SoN9ne

I have now been able to duplicate this on a vanilla WP setup consistently.

This appears to be a bigger issue of the Object Cache not properly invalidating options when being updated. Which is a severe bug as this can cause serious issues on a site.

Please share this with the devs: https://github.com/W3EDGE/w3-total-cache/issues/605#issuecomment-1357749152

That shows exactly how to duplicate the issue and also shows how I was able to bypass the issue (not a proper fix).

The concern is that this is a core issue with Object Cache and this is affecting all options in WP (possibly other systems?) . For now, I cannot use this on PROD due to it not updating the cache for any options

• This reply was modified 2 years, 3 months ago by SoN9ne.

I have created a ticket for this issue on github: https://github.com/W3EDGE/w3-total-cache/issues/605

To add more details about what is happening:

When I run the cron, the same crons are running over and over again on each cron interval. When I remove the object-cache.php file, then run the crons, they work as expected and update the cron options value appropriately (all cron timestamps are updated and single run crons are properly removed).

If I add the object-cache.php file back, then run cron again, it will run the same cron jobs as before I removed the object-cache.php file and then it will update the cron option with the cached values it already ran with. This is adding back into the cron setting, single run crons that have already ran as well as adding back in bad next runtimes. This is also causing all crons to show as overdue in WP Crontrol page.

It would seem (cannot check this in code yet), that the object-cache.php file, for whatever reason, is only using the cached value of the cron options value and not fetching it appropriately. Given my default cache lifetime is 180 I would expect it to expire after that time. I do have the Store transients in database unchecked. I wanted to make note of this for now.

There is a direct correlation between the same crons running, the bad cron options values, and the object-cache.php file. Simply removing that file stops this from happening. I don’t need to change any settings, just removing that file fixes the issue. I am unaware of the consequences of keeping that file removed. I assume W3TC will not cache properly with that file removed. So I am still attempting to figure this out.

I tried to add config to the Non-persistent groups since this is supposed to ignore caching for this group, but that has no affect.

I will update more as I discover more about this issue.

• This reply was modified 2 years, 3 months ago by SoN9ne.

Still not able to isolate this issue. Once I remove the object-cache.php file then add it back, I need to wait some time until this happens. I will keep trying to figure this out.

I am running wp cron event run --due-now at 5 minute intervals. With these constants:
define('DISABLE_WP_CRON', true);
define('WP_CRON_LOCK_TIMEOUT', 60);

The hard part is debugging with wp cli.

As for how these crons are invoked, on production, we are using AWS ECS Scheduled tasks that runs the wp cron command on 5 minute intervals. On local development, we manually trigger the wp cron command. This happens on production and local.

On production, we need to use ECS Scheduled tasks as using the URL to trigger cron will cause issues due to autoscaling (it will kill the task running the cron and we had this issue previously).

The cron jobs affected are all cron jobs and it’s rarely the same that keep running when this happens. This is why I am assuming the cron option is being cached. After some time, it’s only the same cron jobs that keep running while all other are overdue. I then remove the object-cache.php file and then disable the object cache and this seems to recover as the cron jobs will run immediately after I do this.

I have WP Crontrol installed and when I check the list, I see almost all cron jobs are a week overdue. This time this happened, the cron jobs that kept running were:
wpseo_ping_search_engines
wc_admin_unsnooze_admin_notes
wp_privacy_delete_old_export_files
olyott-plugin-importexport-cron-queue-process
action_scheduler_run_queue

The previous time this has happened, this was completely different crons that kept running.

On local, I have tried to use the URL to invoke cron and the same issue is happening. Since I removed the object cache file, it takes some time for this to happen again. Once this happens again, I can debug using the URL for the cron process. I am waiting for this to happen again to get more information. Until then, it’s impossible to duplicate the issue.

One more thing that I am noticing now that I am paying attention to the cron system. When this issue happens, it seems that when the crons do run and object cache is enabled, I am seeing single run crons still showing after they ran. Meaning, that crons that ran do not appear to be shown as being updated for the next run time. When checking the database, I see them in the cron options table too. That is interesting. When I disable the object-cache.php file, when they run again, they do get updated properly and the single run crons are removed properly.

Let me know if you need more information.

Thanks again

• This reply was modified 2 years, 3 months ago by SoN9ne.
• This reply was modified 2 years, 3 months ago by SoN9ne.

I can confirm this happens locally but it seems to take a week for this to start to happen. That is what’s so puzzling about this. I would expect this to happen immediately. I am still trying to dig into this issue but got pulled off on another task real quick. I will update this post when I find anything.

I am also trying to setup a vanilla setup for this since we do have a lot of plugins installed (mostly custom plugins for our system that won’t affect how W3TC works but we do have WPML and WooCommerce installed too). What is weird, is that I can resolve the issue by making sure the object-cache.php file is removed.

Our production system won’t remove files (other than cache) so when we were disabling the object cache, the file still existed. Once I removed the object-cache.php, then cron works as expected.

Thank you for looking into this issue. I can tell that time is a factor for this to break cron. I will update when I find out more information.

• This reply was modified 2 years, 3 months ago by SoN9ne.

Awesome, I will close this ticket then. Seems this was all a false-flag due to that error but it is working. Thanks again!

Thank you for your response.

Could you please check the Debug tab and see if you see the message:

No strings can be extracted from source code

I never checked past seeing that error.

I just tested now and I am actually able to get the translations to work. So perhaps this is working but that error is not accurate.

It would be nice to be able to use the loco.xml in the sub-folders but this works for my needs.

Thank you so much for your time. I truly appreciate it. Thank you

Thank you.

oly-ott-core folder structure in the mu-plugins:

oly-ott-core
├── assets
├── index.php
├── js
├── languages
│?? ├── oly-ott-core-en_US.mo
│?? ├── oly-ott-core-en_US.po
│?? ├── oly-ott-core-es_ES.mo
│?? ├── oly-ott-core-es_ES.po
│?? └── oly-ott-core.pot
├── lib
├── metabox-views
├── oly-ott-core.php
├── readme.md
├── templates
├── Third-Party
├── views
│?? ├── olyrecommends-sync.php
│?? ├── user-profile.php
│?? └── woocommerce-pricing-updater.php
└── wpml-config.xml

Plugin Header

/**
 * Plugin Name: Oly OTT Core
 * Description: Core resources for Oly OTT Platform
 * Version: 1.7.4
 * Text Domain: oly-ott-core
 */

This should be enough to see the text domain and the folder structure.

The olyrecommends-sync.php is using standard WP i18n:

_e('Translatable String', 'oly-ott-core')

• This reply was modified 2 years, 7 months ago by SoN9ne.

Not sure how this isn’t correct, am I missing something?

<?xml version="1.0" encoding="utf-8"?>
<bundle name="Oly OTT Core">
    <domain name="oly-ott-core">
        <project name="Oly OTT Core" slug="oly-ott-core">
            <source>
                <directory>oly-ott-core/views</directory>
                <file>oly-ott-core/views/olyrecommends-sync.php</file>
            </source>
            <target>
                <directory>oly-ott-core/languages</directory>
            </target>
            <template>
                <file>oly-ott-core/languages/oly-ott-core.pot</file>
            </template>
        </project>
    </domain>
</bundle>

Thanks for your response.

It seems mu-plugin support is minimal.

WordPress recommends using a proxy loader which then loads the mu-plugin from a folder which acts like a normal plugin.

This is implemented as:

mu-plugins
├── 1-olymp-wp-core.php
├── 2-oly-ott-core.php
├── 3-oly-ott-features.php
├── olymp-wp-core
├── oly-ott-core
└── oly-ott-features

Whereas every folder is a proper WordPress plugin.

Using loco.xml for mu-plugins is not possible unless I build a loco.xml in the mu-plugins folder and configure them all in it (not ideal at all). It also seems that adding “Source File Paths”, it still gives:

No strings can be extracted from source code

I even tried configuring it in the backend interface and it still never seems to work.

I tried with using the main directory:

<source>
    <directory>oly-ott-core</directory>
</source>

Then I also tried declaring every directory that has translatable files but it just doesn’t seem to work.

I then tried to specify a single file and still nothing. I tried relative at first then even tried absolute path (I know it’s not recommended, just trying to get this to work) and still nothing.

Do you have any suggestions?

There are 2 design patterns most commonly used with mu-plugins:

1. Single PHP file in the mu-plugins directory that is the simple plugin
2. A proxy loader that loads the plugin from a sub-directory in mu-plugins (WordPress recommended way).

It seems that the first way is supported but I cannot prove this. The second way would be nice to have supported as this is the recommended way by WordPress.

This is the way I was able to add mu-plugins support to Polylang for the wpml-config.xml (awaiting review to have it put into Polylang):

        // Mu-Plugins
        // Search for top level wpml-config.xml, not ideal or best practice but these exist.
        if (file_exists($file = WPMU_PLUGIN_DIR . '/wpml-config.xml')) {
            $files[basename(WPMU_PLUGIN_DIR)] = WPMU_PLUGIN_DIR . '/wpml-config.xml';
        }
        // Search for proxy loaded mu-plugins
        foreach (new DirectoryIterator(WPMU_PLUGIN_DIR) as $file_info) {
            if ($file_info->isDot()) continue;
            // Check if a directory (proxy loader method)
            if ($file_info->isDir()) {
                if (file_exists($file = $file_info->getPathname() . '/wpml-config.xml')) {
                    $files[$file_info->getFilename()] = $file;
                }
            }
        }

Perhaps this is worth checking out for this plugin too?

I really like the work done on this plugin and I would like to have my mu-plugins integrated into it properly. I hope this is possible to get done.

Thanks

• This reply was modified 2 years, 7 months ago by SoN9ne.
• This reply was modified 2 years, 7 months ago by SoN9ne.
• This reply was modified 2 years, 7 months ago by SoN9ne.

Actually, the issue I had was due to this plugin. I disabled this plugin and it works as expected.

Actually, this seems to break the admin language. I just disabled this plugin and it shows properly.

I’ve moved on to Loco Translate. Thanks for this plugin but unfortunately it has a bit of issues.

Actually, even with fixing the text domain, it still says

No strings can be extracted from source code

I am able to do the string translations in my PO files but it’s not seeing any changes in my code.

nevermind, seems I messed up the text doamin…

• This reply was modified 2 years, 7 months ago by SoN9ne.

To follow up about my issue:

I can confirm that my patch works as expected. My issue I experienced is due to a bug with WPML to Polylang that I am currently working on. MU Plugins are now properly translatable with my patch.