[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$ftIWs-cRC2-ih7GHVkG4anOEESfnnGUPyywgawuu8Dgs":3,"$fumG_8OBVX1XjMMGpEJRBG6rzZT3T7mqjfzmHdHhNOdc":129,"$fnMC-7n3RlAhkKeDNAqgS1sIXRwptJ0ktKBH3V1NuLjY":134},{"slug":4,"name":5,"version":6,"author":7,"author_profile":8,"description":9,"short_description":10,"active_installs":11,"downloaded":12,"rating":11,"num_ratings":11,"last_updated":13,"tested_up_to":14,"requires_at_least":15,"requires_php":16,"tags":17,"homepage":23,"download_link":24,"security_score":25,"vuln_count":11,"unpatched_count":11,"last_vuln_date":26,"fetched_at":27,"discovery_status":28,"vulnerabilities":29,"developer":30,"crawl_stats":26,"alternatives":35,"analysis":26,"fingerprints":26},"spawnwp-deploy","SpawnWP Deploy","0.3.4","wpvoicer","https:\u002F\u002Fprofiles.wordpress.org\u002Fwpvoicer\u002F","\u003Cp>SpawnWP Deploy provides two administrator-initiated workflows:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Capture a configured WordPress site as a reusable blueprint on a self-hosted SpawnWP server.\u003C\u002Fli>\n\u003Cli>Publish a finished site once to a separate, fresh WordPress installation.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>It is not a continuous staging or synchronization system. Site-to-site deployment is\u003Cbr \u002F>\nlimited to an empty destination and keeps rollback data for seven days. Connections use\u003Cbr \u002F>\nsingle-use pairing codes, signed requests and replay protection.\u003C\u002Fp>\n\u003Cp>For blueprint capture, the administrator chooses whether to include plugins, themes,\u003Cbr \u002F>\nuploads and database content. WordPress users and user metadata are excluded. The source\u003Cbr \u002F>\nsite URL is replaced with a fixed placeholder in captured database content, and each site\u003Cbr \u002F>\ncreated from the blueprint receives its own administrator credentials.\u003C\u002Fp>\n\u003Ch4>Requirements\u003C\u002Fh4>\n\u003Cul>\n\u003Cli>WordPress single-site.\u003C\u002Fli>\n\u003Cli>PHP 7.4 or later with the Sodium and ZIP extensions.\u003C\u002Fli>\n\u003Cli>HTTPS with a publicly trusted certificate on paired endpoints.\u003C\u002Fli>\n\u003Cli>A reachable WordPress REST API without an additional HTTP password.\u003C\u002Fli>\n\u003Cli>Write access to the WordPress plugin, theme and uploads directories.\u003C\u002Fli>\n\u003Cli>Sufficient free disk space for staging and rollback data.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Always back up important sites before using deployment or capture tools.\u003C\u002Fp>\n\u003Ch3>External Connections\u003C\u002Fh3>\n\u003Cp>This plugin does not contact a SpawnWP-operated SaaS platform and does not send telemetry\u003Cbr \u002F>\nto SpawnWP merely because it is installed, activated or loaded.\u003C\u002Fp>\n\u003Cp>An administrator can explicitly pair the plugin with either:\u003C\u002Fp>\n\u003Col>\n\u003Cli>another WordPress site running SpawnWP Deploy; or\u003C\u002Fli>\n\u003Cli>a self-hosted SpawnWP server whose URL is supplied by the administrator.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>During a requested deployment or capture, the plugin sends the selected package and\u003Cbr \u002F>\ntechnical metadata to that administrator-selected endpoint. Depending on the selected\u003Cbr \u002F>\noptions, this can include plugin and theme files, media uploads, database content,\u003Cbr \u002F>\nWordPress and PHP versions, plugin names and versions, package checksums, job identifiers\u003Cbr \u002F>\nand connection signatures. WordPress user and user-meta tables are excluded.\u003C\u002Fp>\n\u003Cp>The remote endpoint is operated by the site administrator or their chosen provider. Its\u003Cbr \u002F>\nprivacy and retention practices are therefore controlled by that operator. SpawnWP is\u003Cbr \u002F>\nself-hosted open-source software distributed under the MIT License:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>SpawnWP project: https:\u002F\u002Fspawnwp.com\u002F\u003C\u002Fli>\n\u003Cli>Source code and license: https:\u002F\u002Fgithub.com\u002Ftts-empire\u002Fspawnwp\u003C\u002Fli>\n\u003Cli>Security documentation: https:\u002F\u002Fspawnwp.com\u002Fdocs\u002Fsecurity\u002F\u003C\u002Fli>\n\u003Cli>Optional SpawnWP platform telemetry notice: https:\u002F\u002Fspawnwp.com\u002Fprivacy\u002Ftelemetry\u002F\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>When the plugin inventory is displayed and WordPress does not already have cached update\u003Cbr \u002F>\ninformation for an active plugin, SpawnWP Deploy may query the WordPress.org Plugins API\u003Cbr \u002F>\nusing WordPress core’s \u003Ccode>plugins_api()\u003C\u002Fcode> function. It sends the plugin slug and uses the\u003Cbr \u002F>\nresponse only to classify the plugin as WordPress.org-hosted or custom. The result is\u003Cbr \u002F>\ncached for one day. WordPress.org privacy policy: https:\u002F\u002Fwordpress.org\u002Fabout\u002Fprivacy\u002F\u003C\u002Fp>\n","Capture a configured site as a reusable blueprint, or publish it once to a separate empty WordPress installation.",0,125,"2026-07-20T09:33:00.000Z","7.0.2","6.8","7.4",[18,19,20,21,22],"blueprint","deployment","development","migration","staging","https:\u002F\u002Fspawnwp.com\u002Fdocs\u002Fwordpress-development\u002F","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fspawnwp-deploy.0.3.4.zip",100,null,"2026-07-22T17:31:50.256Z","no_bundle",[],{"slug":7,"display_name":7,"profile_url":8,"plugin_count":31,"total_installs":11,"avg_security_score":25,"avg_patch_time_days":32,"trust_score":33,"computed_at":34},2,30,94,"2026-08-29T00:50:12.016Z",[36,57,78,97,113],{"slug":37,"name":38,"version":39,"author":40,"author_profile":41,"description":42,"short_description":43,"active_installs":25,"downloaded":44,"rating":25,"num_ratings":31,"last_updated":45,"tested_up_to":46,"requires_at_least":47,"requires_php":48,"tags":49,"homepage":52,"download_link":53,"security_score":54,"vuln_count":55,"unpatched_count":11,"last_vuln_date":56,"fetched_at":27},"the-permalinker","The Permalinker","1.9.0","Andy Stratton","https:\u002F\u002Fprofiles.wordpress.org\u002Ftheandystratton\u002F","\u003Cp>Use short codes to dynamically link to your WordPress pages and posts. All you need is the ID. This can come in handy when developing content for WordPress sites. Makes for a cleaner migration with no need to manipulate content when moving from one subdirectory or domain to another.\u003C\u002Fp>\n\u003Cp>Attributes of \u003Ccode>append\u003C\u002Fcode> \u003Ccode>class\u003C\u002Fcode>, \u003Ccode>rel\u003C\u002Fcode>, and \u003Ccode>target\u003C\u002Fcode> are supported within the \u003Ccode>[permalink]\u003C\u002Fcode> opening tag. See FAQs. You can insert the token \u003Ccode>%post_title%\u003C\u002Fcode> to dynamically insert the post’s title into anchor text (content between the opening and closing shortcode).\u003C\u002Fp>\n\u003Cp>A short code for \u003Ccode>[template_uri]\u003C\u002Fcode> exists if you’d like to dynamically grab the full URL to your current template directory (useful for adding images and other resources bundled in a template via the page\u002Fpost editor).\u003C\u002Fp>\n\u003Cp>\u003Cem>Example 1: Create link.\u003C\u002Fem>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>[permalink id=2 rel=\"internal\"]Check out my latest post named %post_title%[\u002Fpermalink] or use `[permalink]this link[\u002Fpermalink]` to link to this post.\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cem>Example 2: Output Permalink URL.\u003C\u002Fem>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u003Ca href=\"[permalink]\">;This post.\u003C\u002Fa>;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cem>Example 3: Template Directory URI\u003C\u002Fem>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u003Cimg src=\"[template_uri]\u002Fphotos\u002Fme_grandma.jpg\" alt=\"A Photo of Me and My Grandma\" \u002F>\n\u003C\u002Fcode>\u003C\u002Fpre>\n","Use short codes to dynamically link to your WordPress pages and posts. All you need is the ID. This can come in handy when developing content for Word …",12849,"2024-12-13T20:33:00.000Z","6.4.8","2.6","",[20,50,21,51,22],"linking","permalinks","http:\u002F\u002Ftheandystratton.com\u002F2009\u002Fthe-permalinker-wordpress-plugin-dynamic-permalinks","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fthe-permalinker.1.9.0.zip",91,1,"2024-12-13 15:58:35",{"slug":58,"name":59,"version":60,"author":61,"author_profile":62,"description":63,"short_description":64,"active_installs":65,"downloaded":66,"rating":33,"num_ratings":67,"last_updated":68,"tested_up_to":69,"requires_at_least":70,"requires_php":48,"tags":71,"homepage":74,"download_link":75,"security_score":76,"vuln_count":11,"unpatched_count":11,"last_vuln_date":26,"fetched_at":77},"sitepush","SitePush","0.4.2","Mark Rowatt Anderson","https:\u002F\u002Fprofiles.wordpress.org\u002Fmarkauk\u002F","\u003Cp>SitePush is a WordPress plugin which allows you to have multiple versions of your WordPress site, so you can edit, develop, test without any risk to your main, live site. It’s great for developers, designers and editors… anyone who wants to be able to test changes to a site before it is visible to the world. For example:-\u003C\u002Fp>\n\u003Col>\n\u003Cli>you can \u003Cstrong>easily move content between sites\u003C\u002Fstrong>. For example, make extensive edits on a private staging site, and then push changes all at once to your live site. Or, easily pull copy of your live database into your development site so you are developing against the latest content.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>test new themes and plugins\u003C\u002Fstrong>, and only push them to your live site once they are configured and working as you want.\u003C\u002Fli>\n\u003Cli>upgrade WordPress, themes and plugins on a private site so you can \u003Cstrong>test that nothing breaks before upgrading your live site\u003C\u002Fstrong>. Sure you take backups before any upgrades (right?), but it’s a pain doing a full backup and an even bigger pain restoring from a backup.\u003C\u002Fli>\n\u003Cli>easily make small (and big!) code changes on your development site, \u003Cstrong>test and easily push new code to a live site\u003C\u002Fstrong>. Great for dealing with clients who want “just one more thing”.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Although SitePush installation is a bit more involved than a typical plugin, once set up it runs with minimal effort and can be easily used by non-tech authors & editors. Site admins can easily configure SitePush so that non-admins can only push content (i.e. posts\u002Fpages, comments and uploads) and to a restricted set of sites.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Please read the \u003Cem>Installation\u003C\u002Fem> instructions before you install SitePush – it’s not a normal download and activate type of plugin installation\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch4>Support\u003C\u002Fh4>\n\u003Cp>SitePush is under active development and I will do my best to provide fixes to problems. The latest general releases are always available through the WordPress Plugins Directory. Development code is \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Frowatt\u002Fsitepush\u002Ftree\u002Fdevelop\" rel=\"nofollow ugc\">hosted on GitHub\u003C\u002Fa>, so you may find more frequent releases there.\u003C\u002Fp>\n\u003Cp>For general questions, please post on the WordPress forums with the tag sitepush. For bug reports or if you wish to suggest patches or fixes, please go to the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Frowatt\u002Fsitepush\" rel=\"nofollow ugc\">SitePush GitHub repository\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>If you have any problems with SitePush, it would be helpful if you could add\u003C\u002Fp>\n\u003Cpre>\u003Ccode>define('SITEPUSH_DEBUG',TRUE);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>to your wp-config.php file, and include the output which will now be displayed at the top of the SitePush options screen.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Disclaimer\u003C\u002Fstrong> Although SitePush has been well tested and is used on production web sites, it moves files and database content between sites which could break things. Use of SitePush is at your own risk! Please make sure you have adequate backups and if you do find any problems please report them.\u003C\u002Fp>\n\u003Ch4>Roadmap\u003C\u002Fh4>\n\u003Cp>There are a number of areas which could be improved. Currently on the roadmap:-\u003C\u002Fp>\n\u003Cul>\n\u003Cli>improve push undo\u003C\u002Fli>\n\u003Cli>add support for pushing between sites on different servers\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Please let me know how you would like to see SitePush evolve.\u003C\u002Fp>\n\u003Ch3>Server Setup\u003C\u002Fh3>\n\u003Ch4>How to setup SitePush in a multiple vhost environment\u003C\u002Fh4>\n\u003Cp>You can run your separate versions of a site in a single vhost, or in separate vhosts. While running them all in a single vhost can be little easier to set up on some web hosts, it does not work well if different sites need any different configuration in your .htaccess file – for example if you are using a caching plugin.\u003C\u002Fp>\n\u003Cp>If you are able to set up separate vhosts (or subdomains as some hosts call them) I recommend you do it that way.\u003C\u002Fp>\n\u003Cp>Let’s say you want to have three versions of your site – live, test, and dev.\u003C\u002Fp>\n\u003Cp>Set up a vhost for each site. Where they all sit on your server will depend on your hosting setup, but let’s say they are at:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fvhosts\u002Flive\u002Fhttpdocs\n\u002Fvar\u002Fwww\u002Fvhosts\u002Ftest\u002Fhttpdocs\n\u002Fvar\u002Fwww\u002Fvhosts\u002Fdev\u002Fhttpdocs\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You will need to create a directory to hold all the config files. If at all possible, this directory should not be web accessible. For example, it might be at:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fsitepush\u002Fconfig\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You will also probably want to create a directory for any backups SitePush makes, such as:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fsitepush\u002Fbackups\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Finally, you will need to create a database for each of your sites. Consult the \u003Ca href=\"https:\u002F\u002Fcodex.wordpress.org\u002FInstalling_WordPress\" rel=\"nofollow ugc\">WordPress installation instructions\u003C\u002Fa> and your web host for how to do this.\u003C\u002Fp>\n\u003Cp>Download WordPress and unzip it into one of your sites. I normally keep WordPress in its own subdirectory, for example:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fvhosts\u002Flive\u002Fhttpdocs\u002Fwordpress\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>That way, the root directory stays clean, and if I install anything else outside of WordPress, there won’t be any confusion of which files belong where. You need to make a couple of changes for this setup to work – see \u003Ca href=\"https:\u002F\u002Fcodex.wordpress.org\u002FGiving_WordPress_Its_Own_Directory\" rel=\"nofollow ugc\">WordPress documentation\u003C\u002Fa> for more details. Note that for multisite installs, though, you will need to install WordPress in the root directory.\u003C\u002Fp>\n\u003Cp>I do, however, put my wp-config.php file in the root directory (WordPress is smart enough to find it).\u003C\u002Fp>\n\u003Cp>Next you will need to create the SitePush config files and put them in the config directory you created above. See \u003Ca href=\"https:\u002F\u002Fwordpress.org\u002Fextend\u002Fplugins\u002Fsitepush\u002Finstallation\" rel=\"ugc\">the SitePush installation instructions\u003C\u002Fa> for what needs to go in your sites config file and your database config file (I usually call them sites.ini.php and dbs.ini.php).\u003C\u002Fp>\n\u003Cp>Now, copy the files from the site you just set up to your other sites, for example:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>cd \u002Fvar\u002Fwww\u002Fvhosts\ncp -r live\u002Fhttpdocs dev\u002Fhttpdocs\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>To save a bit of disk space (at the expense of possibly messing things up between sites), you can also symlink the uploads directory between sites so there is only one copy of any media files uploaded. For example:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>cd \u002Fvar\u002Fwww\u002Fvhosts\u002Fdev\u002Fhttpdocs\u002Fwordpress\u002Fwp-content\nrmdir uploads\nln -s ..\u002F..\u002F..\u002F..\u002Flive\u002Fhttpdocs\u002Fwordpress\u002Fwp-content\u002Fuploads uploads\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The exact paths will depend on your setup.\u003C\u002Fp>\n\u003Cp>Finally, log into your live site, install, activate and configure SitePush, and now you are set up to easily move files and content between 3 versions of your site!\u003C\u002Fp>\n\u003Ch4>How to setup SitePush in a single vhost\u003C\u002Fh4>\n\u003Cp>You can run your separate versions of a site in a single vhost, or in separate vhosts. Depending on your web host, running them all in a single vhost can be bit easier to set up, though it does mean you need to share one .htaccess file across all versions of your site, and won’t work for WordPress Multisite setups.\u003C\u002Fp>\n\u003Cp>If you are able to set up separate vhosts (or subdomains as some hosts call them) I recommend you do it that way, but if not, these instructions show how you can have multiple version so of your site on one vhost.\u003C\u002Fp>\n\u003Cp>Let’s say you want to have three versions of your site – live, test, and dev.\u003C\u002Fp>\n\u003Cp>First make sure that you can set up domain aliases on your host – so that multiple domains point to the same files. For example, you might set up:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>live.example.com\ntest.example.com\ndev.example.com\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>If your host allows wildcard domain setups, so for example anything.example.com would point to your files, that would also work\u003C\u002Fp>\n\u003Cp>Set up a subdirectory for each site. Where they all sit on your server will depend on your hosting setup, but let’s say they are at:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fhttpdocs\u002Flive\n\u002Fvar\u002Fwww\u002Fhttpdocs\u002Ftest\n\u002Fvar\u002Fwww\u002Fhttpdocs\u002Fdev\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You will need to create a directory to hold all the config files. If at all possible, this directory should not be web accessible. For example, it might be at:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fsitepush\u002Fconfig\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You will also probably want to create a directory for any backups SitePush makes, such as:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fsitepush\u002Fbackups\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Download WordPress and unzip it into one of the directories for your sites. For example:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>\u002Fvar\u002Fwww\u002Fhttpdocs\u002Flive\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Follow the \u003Ca href=\"https:\u002F\u002Fcodex.wordpress.org\u002FGiving_WordPress_Its_Own_Directory\" rel=\"nofollow ugc\">instructions\u003C\u002Fa> for more installing WordPress in a subdirectory.\u003C\u002Fp>\n\u003Cp>You should also now create a database for each of your sites. Consult the \u003Ca href=\"https:\u002F\u002Fcodex.wordpress.org\u002FInstalling_WordPress\" rel=\"nofollow ugc\">WordPress installation instructions\u003C\u002Fa> and your web host for how to do this.\u003C\u002Fp>\n\u003Cp>Complete any other required configuration (WordPress setup, plugin installs etc) and make sure that your site is now working properly. Don’t forget to install SitePush!\u003C\u002Fp>\n\u003Cp>Next you need to create the SitePush config files and put them in the config directory you created above. See here readme.txt or \u003Ca href=\"https:\u002F\u002Fwordpress.org\u002Fextend\u002Fplugins\u002Fsitepush\u002Finstallation\" rel=\"ugc\">the SitePush installation instructions\u003C\u002Fa> for what needs to go in your sites config file and your database config file (I usually call them sites.ini.php and dbs.ini.php).\u003C\u002Fp>\n\u003Cp>Now, copy the files from the site you just set up to your other sites, for example:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>cd \u002Fvar\u002Fwww\u002Fhttpdocs\ncp -r live dev\ncp -r live test\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>To save a bit of disk space (at the expense of possibly messing things up between sites), you can also symlink the uploads directory between sites so there is only one copy of any media files uploaded. For example:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>cd \u002Fvar\u002Fwww\u002Fhttpdocs\u002Fdev\u002Fwp-content\nrmdir uploads\nln -s ..\u002F..\u002Flive\u002Fwp-content\u002Fuploads uploads\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>The exact paths will depend on your setup.\u003C\u002Fp>\n\u003Cp>Next you need to make some changes to your wp-config.php file so that it will point to the correct site files and database depending on what domain name was used. The exact details will vary depending on your setup, but you will want something like this, which should be inserted immediately above the line \u003Ccode>\u002F* That's all, stop editing! Happy blogging. *\u002F\u003C\u002Fcode>:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>switch ( $_SERVER['SERVER_NAME'] ) {\n    case 'test.example.com':\n        $site_dir='test';\n        define('DB_NAME', 'database_name_here');\n        define('DB_USER', 'username_here');\n        define('DB_PASSWORD', 'password_here');\n        break;\n\n    case 'dev.example.com':\n        define('DB_NAME', 'database_name_here');\n        define('DB_USER', 'username_here');\n        define('DB_PASSWORD', 'password_here');\n        $site_dir='dev';\n        break;\n\n    case 'www.example.com':\n    case 'live.example.com':\n    default:\n        define('DB_NAME', 'database_name_here');\n        define('DB_USER', 'username_here');\n        define('DB_PASSWORD', 'password_here');\n        $site_dir='live';\n        break;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Insert whatever constant definitions are specific to a site in that section, and delete or comment them out from their original location in wp-config.\u003C\u002Fp>\n\u003Cp>Lastly, you need to edit the last line of wp-config so it reads:-\u003C\u002Fp>\n\u003Cpre>\u003Ccode>require(\".\u002F{$site_dir}\u002Fwp-blog-header.php\");\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>You can now log into your live site, activate and configure SitePush. Once that is done, you can push everything to your other sites and you should now be able to access all three versions of your site. You are now set up to easily move files and content between 3 versions of your site!\u003C\u002Fp>\n","Easily move content and code between WordPress sites. Pull your site's DB to a dev site, push new code to a staging site, etc.",20,10596,15,"2013-09-09T14:17:00.000Z","3.6.1","3.3.1",[19,20,72,21,73],"migrate","move","http:\u002F\u002Frowatt.com\u002Fsitepush","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fsitepush.0.4.2.zip",85,"2026-04-16T10:56:18.058Z",{"slug":79,"name":80,"version":81,"author":82,"author_profile":83,"description":84,"short_description":85,"active_installs":86,"downloaded":87,"rating":11,"num_ratings":11,"last_updated":88,"tested_up_to":89,"requires_at_least":90,"requires_php":48,"tags":91,"homepage":94,"download_link":95,"security_score":76,"vuln_count":11,"unpatched_count":11,"last_vuln_date":26,"fetched_at":96},"deploy-helper","Deploy Helper","0.6","topdrawinc","https:\u002F\u002Fprofiles.wordpress.org\u002Ftopdrawinc\u002F","\u003Cp>Simplify the process of deploying a website. If you ever worked on a WordPress site on a local environment, you know how frustrating it can be to move it to different servers.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Ca href=\"http:\u002F\u002Fwww.topdraw.com\u002Fnews\u002Fwp-plugin-deploy-helper\u002F\" title=\"Top Draw home page\" rel=\"nofollow ugc\">Plugin home page\u003C\u002Fa>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Ca href=\"https:\u002F\u002Fwordpress.org\u002Ftags\u002Ftd-deployhelper\u002F\" title=\"Forum \u002F Support\" rel=\"ugc\">Forum \u002F Support\u003C\u002Fa>\u003C\u002Fstrong>\u003C\u002Fp>\n","Simplify the process of deploying a website. If you ever worked on a Wordpress site on a local environment, you know how frustrating it can be to move …",10,3589,"2012-06-05T22:13:00.000Z","3.3.2","2.9.0",[19,20,92,93,22],"hosting","paths","http:\u002F\u002Fwww.topdraw.com\u002Fnews\u002Fwp-plugin-deploy-helper\u002F","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fdeploy-helper.0.6.zip","2026-04-06T09:54:40.288Z",{"slug":98,"name":99,"version":100,"author":101,"author_profile":102,"description":103,"short_description":104,"active_installs":11,"downloaded":105,"rating":11,"num_ratings":11,"last_updated":106,"tested_up_to":14,"requires_at_least":107,"requires_php":16,"tags":108,"homepage":111,"download_link":112,"security_score":25,"vuln_count":11,"unpatched_count":11,"last_vuln_date":26,"fetched_at":27},"migro-content-migrator","Migro – Content Migration & Deployment","2.5.2","migro","https:\u002F\u002Fprofiles.wordpress.org\u002Fmigro\u002F","\u003Cp>You changed one post. Why clone the whole site?\u003C\u002Fp>\n\u003Cp>Traditional WordPress migration plugins were built for moving hosts: export the database, overwrite production, hope nothing breaks.\u003C\u002Fp>\n\u003Cp>Migro was built for editorial deployment.\u003C\u002Fp>\n\u003Cp>Push individual posts and pages between staging and production without touching the rest of the live site. Deploy exactly what changed (including media, taxonomies, metadata, and author attribution) and leave everything else untouched.\u003C\u002Fp>\n\u003Cp>Built for agencies, publishers, freelancers, and editorial teams running real staging workflows.\u003C\u002Fp>\n\u003Ch4>What Migro does\u003C\u002Fh4>\n\u003Cp>Migro is a selective WordPress migration plugin that deploys content between environments. Choose a post or page, click Push, and Migro transfers only that content and its dependencies:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Post content, excerpts, slugs, statuses, dates, comment status, and ping status\u003C\u002Fli>\n\u003Cli>Categories and tags with hierarchy preservation\u003C\u002Fli>\n\u003Cli>Featured images and embedded media\u003C\u002Fli>\n\u003Cli>Image alt text, kept in sync between the Media Library and post content\u003C\u002Fli>\n\u003Cli>Custom fields and post meta\u003C\u002Fli>\n\u003Cli>Author attribution (falls back to the deploying admin if the source author does not exist on the destination)\u003C\u002Fli>\n\u003Cli>Attached PDFs, videos, and inline assets\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Pull works the same way in reverse, syncing live content back into staging for testing and revision.\u003C\u002Fp>\n\u003Ch4>Why Migro exists\u003C\u002Fh4>\n\u003Cp>Site-migration tools solve infrastructure problems. Migro solves editorial workflow problems.\u003C\u002Fp>\n\u003Cp>Most WordPress teams do not want to:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>clone production databases\u003C\u002Fli>\n\u003Cli>overwrite unrelated content\u003C\u002Fli>\n\u003Cli>freeze publishing workflows\u003C\u002Fli>\n\u003Cli>manually recreate approved edits\u003C\u002Fli>\n\u003Cli>risk breaking live sites for a single article update\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>They just want to safely deploy finished content. Migro is built specifically for that workflow.\u003C\u002Fp>\n\u003Ch4>Built for staging-to-production workflows\u003C\u002Fh4>\n\u003Cp>Whether you are an agency managing client sites or a publisher coordinating editors and reviewers, Migro fits directly into modern WordPress workflows.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Selective deployment.\u003C\u002Fstrong> Deploy individual posts and pages instead of cloning entire sites.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Push and Pull synchronization.\u003C\u002Fstrong> Push staging changes to production or pull live content back into staging.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sync-key tracking.\u003C\u002Fstrong> Re-deployments update existing content in place, even if slugs or IDs changed between environments.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Safe overwrite protection.\u003C\u002Fstrong> Every overwrite creates a local backup before deployment, with one-click restore.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Editor-friendly permissions.\u003C\u002Fstrong> Editors can deploy approved content without requiring Administrator access.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Unlimited deployments.\u003C\u002Fstrong> No monthly caps, throttles, or upgrade prompts.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4>Headline features\u003C\u002Fh4>\n\u003Cul>\n\u003Cli>Selective Push and Pull between WordPress environments\u003C\u002Fli>\n\u003Cli>Sync-key redeployment without duplicate posts\u003C\u002Fli>\n\u003Cli>Automatic backups before overwrite operations\u003C\u002Fli>\n\u003Cli>Migration logs with per-item status tracking\u003C\u002Fli>\n\u003Cli>Encrypted credential storage at rest\u003C\u002Fli>\n\u003Cli>Media deduplication using MD5 hashing\u003C\u002Fli>\n\u003Cli>Local development support including Local by WP Engine\u003C\u002Fli>\n\u003Cli>REST API authentication using Application Passwords\u003C\u002Fli>\n\u003Cli>Direct database transport for reliability\u003C\u002Fli>\n\u003Cli>Multilingual support (English, Brazilian Portuguese, Spanish)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4>Smart page builder detection\u003C\u002Fh4>\n\u003Cp>Modern page builders store layouts as serialized data containing environment-specific URLs and generated assets. Unsafe migrations can corrupt layouts or break rendering.\u003C\u002Fp>\n\u003Cp>Migro detects content created with Elementor, Divi, Beaver Builder, Bricks, Oxygen, Breakdance, Droip, and WPBakery. The free version warns before deployment when builder content is detected, so a deployment cannot silently break a destination layout.\u003C\u002Fp>\n\u003Cp>Migro Pro adds serialized data rewriting, safe builder migration, CSS regeneration, and environment-aware asset handling.\u003C\u002Fp>\n\u003Ch4>AI-powered alt text\u003C\u002Fh4>\n\u003Cp>Migro can generate alt text for images missing accessibility metadata using the WordPress 7.0 AI Connector and your own provider account.\u003C\u002Fp>\n\u003Cp>Supported providers: Anthropic, OpenAI, and Google Gemini.\u003C\u002Fp>\n\u003Cp>Existing alt text is never overwritten. Requests are sent directly from your WordPress site to the provider using your own API key. Migro never proxies the call and never sees your key.\u003C\u002Fp>\n\u003Ch4>Built for production use\u003C\u002Fh4>\n\u003Cul>\n\u003Cli>\u003Cstrong>Conflict handling.\u003C\u002Fstrong> Choose between Overwrite (update existing content in place) and Skip (leave existing destination content untouched).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Reliable backups.\u003C\u002Fstrong> Stored locally before overwrite operations and retained for 30 days by default.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Deployment logging.\u003C\u002Fstrong> Review successful, skipped, and failed deployments with detailed error reporting and retry support.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Secure credential handling.\u003C\u002Fstrong> Database credentials are encrypted before being stored in the WordPress options table.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Local development support.\u003C\u002Fstrong> Custom sockets, SSL verification toggles, and configurable timeouts for local and hybrid environments.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4>How Migro compares to site-migration plugins\u003C\u002Fh4>\n\u003Cp>Traditional migration plugins move entire WordPress installations. Migro deploys content changes.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Scope.\u003C\u002Fstrong> Traditional tools clone the full database. Migro deploys only the selected content.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Workflow.\u003C\u002Fstrong> Traditional tools run a one-shot host migration. Migro supports continuous editorial deployment.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Side effects.\u003C\u002Fstrong> Traditional tools overwrite entire environments. Migro leaves unrelated content untouched.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Direction.\u003C\u002Fstrong> Traditional tools are one-way import\u002Fexport. Migro is bidirectional Push and Pull synchronization.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Re-runs.\u003C\u002Fstrong> Traditional re-imports create duplicates. Migro uses sync-keys to update content in place.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Focus.\u003C\u002Fstrong> Traditional tools are infrastructure-focused. Migro is editorial-workflow-focused.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4>How it works\u003C\u002Fh4>\n\u003Col>\n\u003Cli>Install Migro on both WordPress environments\u003C\u002Fli>\n\u003Cli>Connect staging and production using the setup wizard\u003C\u002Fli>\n\u003Cli>Select the posts or pages to deploy\u003C\u002Fli>\n\u003Cli>Click Push or Pull\u003C\u002Fli>\n\u003Cli>Review the deployment summary\u003C\u002Fli>\n\u003Cli>Restore from backup instantly if needed\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>No command line required. WP-CLI is available in Migro Pro for automation and CI\u002FCD pipelines.\u003C\u002Fp>\n\u003Ch4>Migro Pro\u003C\u002Fh4>\n\u003Cp>Migro Pro adds advanced workflow and commerce support:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Custom Post Types\u003C\u002Fli>\n\u003Cli>Advanced Custom Fields (ACF)\u003C\u002Fli>\n\u003Cli>Yoast SEO migration\u003C\u002Fli>\n\u003Cli>WooCommerce products and variations\u003C\u002Fli>\n\u003Cli>Scheduled migrations\u003C\u002Fli>\n\u003Cli>WP-CLI support\u003C\u002Fli>\n\u003Cli>Full page builder migration\u003C\u002Fli>\n\u003Cli>Gutenberg Quick Migrate sidebar\u003C\u002Fli>\n\u003Cli>AI-generated SEO metadata\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The free version remains fully functional with no deployment limits and no nag screens.\u003C\u002Fp>\n\u003Ch3>External Services\u003C\u002Fh3>\n\u003Cp>Migro can connect to two categories of external services. Both are off by default and are never contacted unless you take an explicit action.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1. AI provider for alt-text generation (optional, opt-in, your own account).\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>If you enable the AI Enhancements feature on the AI tab and configure a provider via the WordPress 7.0 AI Connector, Migro sends a single image (as a base64-encoded request payload) plus a short prompt to your configured AI provider in order to generate alt text for that specific image. Supported providers in the free version are Anthropic, OpenAI, and Google Gemini. The request is sent directly from your WordPress site to the provider using \u003Cem>your\u003C\u002Fem> API key; Migro never proxies the call and never sees your key. No request is ever made unless you explicitly trigger an alt-text generation, and existing alt text is never overwritten. Each provider’s terms apply to your account independently:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Anthropic: terms https:\u002F\u002Fwww.anthropic.com\u002Flegal\u002Fconsumer-terms ; privacy https:\u002F\u002Fwww.anthropic.com\u002Flegal\u002Fprivacy\u003C\u002Fli>\n\u003Cli>OpenAI: terms https:\u002F\u002Fopenai.com\u002Fpolicies\u002Fterms-of-use ; privacy https:\u002F\u002Fopenai.com\u002Fpolicies\u002Fprivacy-policy\u003C\u002Fli>\n\u003Cli>Google Gemini: terms https:\u002F\u002Fpolicies.google.com\u002Fterms ; privacy https:\u002F\u002Fpolicies.google.com\u002Fprivacy\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>2. Anonymous usage telemetry to Migro (optional, opt-in, off by default).\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>After installation Migro shows a one-time prompt asking whether you want to share anonymous usage data. Nothing is sent unless you choose Yes. If you decline or ignore the prompt, no data ever leaves your site, and you can change your choice at any time on the Settings page. When enabled, Migro sends anonymous, non-personal information (plugin version, WordPress version, PHP version, and aggregate deployment counts) to https:\u002F\u002Fmigro.dev to help prioritize roadmap work. It never sends post content, URLs, credentials, or personally identifiable information.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Migro privacy policy: https:\u002F\u002Fmigro.dev\u002Fprivacy\u003C\u002Fli>\n\u003Cli>Migro terms of service: https:\u002F\u002Fmigro.dev\u002Fterms\u003C\u002Fli>\n\u003C\u002Ful>\n","You changed one post. Why clone the whole site? Migro deploys individual posts and pages between staging and production.",725,"2026-07-21T21:45:00.000Z","5.6",[109,19,21,110,22],"backup","push-pull","https:\u002F\u002Fmigro.dev","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fmigro-content-migrator.2.5.2.zip",{"slug":114,"name":115,"version":116,"author":117,"author_profile":118,"description":119,"short_description":120,"active_installs":11,"downloaded":121,"rating":11,"num_ratings":11,"last_updated":122,"tested_up_to":14,"requires_at_least":123,"requires_php":16,"tags":124,"homepage":127,"download_link":128,"security_score":25,"vuln_count":11,"unpatched_count":11,"last_vuln_date":26,"fetched_at":27},"sitecargo","SiteCargo","0.1.2","Khokan Sardar","https:\u002F\u002Fprofiles.wordpress.org\u002Fkhokansardar\u002F","\u003Cp>WordPress full-site-editing structure — patterns, templates, template parts, global styles, and navigation — lives in the database. Moving \u003Cem>some\u003C\u002Fem> of it from staging to production today means either a full database sync (which is destructive to production-only data like orders, users, and form entries) or tedious manual copy-paste.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>SiteCargo\u003C\u002Fstrong> packs exactly what you choose into a portable, reviewable bundle and applies it to another site with stable identity, ID remapping, and media handling — never touching the data you didn’t select.\u003C\u002Fp>\n\u003Cp>It is currently a \u003Cstrong>WP-CLI tool\u003C\u002Fstrong> (an admin user interface is on the roadmap).\u003C\u002Fp>\n\u003Ch4>How it works\u003C\u002Fh4>\n\u003Cul>\n\u003Cli>\u003Cstrong>Export\u003C\u002Fstrong> the entity types you choose into a self-describing bundle (a folder containing a manifest, one JSON file per entity, and the referenced media).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Diff\u003C\u002Fstrong> a bundle against a target site to preview exactly what would be created, updated, or left unchanged — without writing anything.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Apply\u003C\u002Fstrong> the bundle to the target: standalone posts (patterns, navigation) are matched by a stable identifier so re-applying updates the same item instead of duplicating it; templates, parts, and global styles are matched by theme and slug. Numeric IDs baked into block markup (images, reusable-block and navigation references) are remapped to the target site, and referenced media is imported and de-duplicated by content hash.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch4>Supported entity types\u003C\u002Fh4>\n\u003Cul>\n\u003Cli>Patterns (\u003Ccode>wp_block\u003C\u002Fcode>)\u003C\u002Fli>\n\u003Cli>Templates (\u003Ccode>wp_template\u003C\u002Fcode>)\u003C\u002Fli>\n\u003Cli>Template parts (\u003Ccode>wp_template_part\u003C\u002Fcode>)\u003C\u002Fli>\n\u003Cli>Global styles (\u003Ccode>wp_global_styles\u003C\u002Fcode>)\u003C\u002Fli>\n\u003Cli>Navigation menus (\u003Ccode>wp_navigation\u003C\u002Fcode>)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Only templates\u002Fparts that have been customized in the database are exported; unedited theme-file templates already ship with the theme.\u003C\u002Fp>\n\u003Ch4>External services\u003C\u002Fh4>\n\u003Cp>This plugin does \u003Cstrong>not\u003C\u002Fstrong> connect to any external service, send any data off-site, or phone home. Bundles are plain files on your own server that you move between environments however you like.\u003C\u002Fp>\n","Selectively promote WordPress full-site-editing structure and content between environments — without a full database migration.",95,"2026-06-13T05:20:00.000Z","6.5",[125,19,126,21,22],"block-themes","full-site-editing","https:\u002F\u002Fgithub.com\u002Fitzmekhokan\u002Fsitecargo","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fsitecargo.0.1.2.zip",{"error":130,"url":131,"statusCode":132,"statusMessage":133,"message":133},true,"http:\u002F\u002Flocalhost\u002Fapi\u002Fplugins\u002Fspawnwp-deploy\u002Fbundle",404,"no bundle for this plugin yet",{"slug":4,"current_version":6,"total_versions":55,"versions":135},[136],{"version":6,"download_url":24,"svn_tag_url":137,"released_at":26,"has_diff":138,"diff_files_changed":139,"diff_lines":26,"trac_diff_url":26,"vulnerabilities":140,"is_current":130},"https:\u002F\u002Fplugins.svn.wordpress.org\u002Fspawnwp-deploy\u002Ftags\u002F0.3.4\u002F",false,[],[]]