Riza Prihananto

Hi @lenasterg ,

We really appreciate you using our plugin and taking the time to leave such a great review!

Hi @delcour ,

Alright! Feel free to reach out if you need any further information. I’ll be happy to help with anything within our scope.

Hi @lenasterg ,

Thanks for reaching out, and great question! You’re right that clicking “Update Series Data” on every subsite by hand isn’t practical on a large multisite. The good news is this can be fully automated.

First, a quick note on what that button actually does: it’s a one-time data migration. It moves each post’s “series part” number from an old storage format to a new one (which is what enables the Multiple Series feature), then marks the site as done. There’s no official WP-CLI command built into the plugin for this, but because it’s purely a data operation, we can run the exact same process safely across your whole network using WP-CLI.

Here’s the recommended, safest way to do it.

Why WP-CLI (and not raw SQL): running it through WP-CLI means WordPress and the plugin stay fully loaded during the process, so all settings and caching are handled correctly for you. It’s also safe to run more than once; sites that are already updated are simply skipped.

Step 0: Update and network-activate the plugin.
Make sure PublishPress Series is updated to the latest version and Network Activated (Network Admin → Plugins), so it’s loaded on every subsite when the script runs.

Step 1: Connect to your server via SSH and go to your WordPress folder (the one containing wp-config.php). If you’re unsure how, your hosting provider can help you with SSH access.

Step 2: Upload the script. Place the attached file pps_migrate_series.php in that same WordPress folder.

<?php

/**

* pps_migrate_series.php

*

* Replicates PublishPress Series' "Update Series Data" button

* (publishpress_series_process_upgrade) for use via WP-CLI:

*

* wp eval-file pps_migrate_series.php

* wp site list --field=url | xargs -n1 -I % wp --url=% eval-file pps_migrate_series.php

*

* Idempotent: skips sites already migrated, and never overwrites an

* existing per-series meta value. Safe to re-run.

*/

global $wpdb;

// Already migrated on this site? (same flag the plugin checks)

if ( ! empty( get_option( 'publishpress_multi_series_supported' ) ) ) {

WP_CLI::log( sprintf( '[%s] already migrated — skipping.', home_url() ) );

return;

}

// Old single-series meta key (SERIES_PART_KEY). Use the constant if the

// plugin is loaded, otherwise fall back to its literal default value.

$part_key = defined( 'SERIES_PART_KEY' ) ? SERIES_PART_KEY : '_series_part';

// Series taxonomy slug (option, default 'series').

if ( function_exists( 'ppseries_get_series_slug' ) ) {

$taxonomy = ppseries_get_series_slug();

} else {

$slug = get_option( 'pp_series_taxonomy_slug' );

$taxonomy = ( is_string( $slug ) && trim( $slug ) !== '' ) ? $slug : 'series';

}

// Same query the button's handler runs.

$query = $wpdb->prepare(

"SELECT p.ID, t.term_id, pm.meta_value

FROM {$wpdb->posts} AS p

LEFT JOIN {$wpdb->postmeta} AS pm ON p.ID = pm.post_id

LEFT JOIN {$wpdb->term_relationships} AS tr ON p.ID = tr.object_id

LEFT JOIN {$wpdb->term_taxonomy} AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id

LEFT JOIN {$wpdb->terms} AS t ON tt.term_id = t.term_id

WHERE pm.meta_key = %s

AND tt.taxonomy = %s",

$part_key,

$taxonomy

);

$posts = $wpdb->get_results( $query );

$migrated = 0;

if ( ! empty( $posts ) ) {

foreach ( $posts as $post ) {

if ( empty( $post->term_id ) ) {

continue; // post has the meta but no series term — leave as-is

}

$new_key = $part_key . '_' . $post->term_id;

if ( empty( get_post_meta( $post->ID, $new_key, true ) ) ) {

add_post_meta( $post->ID, $new_key, $post->meta_value );

}

delete_post_meta( $post->ID, $part_key );

$migrated++;

}

}

// Same flags the handler sets.

update_option( 'publishpress_multi_series_supported', true );

update_option( 'os_multi_import', true );

WP_CLI::success( sprintf( '[%s] migration complete — %d post/series entries moved.', home_url(), $migrated ) );

Step 3: Back up your database first (please don’t skip this). This is your safety net:

wp db export backup-before-series-migration.sql

Step 4: Test on ONE subsite first. Replace the URL with a real subsite address:

wp --url=https://your-subsite.com eval-file pps_migrate_series.php

Then open that subsite and confirm the series part numbers still display correctly and the “Update Series Data” notice is gone.

Step 5: Run it across the entire network. Once the test looks good:

wp site list --field=url | xargs -n1 -I % wp --url=% eval-file pps_migrate_series.php

Step 6: Check the results. Each site prints either “migration complete” or “already migrated, skipping.” If every site shows one of those with no errors, you’re done.

The script does exactly what the button does, just automatically and network-wide, and it’s safe to re-run. The two steps we’d really encourage you not to skip are the database backup (Step 3) and the single-site test (Step 4).

If you don’t have SSH/WP-CLI access, let us know and we’ll help you find another route.

Hi @wpsi1 ,

Thank you for reporting this issue. I can confirm this on my end.

I’ve escalated it to our developer for further investigation. It may take some time to resolve, but you can follow the progress of the investigation through our GitHub issue:

https://github.com/publishpress/publishpress-blocks/issues/1863

Hi @delcour ,

Thank you for using PublishPress Future. Could you check whether you’re selecting the date on the correct calendar? There are actually two calendars in the WordPress editor.

The upper calendar is used to schedule the post’s publication. If you select a future date there, the button will show “Scheduled” instead of “Published.” Therefore, if you want to immediately publish the post, you can select “Now” on the calendar.

The lower calendar is used to schedule the Future Action, for example, when the post should be deleted in the future. You can select the deletion date using this calendar:

Screenshot