@phpdude, ну как бы то ни было её возвращение к жизни и настройка локального денвера решили проблему, хотя я так и не понимаю почему )) Просто не вижу связи с выше описываемыми проблемами с некоторыми записями в базе и моими последними действиями. Но пока работает, трогать это не буду :))
Всё починилось после снятия комментария со старой функции и изменения настройки денвера magic_quotes_gpc = Off
потому как в локальной версии с указанной выше функцией весь код резался на корню, ни 1й картинки, ни 1й таблицы - ничего не добавлялось, т.к. ко всем кавычкам в базу добавлялся символ / ну и естественно потом всё на сайте плыло :))
Правда я так и не поняла, почему происходили выше описанные проблемы с записями, даже когда я вместо прежнего текста отправляла какую-нибудь цифру\букву. И почему только на части записей такое случалось..
Теперь интересное наблюдение: конкретно в подопытной таблице 6 записей на данный момент. Прекрасно редактируются только записи с id: 1, 2 и 4
3, 5 и 6 не хотят редактироваться.. Создала 7ю строчку вместо 3й и всё заработало...
Пока не вижу логических объяснений, почему конкретно 3 строки оказались бракованными... Для чистоты эксперимента удалила таблицу и сделала экспорт с локально БД...
Теперь редактируются записи 1, 2, 4 и 6, а повторно созданная 7я, как и 3, 5 - нет :))
В чём может быть причина такого странного поведения? Или стоит просто забить на 3 неработающие строчки (учитывая, что реально нужны всего 4 записи, и как раз 4 работают, просто id поменяется у них).
Я беспокоюсь, что как бы позже проблема с другими записями не проявилась, ранее просто с редактированием не возникало проблем, но последний раз правки делались месяц или 2 назад, а тут вот понадобилось, а 3 строчки не хотят редактироваться из вне, только ручками напрямую в базе.
@phpdude, она у меня раньше была для экранирования спец.символов записи, но потом на хостинге сменили ПО и появились проблемы с этой функцией, сейчас все строки с mysql_real_escape_string закомментированы.
оо! корень проблемы найден )))) Правда пока не понятна причина этого:
Все записи в базе кроме той, которую я как раз редактировала - из админки редактируются на ура
и только одна не передаёт в базу данные при отправке... пойду искать, почему это случилось
По крайней мере точно дело не в редакторах, хотя при одинаковом коде админки для всех записей, непонятно, почему блокируется только одна из середины таблицы в базе..
сейчас даже ещё раз для верности перезалила файлы, не помогло.
Вот жопой чую, что сервер тут непричем и дело в визуальном редакторе. ))))
@AlexB, я на него в 1ю очередь и подумала как наиболее очевидное, пробовала влезть внутрь во все файлы, искала там все места, где хоть как-то фигурирует border, убирала эти строки, чтобы проверить, что будет
так же пробовала вместо старого другие редакторы подключать, как итог наблюдала следующее:
1. в локальной версии все эти редакторы передают код должны образом без добавок, проблема только на хостинге
2. пробовала вместо отправки данных в базу выводить результат на текущую страницу при помощи print_r и как выше советовали var_dump, чтобы проверить, а что именно редактор пытается отправить в базу
проверку проводила на хостинге и на локальной версии - в данном случае редактор отправляет текст без добавок
добавка появляется только при внесении изменений в запись в БД
Может я что-то упускаю, конечно, из виду. Но не знаю, где копать. Была бы проблема и там и там - дальше ковыряла бы редактор.
В бд может быть триггер на инсерт, но не на апдейт.
@Nek, я инсерт даже не тестировала, я пытаюсь пересохранить старые записи, в которые этот border влез, но единственный способ это сделать на хостинге - это руками каждую запись в БД править.. а это как-то не очень
почти во всех фреймворках/cms можно сделать так, чтобы на тестовой версии менялся или примешивался другой конфиг
@Nek, фишка в том, что весь код полностью мной написан, это не чья-то cms... Я по мере пополнения знаний модифицирую и улучшаю его.
На хостинге и на локальном компе стоят одинаковые версии php и mysql
а вот их настройки.. дома стоит то, что по умолчанию досталось с денвером - я не настраивала сама, на хостинге - то, что выдал хостер, плюс есть небольшой доступ к настройкам (скрины в 1м сообщении).
Из всего этого вопрос: каким макаром к мои файлам, в которых нет дополнительного кода, примешивается другой конфиг? откуда он мог взяться? я просто не знаю, где искать это
@Sinkler, cms самописная, потому я уверена, что дело не в ней )) я таких условий там не прописывала.
Да и опять же: в локальной версии ничего не заменяется, только на хостинге, a файлы cms и там и тут одинаковые, и расположены одинаково, т.е., если бы дело было в них - ошибка была бы локальной тоже и её было бы легче найти.
@Jane, а если sql запросом (через ваше средство работы с бд, не через веб-приложение) добавить запись в табличку - тоже будет модифицироваться поле?
@Nek, сейчас для теста в самой БД просто взяла отредактировала конкретную запись - всё сохранилось без проблем. Т.е. дело получается не в БД?
ну это был правда не запрос, а непосредственное редактирование конкретной ячейки таблицы.
Тогда надо смотреть код и конфиги приложения, т.к. где-то есть различие между локальной и продакшн версией.
@Nek, повторюсь: отличий в версиях нет. Любое изменение, сделанное локально, после проверки во всех браузерах - сразу мной заливается на хостинг. К тому же на днях как раз была полная перезаливка всех файлов - т.е. тут уже 100% соответствие.
Правильно я понимаю, что вы перед сохранением контента делаете var_dump.. - там все ок, а сразу после сохранения в записи в бд уже модифицированный контент (причем проверяете последнее через средства работы с бд, а не через странички самого приложения)?
@Nek, да и var_dump и print_r записи, что отправляется в БД делала для теста - там ничего лишнего. Но если сразу после этого посмотреть содержимое БД - там появляется этот border ...
Тип сервера: MySQL
Версия сервера: 5.6.31-log - MySQL Community Server (GPL)
Версия протокола: 10
@Sinkler, я даже код редакторов пыталась просмотреть и поправить, грешила на них сперва. Но т.к. код движка сайта до запятой одинаковый и в локальной версии и в реальной, то это должно было в локальной тоже случаться. Но проблема только на хостинге.
В момент отправки в базу вместе с тем кодом, что я отправляю, добавляется этот border="0" ко всем img в коде отправляемой записи.
И что примечательно, смена редактора в админке не помогает (т.е. в локальной версии всё как нужно, а на хостинге этот border...)
Столкнулась с такой проблемкой:
При добавлении\редактировании записей в БД через админку в локальной версии сайта - всё добавляется как есть (т.е. код добавляется именно так, как прописан в поле редактора).
А вот при добавлении той же записи на реальном сайте - везде к img добавляется тег border="0". У меня это и так прописано в css и это дублирование мне ни к чему.
Перепробовала уже целую пачку редакторов (думала проблема в них), в настройках ставила запрет на изменение кода, однако именно код картинок всегда редактируется (и только на реальном сайте) в момент отправления или добавления в БД.
Появилось подозрение, что это что-то там на сервере хостинга не так настроено. Есть доступ к некоторым настройкам php:
Пыталась найти описания этих опций и расширений, но ничего понятного не нашла :)) По крайней мере на русском. А с английским я пока дружу на уровне: "Hello, my name is.." =))
Есть ли в этих настройках что-то, что так упорно вмешивается в мой код? Или я не там копаю?
Все файлы и настройки самого движка в обоих версиях сайта одинаковые.
@Jane, ну так вставь строчки до подключения к базе! бинго! :) Переделывай, на сейчас тебе два
@phpdude, у меня подключение к базе происходит в отдельном классе, который грузится до загрузки самой страницы, так что не знаю, как там впихнуть этот код, да и проблема самоустранилась просто переустановкой денвера.
Но на будущее запомню, если придётся столкнуться с этим ещё раз. Я же как бы не верстальщик и не программист (разве что по диплому, и то давно и не правда))). Потому переписывать много кода в разных файлах, чтобы появилась новая строчка - на это нужно ещё с духом собраться )) и так 2 дня потратила на отладку неработающего кода, теперь беру перерыв :))
Спасибо за советы.
Не прокатило.
Warning: Cannot modify header information - headers already sent by...
Ругается, что заголовок уже был послан при подключении к БД
В общем, старый Денвер был снесён на прочь (тем более, что там ещё обнаружилась проблема с экспортом из БД), и установлен новый. где в конфиге закомментировала строчку с выбором кодировки. И это сработало на тех страницах, которые были пересохранены в нужной кодировке. Пойду с остальными теперь разбираться.
@artoodetoo, Всегда смотрю через Ctrl+ F5 )) иногда даже напрочь вычищаю историю, куки и вообще всё что можно по сайту, чтобы уж наверняка (а в ИЕ история даже не хранится - браузер тупо для отладки, чтобы у тех, кто в нём сидит тоже всё работало))
@phpdude, да
который: <meta charset="utf-8"> или <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
А после данного вопроса у меня закралось подозрение, что есть ещё какой-то способ, о котором я пока не ведаю :)
Из любопытства вбила в поисковик способ задания кодировки в php, он выдал вариант:
<?php
header("Content-Type: text/html; charset=utf-8");
?>
Это оно? Стоит ещё так попробовать? Или это уже танцы с бубном (учитывая, что у меня и так во всех местах указана кодировка)?
Сейчас уже поздно в любом случае, утром проверять буду, если этот способ лучше.
все страницы php, на всех страницах есть этот заголовок, где строго прописана кодировка.
Она же прописана в файле htaccess , в файле конфигурации апача, и установлена по умолчанию в БД, даже при подключении к базе указано: "SET NAMES UTF8", и как я писала выше, все файлы сохранены в этой кодировке.
В общем, я сделала все рекомендации, что были в сети на этот счёт. И для реального сайта это сработало отлично, а с локальным - если ставить в браузере выбор кодировки автоматически - он думает, что там windows-1251.
Можно, конечно, тупо на локальной версии заставлять браузер тоже читать сайт в utf-8... Но мне ситуация не даёт покоя, хочется найти причину и исправить :))
В статьях нового пока ничего не находится, только те рекомендации, что уже сделаны.
Если учесть, что файлы, лежащие в сети и дома - одинаковые, БД - тоже, остаётся версия, что проблема с апачем и его настройками. Но там была только одна рекомендация по настройке: в файле httpd.conf прописать жёстко кодировку, либо вообще закомментировать с ней строчку.
В моём случае это не сработало. В какие ещё файлы для настройки можно\стоит залезть - пока не нашла, потому я и пишу тут.
Сейчас склоняюсь просто к переустановке вебсервера, может у меня какие-то файлы изначально были кривые.
Ага, на сервере всё ок, но т.к. я сперва все правки делаю на локальной версии и потом заливаю на сервер - это оочень неудобно, хочется локальную вернуть к рабочему виду.
Пока везде была старая кодировка - всё отлично работало, но возвращаться на неё не хочется, да и валидатор выдал, что ему нужна utf-8 :))
Локальная версия сервера: Денвер-3 2012-09-16
Думала попробовать поновее скачать, но там тоже 3й.
Спустя 276 сек.
Стоит другой сервер попробовать? Если да, то какой будет грамотнее работать? Меня на Денвер ещё в 2007м году подсадили, я даже не интересовалась другими и их преимуществами (если такие есть))
Не смогла выбрать, в какой раздел это запихнуть, потому напишу здесь.. :)
Случилось мне тут озадачиться переводом сайта в кодировку utf-8. Нашла рекомендации, всё сделала по ним.
Т.е. прописала в коде в meta теге, поменяла кодировку БД и всех таблиц и полей с текстом на нужную, добавила строчку в htaccess и пересохранила все текстовые (и похожие на них) файлы в utf, как того советовали в статьях.
И с самим сайтом всё замечательно стало, как и задумывалось, но вот по мере смены кодировки текстовых файлов - в локальной версии страницы превращались во что-то страшное с крякозябрами.
Нашла информацию, что нужно файлик конфигурации самого апача (httpd.conf) тоже поднастроить и прописать там кодировку по умолчанию, или закомментировать строчку с ней. (между всеми процедурами денвер перезапускала)
Однако это не помогает, все браузеры на компе локальную версию упорно по умолчанию конвертируют в windows-1251...
Уже закончились идеи, где ещё копать.
Может кто сталкивался с подобным, или знает, в каком направлении ещё поискать корень проблемы? %)
для body - overflow: auto;
так можно накрывать прокрутку окна внутренними элементами
теперь .lb-overlay будет над прокруткой body
ну и для .lb-overlay поставь overflow-y: auto; для своей прокрутки.
при закрытии попапа лучше ссылаться на пустой хэш #, что бы страница не
@technobulka, вот это делала, без 1го пункта про html - оставались 2 полосы
Сейчас попробовала ещё и html задать - заработало :)))
Кроме ИЕ и оперы - там в принципе работает, но не все стили корректно (в опере почему-то webkit не подцепляется и части эффектов просто нет, но это уже другая задача :)) С этим попробую разобраться.
Спасибо, про отдельно для html и body не додумалась прописывать.
@cOAPerator, Сейчас одна полоса, потому как последнюю версию с 2мя я не стала выкладывать.
Проблема в том, что если для BODY по умолчанию это использовать, то страница до открытия блока с картинкой на маленьком разрешении тоже не прокручивается.
А тут нужно чтобы полоса пропадала только при открытии просмотра картинки (потому как сейчас она прокручивает страницу под ней).
@master, покопаюсь, у меня задача была чтобы можно было описание добавлять к картинкам. Ещё не всё отладила визуально, но всё работает кроме это прокрутки :))
В примере полоса прокрутки так же остаётся, и если колёсиком мышки крутануть - картинка просто сворачивается и страница мотается вниз.
У меня если что-то не получается на css - делаю на js и не парюсь.
@master, я с js пока совсем на Вы, вот и парюсь с css.
Фактически нужно каким-то способом написать условие: если div с классом lb-overlay открыт, то у BODY меняется overflow с auto на hidden, и я допускаю, что тут можно при помощи скриптов это как-то решить в 1-2 строчки буквально, только я не знаю, как именно это написать (полночи вчера копалась, но не нашла примеров, либо не по тем запросам искала).
Захотелось мне побаловаться с CSS галерей, но возникла одна проблемка с полосами прокрутки.
Работа галереи на примере страниц:
Сейчас на сайте не финальная версия CSS файла, там пока последний рабочий вариант выложен.
Итак, в чём заключается проблема:
При клике на картинку открывается её увеличенное изображение, однако остаются полосы прокрутки.
Задача:
Когда показано увеличенное изображение: основные полосы прокрутки сайта должны пропадать, т.е. должна подключаться строчка в css:
body{overflow:hidden;}
А в случае, когда картинка большая, как по 1й ссылке - появляться прокрутка для блока с увеличенной картинкой. Это решается достаточно легко: у класса "lb-overlay" значение overflow:hidden меняется на auto, но на данный момент при этом появляются 2 полосы прокрутки (при локальном тестировании), вот от внешней нужно избавиться... :)
Средствами css задачу пока не удаётся решить (хотя может просто где-то туплю в виду не хватки знаний). Склоняюсь к тому, что нужно использовать скрипты, но я с ними не дружу :) И важно, чтобы это всё продолжало работать на мобильных устройствах, как сейчас (тестируется на планшете).
В общем, я за советом: в каком направлении копать для решения задачи? Или может кто-то расщедрится на какое-то работающее изящное решение? :))
С первым я увы только на Вы (в смысле пару раз щупала)) А вот с виндами со всеми, начиная с 98й довелось возиться, и всегда нахожу в них неожиданные баги, которые потом так же неожиданно лечатся (логике многие из них не поддаются.. хотя главное, чтоб лечились))
