Matthew Boynes

Hello @reelism,

There are no “settings” showing on the export page.

There are no settings for exporting, there are only settings for importing. Perhaps I’m misunderstanding you? If you mean you’re not seeing the plugin’s entry at all on the export page, the choice should read “Options”, not “Settings”. You can see this in the screenshot on the plugin page: https://ps.w.org/options-importer/assets/screenshot-1.png?rev=899744

If you are not seeing “Options” on the export page, it’s possible that another plugin is conflicting. If that’s the case, I would love to know what plugins and theme you have active.

Sorely in need of an update, any plans

Everything continues to work as advertised on the latest version of WordPress, 5.0.3, and there are no outstanding bug reports. I would therefore contend that it is not “sorely in need of an update”. I may update it in the near future to add a side-by-side comparison view as was pitched in another support thread, but that would be a new feature.

Thanks,
Matt

Hi Edir,
Contributions are welcome at https://github.com/alleyinteractive/options-importer. Thanks for using the plugin!

Cheers,
Matt

Great to hear, thanks!

Hi @ssuess, thanks for the report that ‘Export WordPress Menus’ conflicts. Can you confirm that with that disabled everything is working perfectly for you? On import you’re now able to select specific options as advertised?

Cheers,
Matt

No, there is no undo. The warning about overriding all options is quite explicit, that you should not do that unless you truly understand the consequences, because it would override the site’s URL.

Also worth noting that this plugin does not make any changes to the exporting site, so this would not affect your ability to login to that installation.

Thanks for the feature request! I moved it over to GitHub: https://github.com/alleyinteractive/options-importer/issues/7.

There would be no way to determine plugin vs. theme options, but we could do core vs. third party ones. I’ll consider this for a future update.

If the site is on WordPress.com VIP, yes, because the plugin is available for activation. Otherwise, there’s unfortunately no way to activate the plugin. You might submit a support request asking if there’s any way they can provide an export, and perhaps one of the Happiness Engineers can engineer some happiness for you. It’s a long shot, but since the plugin is available on WordPress.com VIP, it’s technically available. Never hurts to ask!

Best of luck!

Hi George,
Sorry for the delay. If you haven’t figured this out yet, the answer is to set the salt key in your wp-config.php file, e.g.:

define( 'WP_CACHE_KEY_SALT', 'site-1' );

The salt can be any string; I would advise making it descriptive of the site in some way, like the domain name.

Sorry for the delay in getting back to you.

This plugin should not be activated the normal way plugins get activated. It’s a very specific kind of WordPress plugin called a “drop-in”.

See step 1 in the instructions.

Hi carrie.marie,
In the demo code, you’ll see that the first lines are:

if ( ! class_exists( 'Super_Custom_Post_Type' ) ) {
    return;
}

This will prevent those errors.

You’re also seeing Warning: json_encode() expects exactly 1 parameter, 2 given in .../wp-content/plugins/options-importer/options-importer.php on line 213? If so, there’s no way that your code is running in PHP 5.4. You may have that option and it’s disabled, but the second parameter was added in PHP 5.3.0.

Yes, it would seem that you are using an old and outdated version of PHP. I accounted for this in one respect, but it didn’t occur to me that it would throw a warning and prevent the JSON from being written. I’ll be sure to update this to prevent that error with your version of PHP.

As an aside, I would recommend updating PHP if that’s within your control. While WordPress still works with your version of PHP, any version < 5.4 is no longer officially supported by The PHP Group and will no longer receives security patches, etc.

Very odd, I haven’t seen that happen anywhere. Do you happen to know what versions of WordPress and PHP you’re using? And if you have access to your PHP error log, I’d be interested to know if there’s any information in there. My hunch is that there’s a version incompatibility, though I’d need more information to confirm that.

Thanks,
Matt

Pragma and cache-control don’t apply to this plugin — or at least, they shouldn’t, so long as everyone is coding responsibly. And if one of your plugin or theme developers isn’t coding responsibly, you should not be using a persistent object cache.

This plugin is a replacement to WordPress’ built-in object cache, and with the exception of transients and bad code, nothing should get stored which isn’t automatically cleared when the original object changes. For instance, let’s say a WP_Post object is stored. When that post changes by way of a core function or method, the post is removed from the object cache. That’s all baked right into WordPress.

Exception #1: Transients may work a little differently. Depending on the code implementing a transient, it may have an expiration and it may not clear when the contents update. That’s up to the developer using the transient, and it would similarly be up to that developer to bypass the cache if pragma or cache-control headers request that the response not be cached. However, this plugin has no impact on that, because transients are guaranteed to persist. If you don’t use a persistent object cache, transients are stored in the database.

Exception #2: If a plugin or theme is updating objects using raw SQL, and not updating by way of core functions, then an object can persist in cache indefinitely. Pragma and cache-control headers have little relevance here, because if your application is bypassing core functions, a persistent object cache is simply not for you.

Specifically addressing your point, “Developer can’t easily refresh the cache contents,” if your developers aren’t seeing fresh content while using this plugin, and they are when not using this plugin, you should not use a persistent object cache at all in your application.

Two final points for posterity:

First, pragma and cache-control headers are mainly relevant for full-page caching, which this plugin doesn’t do. However, this plugin can be used alongside a plugin like Batcache to drive full-page caching. In that case, Batcache (or whichever plugin is implementing the full-page cache) can choose to respect those headers or not.

Second,

This might allow easier DOS of site, but I don’t think it’s that big of a problem.

Not true. Doing what you did in your fork would actually be a huge problem in terms of DOS vulnerability. When a persistent object cache is present, WordPress core’s basic non-persistent object cache doesn’t load. This means that all objects are fetched fresh, all the time. Consider this: if you call get_post( $post_id ) on the same post five times in the same request, it’s going to query mysql all 5 times (which will equate to, I think, 15 total database queries — 1 for the post, 1 for terms, and 1 for postmeta). This may not seem that significant, but that happens a lot — WordPress will probably have to do at least 100x more work to generate a page than it would out-of-the-box.

I hope this helps you out!

Excellent, glad to hear it!