Jump to content
MarkE

Oh no, not another migration module!

Recommended Posts

Posted (edited)

EDIT: Don't try this just yet, there seems to be a slight bug!

Version 0.0.4 on https://github.com/MetaTunes/ProcessDbMigrate

To upgrade, place the files in the module folder and refresh modules.

This version is partly a code tidy-up, but also adds 2 useful things to the module settings:

  1. A (collapsed) help field which contains the help.md text
  2. A feature which enables the current database to be named (e.g. Development, Test, Production, Client_1 or whatever). Migrations sourced from a named database will be treated as 'installable' in any database of a different name (or unnamed), but as 'exportable' in a database with the same name. This means, for example, that you can copy a production database as a new development database and rename it to be the same as your original development database, so that any migrations sourced from that development database will be shown as exportable, not installable, in the new database. You can also request that the current database name is notified in every admin page (in case you forget which environment you are in!). The feature is optional - if not used, any migrations will be treated as installable in every other database.

The module now does pretty much everything I originally wanted - it just needs a bit more use to flush out remaining bugs. It is also possible that further field types may be needed - there are some slight imperfections with pagetables and I do not have pro fields, so can't test those. And I am sure the code can be improved 😉 

Edited by MarkE
  • Like 2

Share this post


Link to post
Share on other sites

Hopefully the bugs in 0.0.4 have been fixed in v0.0.5

FWIW, the issue was to do with the operation of hooks when adding pages via a migration. 

The module was designed for migrating developments, not for mass updating of user pages. It was therefore assumed that any pages being migrated would be of a ‘site-settings’ nature, not user pages.

However, the module allows the migration of any pages and the host PW application may make use of page hooks. All page actions in the module allow hooks to run. To enable users to modify this behaviour, session variables are set for the duration of the following methods:
•    installPages() – new/changed pages – ‘dbMigrate_installPages’ is set to true
•    removeItems() – all item removals – ‘dbMigrate_removeItems’ is set to true
These can then be referenced in the application code as required. Note that in removals, all pages are trashed (so that hooks can operate) then deleted (so they are no longer in the trash).

So it is possible to use the module more generally (e.g. in ‘rescue’ mode) but test carefully first!

Please report any bugs (or indeed successful use). I'd also be grateful for feedback (particularly from module developers @adrian and @bernhard, who have previously commented, but also from any other interested persons) on whether this should be added to the modules library and, if so, whether anything needs to be done to it first.

  • Like 1

Share this post


Link to post
Share on other sites

v0.0.6 allows page selectors that result in multiple levels.

The use of “sort=path” is permitted in selectors, even though this normally has no effect. If it is used, the pages will be sorted in parent-child order, using the ‘natural’ sort order (e.g. XYZ100 is greater than XYZ20). This means that parents should be installed before children. For ‘removed’ pages, the order is reversed so that children are deleted before parents.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...