linux4me2

Thanks @bojankatusic!

Like a noob, I forgot that since we’re talking about a cron job, the errors were in an error log in the account root, not in the subdirectory where I have MainWP installed in a subdomain. I’m not sure they will be of any help, but here’s what I’m seeing:

[18-Nov-2024 08:05:07 UTC] PHP Warning:  Undefined array key "current" in /home/username/mainwp.thedomain.com/wp-content/plugins/mainwp/class/class-mainwp-cron-jobs-auto-updates.php on line 283
[18-Nov-2024 08:05:07 UTC] PHP Warning:  Undefined array key "new" in /home/username/mainwp.thedomain.com/wp-content/plugins/mainwp/class/class-mainwp-cron-jobs-auto-updates.php on line 284
[18-Nov-2024 08:05:07 UTC] PHP Warning:  Undefined property: stdClass::$automatic_update in /home/username/mainwp.thedomain.com/wp-content/plugins/mainwp/class/class-mainwp-cron-jobs-auto-updates.php on line 287

I’ve submitted a ticket.

I didn’t receive the Daily Digest even with Easy WP SMTP installed and able to send mail to the same address, and with all core crons apparently running normally as shown in Main WP > Info > Cron Schedules, so it looks like we can rule out SMTP issues.

I answered my other question: the Daily Digest looks like it is sent in /wp-content/plugins/mainwp/class/class-mainwp-system-cron-jobs.php starting at about line 454.

There are a couple of other crons recommended here on the “Core” tab, which you may or may not need. I’m not sure which cron file in MainWP is responsible for sending the Daily Digest. It seems like it would be updatescheck.php, which you have, but I’m not sure.

I have disabled the SMTP setup in my child theme’s functions.php, installed Easy WP SMTP as suggested here, and successfully sent a test email using it with the same SMTP settings I was using to see if something in my SMTP setup is the cause of the problem for me. I will let you know tomorrow if I get the Daily Digest.

I don’t want to hijack this thread, only to mention that I haven’t received the Daily Digest emails since v. 5.2, so @yodajones isn’t alone in this.

After 5.2, the mainwp_cronupdatescheck_action wasn’t being triggered in cron and no Daily Digest emails were coming through. Version 5.2.1 fixed the updates check issue for me so that it is now running daily and sites with WordPress, theme, or plugin updates are shown accurately within the MainWP Dashboard, but the Daily Digest emails still aren’t coming through. Nothing in the error logs for me if that helps any. I don’t have any other emails set to be sent except the site monitoring ones, but I haven’t had any sites go down to know if those emails are working.

I have SMTP email set up in my functions.php and WP cron disabled with cron jobs set up manually, if that helps identify what might be causing this for @yodajones and those of us who are also affected.

You’re welcome. Thanks for the post. I think this should have been a feature all along.

Good luck with your site.

I just uploaded version 1.3 of Menu In Post, which honors the “Open link in a new tab” for both the list- and dropdown-styles in Menu In Post.

I added instructions for opening Menu In Post links in a new tab/window in the Help tab for Menu In Post, which you can see by clicking “Help” in the upper-right corner of the Admin > Tools > Menu In Post Tools page.

It’s worth noting that the settings in the user’s browser will determine whether links will open in a new tab or window.

I am going to mark this thread as resolved, but I’ll watch it in case you have any more questions.

Hi @raunhar,

I think I’m going to add this as a new feature. I didn’t originally because it’s considered bad form–especially with mobile devices–to force a link to open in a new tab/window, and preferable to leave the option up to the user; however, I think there are use-cases that make it a good idea.

In the meantime, if you want all your Menu In Post dropdowns to open in a new tab/window, you can modify the code in /wp-content/plugins/menu-in-post/js/main.js to look like this:

jQuery(document).ready(
    function () {
        jQuery('.mip-drop-nav').change(
            function () {
                window.open(jQuery(this).val(), "_blank");
            }
        );
    }
);

That will force the dropdown to open its links in a new tab/window, depending on how the user’s browser is configured.

I will post back here when I have an updated version of the plugin that adds the functionality.

Hi @raunhar,

Since you’re using a dropdown, Menu In Post uses a little jQuery to open the link:

jQuery(document).ready(
    function () {
        jQuery('.mip-drop-nav').change(
            function () {
                document.location.href = jQuery(this).val();
            }
        );
    }
);

As you can see from the code, when the selection of a dropdown that has the class “mip-drop-nav” is changed, the code fires and changes the URL of the current window to that of the dropdown’s value attribute.

There may be a way to override that using a menu ID, but I wasn’t able to get it to work.

Maybe this is something I should include as a feature? Let me take a look at it and get back to you.

I have had the same issue with the last two updates that required a database upgrade. The fix for me was to use SSH to log in to the site, then run the following WordPress CLI command (your web host must have WordPress CLI installed):

wp wc update

After running the CLI command and getting a success message, check WooCommerce > Status to verify that both WooCommerce and the database were upgraded to 8.7.0, and you should be good to go.

If your web host doesn’t have WordPress CLI installed and you can’t install it on your server yourself, you might ask them to set it up for you. It comes in very handy.

I could be wrong, but when they say “self-hosted,” I took it to mean they were suggesting that you install MainWP on your own domain hosted on your own account with a trusted web host, not a local install as you have done, though your approach may be even more secure.

Take a look at MainWP > Info > Cron Schedules and you can see when the cron jobs are set to run and when they last run.

If you see that they are not running as they should, you might have better luck setting up cron jobs on your MAMP instance to run them instead of using an external entity that may have issues pinging your MAMP server. It will give you a bit more control.

Diverse Solutions’ Tech Support is forwarding the issue to their developers, but they aren’t sure if there will be a fix released since the issue is a warning and not an error.

A fix that works for me, based on the Slack post that @jordantorres posted above, is to change line 32 of /wp-content/plugins/dsidxpress/globals.php from this:

wp_enqueue_script('dsidxpress_google_maps_geocode_api', '//maps.googleapis.com/maps/api/js?key='.DSIDXPRESS_GOOGLEMAP_API_KEY.'&libraries=drawing,geometry');

to this:

wp_enqueue_script('dsidxpress_google_maps_geocode_api', '//maps.googleapis.com/maps/api/js?key='.DSIDXPRESS_GOOGLEMAP_API_KEY.'&libraries=drawing,geometry&callback=Function.prototype');

I applied the fix to the site, the warning is gone, and Google Maps is still working.

Note that due to the conditional in the globals.php file, you’ll have to have your own, active, Google Maps API Key saved in IDX > More Options > Maps > Google Maps API Key in order for the variable that adds the callback to be added to the query string.

I just sent the URL to the site.

That Stack link is promising.

Hi @jordantorres,

Thanks for the reply. Yes, I am using your IDX with a new Google Maps API key, but don’t use Google Maps anywhere else and there is no other entry for the maps API key. The theme does not load Google Maps, or use the API key. It’s a default WP theme.

I am using the plugin’s Current Listings widget on every page, so I checked a page that doesn’t use any IDX elements in the main content area to see if that was causing the warning, but it still occurred on pages with only the widget.

I’ve tried the usual: purging the browser and server cache, but the warning persists. I’m not getting the error that Firefox shows when Google Maps loads twice, just the warning noted in the original post.

Hi @tderouindesign,

I think it is resolved. The file /assets/js/min/soliloquy-min.js that caused an issue–for me at least–was just 6.3 kB. The one that downloads if you upgrade now is 29.9 kB and fixes the problem for me.

Give it a try. (Make sure you clear your browser and/or server cache.) You can always revert if it doesn’t work.

I upgraded–without deactivating/deleting the plugin–and Soliloquy is now working without any errors.

I still have the copy of 2.7.4.2 I downloaded that gave the error in /assets/js/min/soliloquy-min.js, and compared it to the file currently on www.remarpro.com, which you should get if you do an upgrade through the WP Admin UI now, and found that while the files have the same dates, the sizes vary drastically; the copy of soliloquy-min.js that broke things has a file size of only 6.3 kB, while the file that downloaded when I upgraded today is 29.9 kB.

So it looks like for me, the issue was a corrupted/incomplete file being downloaded from www.remarpro.com when I attempted to upgrade originally, and all is good now.

I recommend re-attempting the upgrade and verifying that the two files listed here have the correct file sizes listed:

• /assets/js/min/admin-min.js (80.5 kB)
• /assets/js/min/soliloquy-min.js (29.9 kB)

That seems to fix the problem for me. I tried it on two other sites that are running Soliloquy Lite and they worked too.