Всех приветствую! Сделал маленькую функцию, в которую передается два параметра: подготовленная строка запроса и массив данных. Функция автоматом определяет (по строке запроса) какое действие необходимо выполнить и возвращает результат. В частности, для "UPDATE" - возвращает true или false, в зависимости от успеха операции. Теперь к проблемке: Если использовать конструкцию запроса "UPDATE IGNORE ...", и обновлять запись с уникальным полем в БД, то в случае дублирования данный, мы получим ответом "0" и в случае, если пользователь ничего не изменил в данных - тоже "0" затронутых строк.
Сижу и чешу затылок, как бы разграничить эти результаты и выводить юзверю соответствующее сообщение: или "Такое имя уже используется", или ... ну, тут можно не выводить сообщение, т.к. ошибки не было, а просто данные остались такими же, как до попытки их обновить.
Повторюсь, что использую PDO и кроме того, данные отправляются AJAX-запросом, что не допускает попадания в ответ ошибки сгенерированной на сервере, какой она могла бы быть, если использовать запрос без "IGNORE".
Если кто сталкивался с подобным, прошу натолкнуть на мысль в правильном направлении.
Всем привет! Не вникал углубленно в тему безопасности, поэтому возник вопросик. Достаточно ли будет использовать для входа в админку сайта только сессии? Для уточнения: никаких "новых регистраций" через веб-интерфейс не будет, в кукисах ничего не сохраняется (модератор вводит данные при каждом новом посещении), пароль хорошо шифруется (XOR).
Был преобразован, как мне тогда показалось, буквально одной-двумя встроенными функциями PHP, в массив, где первое значение каждого вложенного массива, становилось его ключом:
все что после решетки в адресе - на сервер никогда не попадает!!!
Всё это я прекрасно знаю. Тем более, весь механизм работы сайта, как это не покажется странным, мне знаком на все 100%, т.к. я его и писал абсолютно с нуля, и принципиально ни в одном проекте не использую никакие CMS Не о том речь зашла. Главное, что я для себя уяснил - это то, что от полного кеширования страницы, наверно придется отказаться и вы сами подтвердили мои домыслы. Кстати, в полёте мысли, я как-то пропустил в вашем первом сообщении упоминание о LocalStorage. А ведь это вариант. Правда не очень удобный в плане управления кеш-данными, но всё же... надо будет обдумать эту тему. Спс.
Еще раз акцентирую внимание, что сайт работает без перезагрузок, на всех ссылках сайта весит preventDefault(), запросы отправляются в обработчик ajax-средствами, ответ - json
DelphinPRO пишет:
А какая разница? Обращение к серверу все равно идет по адресу без хеша.
В осле - именно с хешем.
DelphinPRO пишет:
Вообще не очень понятно, что и где хотите кэшировать. Если на клиенте, то можно часть данных сохранять в localstorage.
Кешировать малоизменяющиеся данные: статьи, посты блога, видеопрезентации и т.п. Кешировать собираюсь на строне сервера.
DelphinPRO пишет:
Если на сервере - то тут принципы ничем не отличаются от обычных сайтов.
Как оказалось - отличается. Точнее, отличается не сам механизм создания кеша, а то в какой форме его создавать. Для обычного сайта, при запросе определенной страницы, мы бы проверили существование кеша, если надо - его актуальность (дата создания) и произвели те или иные действия. Теперь вернемся к моему вопросу.
Вариант номер раз: кешируем, к примеру, саму статью и в обработчике вытаскиваем или же её из БД (если кеша нет), или из кеша (если таковой рисутствует). В этом случае, возникает вопрос: а зачем тогда нам хэш, если выполнить один запрос к БД это вообще не проблема, а вся оболочка (довольно тяжёлая), так или иначен будет проходить все круги шаблонизации и подгружаться естественным образом.
Вариант второй: как я описал в начале, кешируем всю страницу полностью с каждой статьей в отдельный файл. Вариант был бы хороший, если бы не проблема с ослом, а именно, всё тем же хешем в URL. Поясню, что происходит в этом случае. Юзер набирает в нормальном браузере ручками адрес: http://site.ru/articles/statja.html, по такому адресу у нас есть реальный файл (та самая закешированная статья) и она же выводится на экран пользователя. Тут всё гуд. Теперь, те же действия в осле: точно так же набран адрес, но в браузере ссылка автоматически преобразуется в URL вида http://site.ru/#/articles/statja.html. Естественно, что по такому адресу файла не существует и происходит обычная подгрузка статьи из БД в обход кеша.
Для того, чтоб посмотреть это своими глазами, вот реальная ссылка на тестовом сервере. http://anna[dot]webkey[dot]net[dot]ua/articles/uspeh[dot]html . Попробуйте запустить ее в любом нормальном браузере, а потом в осле. Если подгрузиться закешированная страница, то вы увидите под названием статьи Закешированная страница!!!, если из БД, то этой надписи не будет.
Здравствуйте! Хочу посоветоваться по поводу кеширования страниц сайта, работающего без перезагрузок. Используется Ajax, HistoryAPI, ЧПУ. К примеру, финальная ссылка к статье имеет вид: http://site.ru/articles/article_name.html. Первая же мысль, которая возникла - это кешировать каждую такую страницу в отдельный html-файл. Вроде бы ничего выдумывать не надо, т.к. правило mod_rewrite, перенаправляет все запросы на морду, если файлы или директории на сервере не найдены. А так как они присутствуют, то соответственно и подхватываться они будут автоматом. Будут, но только при прямом обращении к определенной статье, а не при переходе по внутренним ссылкам сайта. Кроме того, вид ссылки в осле отличается. Те, кто использовал HistoryAPI знает, что в URI присутствует хэш. http://site.ru/#/articles/article_name.html.
В общем, можно долго рассуждать что да как, обсуждать разные "НО", а как же все таки оптимальней всего кешировать в такой ситуации? И может на таком сайте вообще нет смысла в кешировании?
Где-то так , но вы немного не уловили суть. Версия PHP на хосте моего клиента аж 5.2.17 и тут при всем желании JSON_UNESCAPED_SLASHES использовать не получиться. Поэтому пытаюсь выяснить - есть ли альтернатива? Не исключаю, что просто упустил где-то информацию, но и для старых версий PHP, тоже может существовать нужный параметр.
А это меня не устраивает. Начиная с версии PHP 5.4.0, есть константа JSON_UNESCAPED_SLASHES, которая решает данную проблему, но как можно выкрутиться, если версия PHP ниже 5.4.0? Как вариант, можно полученную JSON-строку обработать с помощью функции stripslashes(), но мне кажется, что есть какая-то константа, которая делает это еще на стадии кодирования.
EuGen, спасибо за помощь. И не подскажите по поводу того, как запросом можно создать индекс по этим полям? Или это можно сделать только при создании таблицы?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 298
Не о том речь зашла. Главное, что я для себя уяснил - это то, что от полного кеширования страницы, наверно придется отказаться и вы сами подтвердили мои домыслы. Кстати, в полёте мысли, я как-то пропустил в вашем первом сообщении упоминание о LocalStorage. А ведь это вариант. Правда не очень удобный в плане управления кеш-данными, но всё же... надо будет обдумать эту тему. Спс.
и тут при всем желании JSON_UNESCAPED_SLASHES использовать не получиться. Поэтому пытаюсь выяснить - есть ли альтернатива? Не исключаю, что просто упустил где-то информацию, но и для старых версий PHP, тоже может существовать нужный параметр.
