Как отключить кэш закладок?

[blizfix 1]

Здравствуйте!

Подскажите пожалуйста, как отключить кэш закладок? В show.short.php на строке

if( ! in_array( $row['id'], $fav_arr ) or $config['allow_cache']) {

удалил

 or $config['allow_cache']

но кэш закладок в коротких новостях по прежнему кэшируются.

 

Сайт  http://multifile.org

[celsoft 6 076]

О каком кеше закладок идет речь? Поясните суть своей проблемы. Закладки не кешируются, т.к. у каждого пользователя свои закладки и у всех они разные, они не могут кешироваться.

[blizfix 1]

1 час назад, celsoft сказал:

О каком кеше закладок идет речь? Поясните суть своей проблемы. Закладки не кешируются, т.к. у каждого пользователя свои закладки и у всех они разные, они не могут кешироваться.

Прошу прощения за не точный вопрос.

Имелось ввиду отображение кнопки добавить в закладки и удалить из закладок. При добавлении в закладки и обновлении странницы кнопка по прежнему отображается как добавить в закладки, так же происходит при удалении из закладок, при обновлении странницы отображается кнопка удалить из закладок.

[celsoft 6 076]

20 часов назад, blizfix сказал:

Имелось ввиду отображение кнопки добавить в закладки и удалить из закладок. При добавлении в закладки и обновлении странницы кнопка по прежнему отображается как добавить в закладки, так же происходит при удалении из закладок, при обновлении странницы отображается кнопка удалить из закладок.

Это не кеширование закладок. Это кеширование новостей. Не может быть одновременно и кеш новостей и тут же уникальная информация для каждого пользователя. Кеш на то и кеш чтобы показывать готовую заранее информацию, а не брать ее постоянно из БД, а у пользователей закладки могут быть разные. Поэтому в данном случае чтобы видеть это нужно отключать кеширование в настройках скрипта в админпанели.

[redissx 251]

Да не, тут речь про [add-favorites][/add-favorites], [del-favorites][/del-favorites] . Не обновляет сразу, как {favorites}

[celsoft 6 076]

1 час назад, redissx сказал:

Да не, тут речь про [add-favorites][/add-favorites], [del-favorites][/del-favorites] . Не обновляет сразу, как {favorites}

Нет. В этой теме идет речь совсем у другом, а не про обновление этих тегов.

[-Sheckler- 9]

На самом деле тема актуальна и я ранее уже тоже писал (создавал тему) на счет некорректной работы закладок. Понятное, что данные кешируются, но значит нужно как-то очищать кэш когда люди добавляют что-то себе в закладки. Ведь очистка кэша также работает при смене сортировки материалов, а это тоже такая же пользовательская настройка. 

Просто сейчас выходит, что при наличии кэширования функционал не работает должным образом. По сути в закладки мало людей добавляют новости, также как и сортируют тоже мало — в чем сложность при этом действии очищать каждый раз кэш новостей?

Я вот сейчас использую ajax версию, нажимаю на кнопку добавить в закладки, она поменялась (я понял что она добавлена) и далее просто обновляю страницу — валя, опять кнопка добавить "в закладки". Это сбивает с толку. Если функционал закладок используется, то пусть чистится кэш просто при добавлении материалов в эти самые закладки (избранное).

Я пробовал использовать конструкцию clear_cache();, но она не работает:

if ( $config['allow_alt_url'] AND !$config['seo_type'] ) $cprefix = "full_"; else $cprefix = "full_".$id;
    clear_cache( array( 'news_', $cprefix ) );

if ( $config['allow_alt_url'] AND !$config['seo_type'] ) $cprefix = "full_"; else $cprefix = "full_".$id;
	clear_cache( array( 'news_', $cprefix ) );

 

Как быть? 

 Функция "добавить в избранное" при включенном кэшировании работает не корректно. Притом проблема наблюдается на странице поиска и в custom'ах — вообще не отображает, что новость в закладках

Изменено 19 апреля 2021 пользователем -Sheckler-

[celsoft 6 076]

Рассуждения в корне не не верны. При использовании сортировки нет никакого очищения кеша и быть не может. Потому что кеш общий!!! и единый!!! для всех пользователей находящихся в одной группы. Например для всех гостей один, для всех зарегистрированных тоже один, но другой именно для этой группы и т.д.

Когда пользователь использует изменение сортировки на сайте, то кеш не очищается, он только для него и только для него вообще не используется, а для всех остальных используется!!!

Закладки это персональная информация каждого!!!! пользователя, она у всех разная. Не может быть кеша и персональной информации одновременно!!! Это по сути полное отсутствие кеша, т.е. достаточно просто отключить кеширование и будут у всех все актуально сразу. Нельзя кешировать и одновременно иметь персональную страницу. Эти вещи не совместимы, и сути противоречат друг другу по логике и прочему. Вам нужно определяться в данном случае что приоритетнее: снижение нагрузки на сервер, или персональная информация на странице для каждого отдельного пользователя. Кеширование это априори потеря динамики в том или ином вопросе и нужно решать что важнее. 

[Gameer 310]

2 минуты назад, celsoft сказал:

Рассуждения в корне не не верны. При использовании сортировки нет никакого очищения кеша и быть не может. Потому что кеш общий!!! и единый!!! для всех пользователей находящихся в одной группы. Например для всех гостей один, для всех зарегистрированных тоже один, но другой именно для этой группы и т.д.

Когда пользователь использует изменение сортировки на сайте, то кеш не очищается, он только для него и только для него вообще не используется, а для всех остальных используется!!!

Закладки это персональная информация каждого!!!! пользователя, она у всех разная. Не может быть кеша и персональной информации одновременно!!! Это по сути полное отсутствие кеша, т.е. достаточно просто отключить кеширование и будут у всех все актуально сразу. Нельзя кешировать и одновременно иметь персональную страницу. Эти вещи не совместимы, и сути противоречат друг другу по логике и прочему. Вам нужно определяться в данном случае что приоритетнее: снижение нагрузки на сервер, или персональная информация на странице для каждого отдельного пользователя. Кеширование это априори потеря динамики в том или ином вопросе и нужно решать что важнее. 

А ведь можно вынести обработку тега за кэш, используя {fav:id} и проверять по member_id['favorites']

[-Sheckler- 9]

1 час назад, celsoft сказал:

Рассуждения в корне не не верны. При использовании сортировки нет никакого очищения кеша и быть не может. Потому что кеш общий!!! и единый!!! для всех пользователей находящихся в одной группы. Например для всех гостей один, для всех зарегистрированных тоже один, но другой именно для этой группы и т.д.

Когда пользователь использует изменение сортировки на сайте, то кеш не очищается, он только для него и только для него вообще не используется, а для всех остальных используется!!!

Закладки это персональная информация каждого!!!! пользователя, она у всех разная. Не может быть кеша и персональной информации одновременно!!! Это по сути полное отсутствие кеша, т.е. достаточно просто отключить кеширование и будут у всех все актуально сразу. Нельзя кешировать и одновременно иметь персональную страницу. Эти вещи не совместимы, и сути противоречат друг другу по логике и прочему. Вам нужно определяться в данном случае что приоритетнее: снижение нагрузки на сервер, или персональная информация на странице для каждого отдельного пользователя. Кеширование это априори потеря динамики в том или ином вопросе и нужно решать что важнее. 

Благодарю за отклик по данному вопросу!

Я не совсем понимаю, почему нельзя делать кэширование для каждого отдельного пользователя. Для гостей да, свободно. А для пользователей можно создать кэш под уникальным идентификатором этого пользователя и использовать их.

Например было "news_" , вместо него "news105_" (где 105 это ID пользователя). Соответственно, таким образом мы получаем кэширование уникальных данных и для отображения используем их же, также вместо "news_" подставляем "news105_" и вопрос должен быть решен. Далее при заходе на сайт для каждого пользователя будет свой кэш.

Другой вопрос будет ли это корректно для самого кэша, т.к. количество данных для кэширования очень сильно увеличится.

[MSK 289]

11 минут назад, -Sheckler- сказал:

количество данных для кэширования очень сильно увеличится.

Не очень сильно, а безумно сильно ;)

И не забывайте, что есть хостинги с лимитом на число файлов...

[-Sheckler- 9]

1 час назад, MSK сказал:

Не очень сильно, а безумно сильно ;)

И не забывайте, что есть хостинги с лимитом на число файлов...

Ну, для сайтов с выделенным сервером (виртуальным или физическим) я думаю это должно быть по силам, если такая реализация является корректной. Можно было сделать функцию для более сложных тяжелых проектов на выделенном сервере, почему бы и нет? :)

[Gameer 310]

42 минуты назад, -Sheckler- сказал:

Ну, для сайтов с выделенным сервером (виртуальным или физическим) я думаю это должно быть по силам, если такая реализация является корректной. Можно было сделать функцию для более сложных тяжелых проектов на выделенном сервере, почему бы и нет? :)

Ничего кешировать не нужно, вынесите обработку тега за новости в engine/modules/main.php добавьте к тегу id новости, и вы через регулярку спокойно сможете проверять есть новость у пользователя в избранном или нет. зачем велосипед с кэшем изобретать?

[-Sheckler- 9]

5 минут назад, Gameer сказал:

Ничего кешировать не нужно, вынесите обработку тега за новости в engine/modules/main.php добавьте к тегу id новости, и вы через регулярку спокойно сможете проверять есть новость у пользователя в избранном или нет. зачем велосипед с кэшем изобретать?

Это я говорил про сайт в целом и персонализацию для снижения нагрузки путём кэширования. У нас есть персональная информация/выборки из БД, для каждого пользователя эту персональную информацию можно кэшить на 2-3-5 минут, чтобы при каждой загрузки страницы он каждый раз не обращался к mysql, что отразится на скорости загрузки страницы, а также на нагрузке на сервер.

[Gameer 310]

1 минуту назад, -Sheckler- сказал:

Это я говорил про сайт в целом и персонализацию для снижения нагрузки путём кэширования. У нас есть персональная информация/выборки из БД, для каждого пользователя эту персональную информацию можно кэшить на 2-3-5 минут, чтобы при каждой загрузки страницы он каждый раз не обращался к mysql, что отразится на скорости загрузки страницы, а также на нагрузке на сервер.

Но там нет ничего чтобы было снижать ведь переменная $member_id доступна в том файле и выборку заново делать не нужно.

[celsoft 6 076]

18 часов назад, -Sheckler- сказал:

Я не совсем понимаю, почему нельзя делать кэширование для каждого отдельного пользователя. Для гостей да, свободно. А для пользователей можно создать кэш под уникальным идентификатором этого пользователя и использовать их.

Это уже не кеш, если у каждого своя информация. Что есть кеш, что нет, нагрузка в таком случае одинакова, даже больше, потому как каждому еще и создавать и контролировать кеш нужно. Нагрузка с отключенным кешем будет в таком случае даже меньше.

16 часов назад, Gameer сказал:

Ничего кешировать не нужно, вынесите обработку тега за новости в engine/modules/main.php добавьте к тегу id новости, и вы через регулярку спокойно сможете проверять есть новость у пользователя в избранном или нет. зачем велосипед с кэшем изобретать?

Идея кстати интересная, такая еще не приходила. Только надо будет сделать двойную обработку тега, первая промежуточная для кеша где будет id публикации, а вторая уже за пределами после считывания кеша. Спасибо за идею. Подумаем.