agathongroup

Thanks for checking in. We (Agathon Group) are actually the webhost, and we use an auto_prepend_file to detect HTTPS requests that terminate in NGINX on our stack. Specifically, NGINX proxies to Apache/PHP and sets a header via this NGINX directive: proxy_set_header X-Forwarded-proto $scheme;

We pass the connection from NGINX to Apache without SSL, as it’s happening over loopback. This saves some CPU cycles.

However, it means that Apache has to know that the original connection (between the client and NGINX) was over HTTPS, or else it redirects to an https:// version of the site URL. The way it does that is to inspect X-Forwarded-proto, and the way it does that is through an automatically prepended file:

<?php
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS'] = "on";

There are other plugins that write their own prepend file directive into .user.ini but they properly detect the presence of an existing prepend file. One plugin in particular adds this (redacted) code to the top of their own prepend file:

// This file was the current value of auto_prepend_file during the [plugin] installation (Sun, 27 Jun 2021 23:30:08 +0000)
if (file_exists('/home/[user]/etc/prepend.php')) {
	include_once '/home/[user]/etc/prepend.php';
}

It then follows with its own bootstrap instructions. This allows both our (existing) prepend file and the plugin’s (new) prepend file to be executed properly.

Blogvault doesn’t take this approach, and any existing prepend file is both overridden (in .user.ini) and left unincorporated in Blogvault’s prepend file.

I can give you specific sites, but would rather not have to do so. I’m hoping, instead, that this is more than enough information to adjust the code that writes out your prepend file to test for the presence of an existing prepend and incorporate it, thereby not confounding our hosting stack.

Thanks!
Peter

@shivamtyagi – thanks for the reply, and for pointing me in that direction. I hadn’t thought to look under Archives for that, but that’s exactly what I was looking for. Appreciate it!

I realize, upon closer inspection, that the default WP behavior is preserved somewhat if Search Appearance -> Advanced -> Global Robots Meta is set to “Use Default Settings”.

This ensures that noindexing happens on pages 2+ of search results, but will still allow indexing on the first page, and on pages with 0 results (which is quite likely for a lot of spammy search terms).

So I will adjust my request to allow for noindexing **all** search pages, or at least search pages with 0 results.

Actually, I may have answered my own question. It looks like I happened to choose a story in the old database whose post_content_filtered column contained corrupted JSON–it was not escaped properly, and so (presumably) the JSON parsing failed. I’m going to guess this was a problem with this particular story on the old site, as well.

I pulled in a different story that did *not* have this formatting issue, and it seems to have come over cleanly.

Thanks for keeping things self-contained in these two tables! It makes this particular task much more straightforward.

Hi there,

I wonder if you have any more insight or tips on what might be needed to import web stories from one instance to another via database. The scenario that I have right now is that I have a snapshot of a database that contains a number of stories that I’d like to pull into another live, running, instance.

To test one out, I copied the relevant row into wp_posts and the relevant rows into wp_postmeta. I verified that the ID of the post itself was not present in the live DB, and I allowed the wp_postmeta import to reassign primary keys as needed (while keeping the post_id, meta_key, and meta_value fields intact).

This kinda worked. I previously had 2 webstories, and after copying the data in this way it my “My Stories” dashboard did update to say that I had 3 stories… but it still showed only 2 story cards (verified by looking at the HTML).

If I click instead to Stories -> All Stories I do see my copied story listed (with proper author, title, published date). If I click “View” to view the story at its permalink it actually does work (including text, animation, imagery, etc.). However, if I click to “edit” the story, I see the story editor but each page is blank – I just get a white card, without any of the imagery/text that appears when I view the permalink.

It feels like there may be some sort of cached/compiled JS or CSS content that might just need to be regenerated to allow the editor and “My Stories” view to “notice” the updated story, since it seems fully functional at the permalink.

Is there some additional step I might need to take to get it to work completely? Some other crucial bit of information that I need to move over? I’m comfortable manipulating database content, so any general pointers of what I might have missed would be super helpful.

Thanks!

• This reply was modified 3 years, 6 months ago by agathongroup.

FYI I was running into this same issue with WPForms (the action scheduler tables were not created and the site was crashing).

I verified that my DB user has full privileges on my database (including table creation).

I initially tried following the steps on the linked tutorial but as soon as I installed Action Scheduler directly, the site crashed with the same issue (that is, the DB tables were not present).

Ultimately to fix it I followed RankMath’s process for solving this, which involves installing a one-off plugin that creates the ActionScheduler tables. Once I did that, I was able to re-activate WPForms successfully (and I didn’t need the standalone ActionScheduler plugin anymore).

Sidenote: on the tutorial, step 3 (“3. Creating Action Scheduler Tables”) says to navigate to the WPForms menu to install the scheduled actions, but at this point in the tutorial, the WPForms plugin itself is still disabled, and so even if the site weren’t crashing (which it was for me) that option wouldn’t be there.

(Sorry, that formatting is hot garbage. Point being this particular command line operation sent ALTER TABLE wp_blc_instances MODIFY COLUMN link_text text NOT NULL DEFAULT '' and then spent five minutes waiting for MySQL to respond b/c it was doing other things.)

We have a client who experienced this problem this morning. There’s no error or message because the PHP processes just spin before timing out.

The problem is in the database, which seems to be in a death spiral executing the following query over and over and over:

OPTIMIZE TABLE wp_blc_links, wp_blc_instances, wp_blc_synch

Especially on InnoDB, OPTIMIZE TABLE is an extremely expensive operation. Further, it’s blocking other normal queries on the wp_blc_instances table in Waiting for table level lock.

Unfortunately the only fix appears to be to completely remove the plugin folder, as we can’t even get wp plugin deactivate to work. Incidentally, here’s a partial strace of wp plugin list with timestamps so you can see where it’s hanging:

1590503980.171024 sendto(3, " \0\0\0\3SHOW INDEX FROMwp_blc_synch`;”, 36, MSG_DONTWAIT, NULL, 0) = 36
1590503980.171320 poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = 1 ([{fd=3, revents=POLLIN}])
1590503980.172042 recvfrom(3, “\1\0\0\1\rK\0\0\2\3def\22information_schema\nSTATISTICS\nSTATISTICS\5Table\nTABLE_NAME\f\340\0\0\1\0\0\375\1\0\0\0\0P\0\0\3\3def\22information_schema\nSTATISTICS\nSTATISTICS\nNon_unique\nNON_UNIQUE\f?\0\1\0\0\0\10\1\0\0\0\0N\0\0\4\3def\22information_schema\nSTATISTICS\nSTATISTICS\10Key_name\nINDEX_NAME\f\340\0\0\1\0\0\375\1\0\0\0\0T\0\0\5\3def\22information_schema\nSTATISTICS\nSTATISTICS\fSeq_in_index\fSEQ_IN_INDEX\f?\0\2\0\0\0\10\1\0\0\0\0R\0\0\6\3def\22information_schema\nSTATISTICS\nSTATISTICS\vColumn_name\vCOLUMN_NAME\f\340\0\0\1\0\0\375\1\0\0\0\0N\0\0\7\3def\22information_schema\nSTATISTICS\nSTATISTICS\tCollation\tCOLLATION\f\340\0\4\0\0\0\375\0\0\0\0\0R\0\0\10\3def\22information_schema\nSTATISTICS\nSTATISTICS\vCardinality\vCARDINALITY\f?\0\25\0\0\0\10\0\0\0\0\0L\0\0\t\3def\22information_schema\nSTATISTICS\nSTATISTICS\10Sub_part\10SUB_PART\f?\0\3\0\0\0\10\0\0\0\0\0H\0\0\n\3def\22information_schema\nSTATISTICS\nSTATISTICS\6Packed\6PACKED\f\340\0(\0\0\0\375\0\0\0\0\0H\0\0\v\3def\22information_schema\nSTATISTICS\nSTATISTICS\4Null\10NULLABLE\f\340\0\f\0\0\0\375\1\0\0\0\0P\0\0\f\3def\22information_schema\nSTATISTICS\nSTATISTICS\nIndex_type\nINDEX_TYPE\f\340\0@\0\0\0\375\1\0\0\0\0J\0\0\r\3def\22information_schema\nSTATISTICS\nSTATISTICS\7Comment\7COMMENT\f\340\0@\0\0\0\375\0\0\0\0\0V\0\0\16\3def\22information_schema\nSTATISTICS”…, 33666, MSG_DONTWAIT, NULL, NULL) = 1265
1590503980.172482 gettimeofday({tv_sec=1590503980, tv_usec=172531}, NULL) = 0
1590503980.172791 gettimeofday({tv_sec=1590503980, tv_usec=172838}, NULL) = 0
1590503980.173086 sendto(3, “R\0\0\0\3ALTER TABLE wp_blc_instances MODIFY COLUMN link_text text NOT NULL DEFAULT ””, 86, MSG_DONTWAIT, NULL, 0) = 86
1590503980.173497 poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 1471228928) = ? ERESTART_RESTARTBLOCK (Interrupted by signal)
1590504245.813742 — SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} —
1590504246.116273 +++ killed by SIGINT +++`

Hopefully this helps!

User error: an SSL mixed content filter was to blame. Sorry for the noise.

This appears to be related to a call to api.zemanta.com (specifically https://api.zemanta.com/services/rest/0.0/), but that hostname/service no longer exists. The SE plugin does not properly handle the error, and that’s the reason you get:

Fatal error: Cannot use object of type WP_Error as array in /home1/markmuse2007/public_html/wordpress/wp-content/plugins/search-everything/search-everything.php on line 927

Unfortunately, I think the plugin authors are the only ones who will be able to actually fix this. Until then, you can edit search-everything.php and change lines 927–930 from:

    $response = json_decode($zemanta_response['body']);
    if (isset($response->status) && !is_wp_error($zemanta_response)) {
      $status = $response->status;
    }

to:

    if (!is_wp_error($zemanta_response)) {
      $response = json_decode($zemanta_response['body']);
      if (isset($response->status)) {
        $status = $response->status;
      }
    }

That should at least handle the error properly (though I’m still waiting on confirmation from our affected client). The Zemanta folks will need to chime in on the missing API.

Confirmed. Can we get a brown paper bag 2.2.4 release to revert this behavior? Or will we need to use the old version to get the plugin to work for now?

It looks like WP Rocket 2.9.3 dropped today and the Changelog indicates that the conflict with Move Login 2.4+ was addressed. We’ll report back if there are any further problems, but I suspect this one is resolved from our perspectve–thanks!

Peter

Hopefully it’s alright if I piggyback, but we had this problem for a few of our clients. It presented for us with a PHP Fatal error:

Using $this when not in object context in /home/$user/public_html/wp-content/plugins/sf-move-login/inc/classes/class-sfml-options.php:171

Looking at that code, it appears the problem is using this plugin in conjunction with WP Rocket, as line 171 is part of the get_slugs() function. However, WP Rocket calls that function STATICALLY:

$urls = array_merge( $urls, SFML_Options::get_slugs() );

which means, at least with PHP 7, using $this is a PHP Fatal. We downgraded to 2.3 as well and that resolved/sidestepped the problem. Hopefully that helps you sort out the problem as we’re otherwise extremely happy with this plugin.

Thanks!