skyhawkpictures

Thanks but that’s not the issue.

1. all occurrences of dev domain are updated to prod domain as part of my promotion to prod process (in all tables, not just options).

2. any particular piece of data in the options table (domain name or anything else) should not prevent it from loading into the front-end.

Cheers,
S.

Hi thanks for the reply.

Alas, no. I don’t really have a server-side cache. I do use Cloudflare and have cleared that, but that doesn’t make any difference.

I have a contingency site that runs on my own servers here in-house and a production site held on web-hosting. Whenever I promote my site from dev, both the contingency site and production site exhibit the same symptoms – seemingly no structured data (yet it’s there in the database).

Thanks
S.

Hi,
Yes, that is now fixed
Thanks
S.

FYI I have located the issue in your code (and also the additional issue that follows when that issue is fixed).

The inclusion of the class_modula_update.php file sits within an if(is_admin()) block. This means that the file is NOT included when the plugin is activated from a command line. It is ONLY included from the dashboard activation.

So I moved this code outside the IF block to see if it fixed the issue. It did, but it created a new issue. It appears you have introduced an activation redirect hook to direct the dashboard to the Modula plugin. This is, and has always been, a monumentally crap idea and I’ve never understood why any self-respecting organisation would use it. But either way it ONLY works with the dashboard interface. It throws up all sorts of warnings during command line activation.

Get your act together guys, please.
S.

• This reply was modified 4 years, 9 months ago by skyhawkpictures.

One follow up question: I’ve debugged the offending plugin (in lieu of the plugin author debugging it themselves!) and I’ve found the issue. Is there anything in the WP core functionality that allows me to check in code if activation is specifically from the CLI to distinguish it from the dashboard?
e.g. if ( wp_ActivationFromCLI() ) {…}

Hi,
I have updated to 2.2.5 and the “hide captions” issue appears to be fixed. Note however, that it’s not a true test because I didn’t roll back the database from the previous issue (in other words, my starting point for this update was code on 2.2.3 and db on 2.2.4)

However, the more pressing issue (the reason I had to roll back) of the CLI activation is still NOT fixed. I still cannot activate the plugin from the command line, therefore I will need to roll this out – again. Same error – class not found Modula_Update

Thanks
S.

Hi again Mihaela,
I updated from 2.2.3 (and have rolled back to that now).
Thanks
S.

Ahh ok, certainly that would explain it. Thanks for the info Tyler.

Hi Mihaela,

Thanks for your reply.

Regarding the Whatsapp…now understood, I’ve now spotted the “Turn Social Off” switch which acts on all icons.

Regarding the captions and titles, yes its exactly as you said (odd as it seems). I have Modula on two websites (one website has 3 separate galleries) and none showed titles or captions. Following the update, the options to hide captions and hide titles were both switched off for all galleries.

Regarding the CLI, thanks. I’ll look out for it in the changelog before upgrading.

Regards,
Steve

An additional issue, it is not possible to activate the plugin using the commandline (wp plugin activate) because it results in a fatal error. Class Not Found ‘Modula_Update’. I’m going to have to roll this thing back.

+1 for me too
If I run BSR on the whole DB I end up with a 5Gb debug.log file, plus the search fails.
I am using WP 5.3.
Thanks
S.

Just to let you know I get this too.
I use Updraft to script out the DB, then I appy this to the new site database. It should be an exact copy but either does not seem to be or it screws something up somewhere.

Thanks.
Actually there is one workaround. I’ve added a htaccess rewrite rule to redirect wp-login to a non-existent page. Not ideal but better than the basic Cerber 404 options. Of course it could redirect to an existing page too (and that could be implemented in Cerber as an option as well as the two available 404 choices).

Thanks
S.

• This reply was modified 5 years, 5 months ago by skyhawkpictures.

Thanks for the confirmation Gioni.

That’s no problem, I have no issues with it. As I say, the only helpful addition would be to reinforce that notion to the user. I only discovered it because of this issue. Although you have explained it clearly in your access lists post, it’s not obvious from the settings page, that’s all.

Thanks again and keep up the great work
Steve

Hi again,

You know what, I think I answered this myself. Reading your page on Whitelisting, it appears that the whitelist is checked, and if an IP is on it, then no further checks are made of any kind.

So that would explain how I can access the wp-login.php.

I think it is probably worth putting a help note on the Cerber settings page where these options are. All I see is “be careful! you can lock yourself out” which is fair enough, but if it said “be careful! you can lock yourself out unless you’re on the whitelist” instead, I think that would be helpful.

All the best
Steve