Automatic page refresh after saving does not work

  • Resolved Matta Cib

    (@matta-cib)


    2 months ago

    Hello Nawawi,
    it’s me again, because now there is a problem. Saving in the backend of WP only works to a limited extent when Docket Cache is activated: The page/post is saved when you click on “Aktualisieren” (the button in english: save? store? update?) and is then also displayed correctly in the frontend in the last saved form. What does not work, however, is updating in the backend. Normally, saving rebuilds the page in the backend and the changes made are displayed. Now, however, the page is also rebuilt, but does not appear with the changes that have just been saved, but without these changes. Incidentally, this not only applies to content in the text field, but also to other changes. For example: If the page was previously defined as “private” and was changed as “public” as a result of the changes, it is visible to the public after saving (i.e. the changed content is adopted after saving), but the page is still marked as “private” in the backend.
    What I tested:
    1) All plugins activated, but Docket Cache deactivated. Result: The error did not occur.
    2) All plugins deactivated (except Classic Editor) and only Docket Cache activated: The error occurred.
    In my opinion, this means that the error is not a result of the interaction of the installed plugins, but lies in Docket Cache itself.
    What can you do?
    The problem can currently be solved by manually reloading the page (by clicking on the icon at the top left next to the address bar), but of course that is not very convenient.
    Many thanks and best regards
    Matta

    Translated with DeepL.com (free version)

    The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author Nawawi Jamili

    (@nawawijamili)

    2 months ago

    Hi,

    I have tested with and without Classic Editor enabled and did not encounter the issue as stated.

    Please try disabling all plugins except Docket Cache and click the “Flush Object Cache” button.

    If the issue persists, nothing I can do since it is works on other sites.

    Thanks.

    Thread Starter Matta Cib

    (@matta-cib)

    2 months ago

    Hello Nawawi,
    Thank you for your quick reply!
    As advised, I deactivated all plugins except Docket Cache and then clicked on “Flush Object Cache”, but unfortunately the problem still exists.
    Perhaps the problem lies in the interaction between the RAM-side object cache and Docket Cache. I had the problem that the opcache_get_status function was not working (see thread https://wordpress.org/support/topic/opcache_get_status-function-disabled/). My hosting provider confirmed your diagnosis that this is normal on a shared hosting server, but that OpCache is still functional. In this context, he further explained that there are two ways to use OpCache in terms of hosting:
    1) using a php.ini, which must contain the three instructions
    zend_extension=opcache.so
    opcache.file_cache=/homepages/uXXXXX/.opcache
    opcache.file_cache_only=1
    (plus a reference to the php.ini in the .htaccess) – this is probably normal use “in the file system”
    2) using the RAM: Since PHP-FPM is installed for me on my hosting account and OpCache is included in the RAM.
    Since number 2) is the faster option, I chose this in terms of hosting.
    Hypothesis: Could it be that this server-side OpCache in the RAM is incompatible with the object cache of Docket Cache?
    Many thanks and best regards
    Matta

    Plugin Author Nawawi Jamili

    (@nawawijamili)

    2 months ago

    Could it be that this server-side OpCache in the RAM is incompatible with the object cache of Docket Cache?

    Usually, it doesn’t cause an issue. Could you please share you share a screenshot of

    1. Overview page.
    2. OPcache page.
    3. OPcache config page. On the OPcache page, click “Display Config” button.

    And see what we can do about it..

    Thanks.

    Thread Starter Matta Cib

    (@matta-cib)

    2 months ago

    Hello Nawawi,
    Thank you for your answer. I’m happy to send you the screenshots you requested. Since I can’t seem to insert them here, I’ve stored them separately on my web space: overview.png, opcache.png, opcache-config.png. I’ve also attached the configuration.png and the health-report.pdf as a PDF.
    I think creating the health report was a good idea because I noticed two things there:
    1) I did the first report (which I have attached) when all plugins (including Docket Cache) were activated. There I found a WP-note that was declared as a problem, saying that there are two files in the wp-content directory, namely object-cache.php and advanced-cache.php. I suspect that this is perhaps not supposed to be the case, because WP points this out.
    2) I also found the following note in this first report:
    “The scheduled event, wp_privacy_delete_old_export_files, could not be executed. Your website is still working, but this may indicate that scheduling posts or automated updates is not working as intended.”
    I then googled a bit and found a thread in the WP support forum that deals with this problem. The cause of the problem was probably two competing caching plugins (WP Fastest Cache & Redis Object Cache).
    So I temporarily uninstalled Docket Cache and ran a second health report. The problem with wp_privacy_delete_old_export_files seemed to be solved, but the result was the following message:
    “The scheduled event, action_scheduler_run_queue, could not be executed. Your website is still working, but this may indicate that scheduling posts or automated updates is not working as intended.”
    So I googled it and strangely came across another thread in the WP support forum, which was started by the same author who had already started the thread about the wp_privacy problem. So things seem to be linked and somehow located in the context of competing caching systems. In any case, in this second thread, the cause of the problem was the use of two cache plugins (WP Fastest Cache & Redis Object Cache).
    Then I activated all the other plugins again (Docket Cache was still activated) and created a third health report. The result was that the error messages regarding wp_privacy and action_scheduler no longer appeared.
    I also looked in the existing php-error.log, where there was no reference to caching or even docket caching. And I also switched on the debug mode, but so far there is no /wp-content/debug.log.
    I hope that helps.
    Many thanks and best regards
    Matta

    Thread Starter Matta Cib

    (@matta-cib)

    2 months ago

    Oh yes, the original error (not updating the content of the backend page or updating can only be enforced by Ctrl+R) unfortunately still exists…

    Plugin Author Nawawi Jamili

    (@nawawijamili)

    2 months ago

    Hi,

    Thanks for the explanation. I can’t open the screenshot. It returns a “Fehler 403” message.

    This issue needs further debugging on your site. I believe it’s related to your site configuration. There is not much I can do about it. At this moment, you may either uninstall Docket Cache or use it as it is.

    Thanks.

    Thread Starter Matta Cib

    (@matta-cib)

    2 months ago

    Hello Nawawi,
    Thanks for your answer!
    I’m sorry that the PNGs wouldn’t open, I have no idea why that was. But it doesn’t matter, because I’ve continued testing and think I know where the problem lies.
    I first deactivated PHP-FPM and thus also deactivated the server-side creation of the OpCache in RAM: Instead, I loaded “normal” PHP (8.2). The problem then did not occur when Docket Cache was activated.
    In a second test, under the same conditions, I also set up the OpCache on the server side using instead php.ini (zend_extension=opcache.so). The problem did not occur there either.
    So it must be due to the RAM cache created by PHP-FPM, not Docket Cache.
    If I find out more, I’ll get back to you – maybe it will help other users too.
    Best regards
    Matta

Viewing 7 replies - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.