Jeremy Felt

Hi everyone, thanks for reporting this issue and providing any information that you can. I’m trying to find a good way to reproduce this and/or figure out why the database table may not be created for some installs as part of https://core.trac.www.ads-software.com/ticket/46167.

There seems to be 2 separate issues:

1. A PHP notice generated because WordPress tries to use the wp_blogmeta table even though it doesn’t yet exist.
2. The wp_blogmeta table is not created.

We can fix the first issue pretty easily in WordPress by making sure we don’t try to use the table in this one case until the table is available.

Some correct ways to solve the second issue are:

1. Visit wp-admin/network/upgrade.php and click “Upgrade Network”. This triggers the global database upgrade.
2. Use WP-CLI to update the network DB: wp core update-db --network

Both of these should work as long as:

1. The site address is for the main site of the main network.
2. The DO_NOT_UPGRADE_GLOBAL_TABLES constant is not defined.
3. There is nothing filtering wp_should_upgrade_global_tables to false

I’m interested in knowing more about your environment if you’ve tried either of these options specifically and the database table is still not created. Please give me a ping and we can look at it closer.

Thanks!

@ivanbajalovic – I was able to reproduce your issue—I believe—and left a comment on the ticket explaining my thoughts.

I think your best long term solution here is to handle the setting of $current_site and $current_blog with expected data before loading wp-load.php.

Hi @ivanbajalovic. Can you provide a few more details so that I can try to reproduce this issue?

First, the path comparison should only be causing an issue if multisite is enabled with something like the MULTISITE constant. Can you confirm that this constant is set before you include wp-load.php?

When it does fail, what are the values for $current_site, $current_blog, $path, $domain, $_SERVER['REQUEST_URI'], and $_SERVER['HTTP_HOST']?

Something like this should do it:

<?php
include "../blog39/wp-load.php";
global $current_site, $current_blog, $path, $domain;
echo "<pre>";
var_dump( $current_site, $current_blog, $path, $domain, $_SERVER['REQUEST_URI'], $_SERVER['HTTP_HOST'] );
echo "<pre>";
?>

The following when added as a plugin or in your functions.php file will stop the TinyMCE portion of ZipList from loading while the developer sorts out the issues:

add_action( 'init', 'fys_remove_zlist_tinymce', 11 );
function fys_remove_zlist_tinymce() {
        remove_filter('mce_external_plugins', 'amd_zlrecipe_tinymce_plugin');
}

slampty, any word on which plugin may have been causing the issue?

This doesn’t sound like an issue related to Custom Posts Per Page. I believe the issue described is related to built in WordPress pages and categories. By default, categories cannot be assigned to Pages in WordPress, only to Posts.

The plugin is only able to handle new uploads. I haven’t given much thought to dealing with past images, though that would be an interesting problem to solve.

The plugin assigns the image as a featured image to the new post. At the time of upload it is a full size image, but themes that make use of post thumbnails/featured images will display the proper size. Inserting the URL directly into the content at the time of upload will not achieve the same effect. There may be a hook a bit later in the process when WordPress has generated the new sizes that could be used to help find a URL for the content, but I’m not sure if that can be used during the plugin’s portion of things.

AFIP does update the post meta on the newly created post with the post ID of the image – see code here. You could probably hook into update_post_meta at that point and look for any of the _thumbnail_id info to get what you need.

Closing as duplicate.

The plugin is designed to deal only with Featured Images, though filters are included that allow you to manipulate the data in any way. See the second FAQ here.

An example for modifying the category as images are uploaded can be found in the Filters in Automatic Featured Image Posts article.

I’m not aware of any specific issues, though anything with multiple automated parts should be done with care. The only way the two should mix is if the RSS posting is also uploading or sideloading images. At that point, they’ll be treated the same as an other upload by Automatic Featured Image Posts.

I don’t see any reason why not. The add_attachment action that Automatic Featured Image Posts hooks into runs whenever wp_insert_attachment() is fired, which happens both through the web interface and through the XML-RPC interface that is more than likely powering your third party software.

This is more than likely possible, though more of a display issue than an issue with the new post being created.

I would probably approach by specifying a category through the provided filter, then change the template based on the category. If you want to get more advanced, you could probably hook into the save_post action as it happens.