Wp2Apex Specs
The WP2Apex package will be developed with the sole intention of transitioning existing Wordpress sites over to Apex. This package is not intended to fully convert Wordpress powered systems to Apex, but instead acts as a transitional layer until full migration is complete.
wp2apex Account
For the next section to make sense, the wp2apex Apex account first needs to be explained. This will be a namespace at https://code.apexpl.io/wp2apex/<package> which will host all plugin migration packages.
Every developer will be able to publish migration packages to their own Apex account, then request they be linked under the wp2apex account. Here's the process flow:
- Developer creates package for whatever functionality that is equivalent to functionality of an existing Wordpress plugin.
- Developer creates a separate migration package that will complete any data transfer from the Wordpress database and anything else required to migrate the Wordpress data of the plugin into Apex.
- Developer publishes the migration package to their Apex account, and submits a form requesting it be linked under the wp2apex account to the specific Wordpress plugin they developed migration for.
- Apex tests the package to ensure automated migration works, and approves or declines the request.
- Ensure both Apex and WP are installed on the same server, plus the Apex database user also has access to the WP database, and vice versa.
- Run
wp2apex scan command, which will scan the WP system, report any issues found, and list all plugins for which full migration is possible. The checks that will be performed will include, but are not limited to: - Check WP Core version number to ensure it's supported.
- Check SHA1 hashes of WP core files against official Wordpress release to see whether or not core files have been customized.
- Check structure of core WP database tables for custom schema modifications.
- Map packages installed on Apex with installed Wordpress plugins against the wp2apex account, and give any warnings about missing Apex packages.
- Run
wp2apex convert-theme
which will convert the Wordpress theme being used into a Syrus theme for use within Apex. Utilizing the PHP Tokenizer class, an intuitive parser will tokenize all PHP code within the Wordpress theme files, and auto-generate a separate PHP class that will be utilized within the Syrus theme. Naturally, auto-generated code only goes so far so this class will need to be manually refactored by a human as necessary until the theme looks proper on the Apex system. - Run
wp2apex migrate-db
command, which will migrate the database in the following manner:- Dump both, Wordpress and APex databases for backup purposes.
- Insert all base Wordpress data (posts, taxonomies, et al) into the Apex database tables.
- Drop the base Wordpress tables (posts, taxonomies, et al) and replace them with views that point to the Apex database.
- Result is all base data is now handled by the Apex database, yet the Wordpress database schema continues to be the exact same and Wordpress continues to work without error.
- Run the
wp2apex migrate-plugins
command, which will go through all installed Wordpress plugins, and check the wp2apex account for a matching migration package. If one exists, the migration package will be installed and run on the Apex system, then the plugin within Wordpress will be marked as migrated. This process will also go through all plugins for which there is no migration package, scan the plugin code and compile a list of all hooks and triggers the plugin uses. - Run the
wp2apex migrate-core
command, which will replace various Wordpress core files with modified files, essentially turning the Wordpress system into a RPC server. See below for full description. - That's it. Test the Apex installation to ensure everything is running correctly, and begin pointing domain name to the Apex system.
- At the end of the migration period you will have:
- All possible database tables transferred over from Wordpress to Apex database.
- Views replacing the old Wordpress tables, keeping the Wordpress database schema the exact same while having all data stored within the Apex database.
- All possible plugins will have been migrated over with both, the corresponding Apex package installed and the migration package being run.
- The WP core engine files updated essentially turning WP core engine into a RPC server.
- Apex will have compiled a list of all WP hooks and triggers that are used by each plugin that wasn't able to be migrated, including when / where they are used.
The main wp2apex/wp2apex package will be installed on the Apex system, and will have a multitude of listeners developed into it. These listeners will basically emulate the various hooks and triggers that are built into WP. When necessary for a WP plugin that was not able to be migrated over, the Apex system will notice this from the compiled list of WP hooks and triggers the plugins use, and will essentially ping the old WP system with the necessary information in order to execute that portion of the appropriate WP plugin.
This means for the first while for example, 80% of the WP system will have been fully migrated over to Apex. However, for the 20% that was unable to be migrated over Apex will remotely execute the necessary plugin functions essentially via RPC as necessary. The one system will continue running off both databases temporarily.
Finalizing Migration
As stated at the beginning, the wp2apex package is intended to be a temporary migration layer until full migration is complete. Finalizing migration will require waiting until all necessary packages to replace all WP plugins is developed out, plus any custom functionality is developed into Apex. Once all WP plugins have been successfully migrated over, the WP system can be deleted and migration to Apex will be finalized.
This will result in a large number of migration packages under the wp2apex account, each of which is linked to one Wordpress plugin and one Apex package.
Process Flow
Migration process utilizing WP2Apex will work as follows: