MarkE

Hi @antpre. There seems to be a couple of issues here: The first exception is a bug, I think. Please download the current version of DbMigrationPage.class.php which should fix it. The second problem is caused because your module folder is called ProcessDbMigrate-master, not ProcessDbMigrate (this is just because of GitHub download). So: Get the new version of DbMigrationPage.class.php as per above Uninstall the module Rename the module folder to ProcessDbMigrate Refresh modules Install the module I hope that works. Let me know if not and if you have any other queries.

Hi @antpre. Sorry - I've been away for a few days - will look into this.

Hi @thetuningspoon. I have done a hack to display the edit links for multi-page situations where the field is locked. I've also added a quick module config to display edits in modal or as a new page - ideally this would be on a per-template basis. I'll do a fork once I am happy with testing.

Actually I think that @Jan Romero's fix would address the problem, as I could just lock the field rather than restict access. However, it seems to me that fix only works for single, not multiple, pages. I'll take a closer look...

Great workhorse module. Particularly useful with ConnectPageFields. I have a similar question to the permissions matter. I don’t want certain users to add or remove links (i.e. the page field itself), so I have given that role view-only access. However I do want the user to be able to view the linked page. But that seems to only be possible if they have edit access to the field. Am I missing something, or do I need to write some code to fix this?

I have used it - it works fine.

It’s now pretty much “finished” - in the sense that I don’t have much more planned in the way of features (unless others make suggestions), although I’m sure there will still be bug fixes? There are just a couple of possible additions: allowing selectors for fields and templates as well as pages, and providing some sort of database comparison feature.

v0.0.14 is now available This is quite a significant enhancement in hookability so that now (for example) scripts can be run automatically after installing a migration. See the help file for full details. Brief outline is below. Available hooks Many of the ProcessDbMigrate methods are hookable: ___execute() – Display the Database Migrations setup page ___executeNewPage() – Create new migration ___executeGetMigrations() – refreshes all migration pages ___exportData($migrationPage) – creates the .json files for a migration ___removeFiles($migrationPage) – removes the .json files for a migration ___installMigration($migrationPage) – installs a migration in the target ___uninstallMigration ($migrationPage) - uninstalls a migration in the target ___lockMigration($migrationPage, $migrationFolder) – locks a migration (in the source) ___unlockMigration($migrationPage, $migrationFolder) – unlocks a migration (in the source) ___previewDiffs($migrationPage, $comparisonType) – previews migration changes where $comparisonType is one of: export, install, uninstall, review Placement You can place your hooks in site/ready.php. In this case you will need to check the name of the migration page before running – e.g. wire()->addHookAfter('ProcessDbMigrate::installMigration', function ($event) { $migrationPage = $event->arguments(0); if ($migrationPage->name == 'my-migration') { ///code to run } }); and then you use $migrationPage to further reference the migration page. This approach keeps all your hooks together and you have to remember to sync the site/ready.php as well as your migration files. Alternatively (the recommended approach), you can place a file called ready.php in the site/template/DbMigrate/migrations/my-migration/ directory, in which case your script would be $this->addHookAfter('ProcessDbMigrate::installMigration', function ($event) { // code to run }); and you can use $this to reference the migration page. This approach keeps all your migration-related data & code together and you only have to sync the migration folder. It also means that your migration-specific ready.php code will be displayed at the bottom of the migration page. Also, if you ‘remove migration files’ it will remove your custom code as well (usually you will only be doing this as preparation to delete the migration, so that is what you want). With the first approach, your hook will remain in site/ready.php. Usage Of the available hooks, installMigration and uninstallMigration are likely to be the most useful. For example, a hook after ProcessDbMigrate::installMigration could be used to carry out database-wide changes following the amendment of the structure. Say you have changed an address field to split out the post code into a separate field. The migration definition will specify the new field and the changed template. The hook (after ProcessDbMigrate::installMigration) will then include the code to extract postcodes and place them in the new field. You could place code to undo this as a hook before ProcessDbMigrate::uninstallMigration, so that executing the uninstall exactly reverses the install. --------------- UPDATING - NOTE If you are updating the module (as opposed to installing for the first time), after a 'modules refresh' you will need to go to the bootstrap migration page and install it in order to pick up the new field which displays the migration-specific ready.php file.

Hi @prestoav. I don't know if it is of any help, but I did a little module called AdminInModal which had similar aims to FEEL (which didn't do what I wanted). If it isn't quite right it may be simpler to modify than FEEL. You can grab it here.

Horses for courses, I think @opalepatrick. PW is undoubtedly an excellent tool for admin-type applications. I have done a couple (a membership system with an integrated public website and a holiday cottage booking system which is loosely-coupled to a public website) and have found that it works well. However, you do need to think about the design quite carefully if you want it to perform elegantly and be maintainable. So far I haven't found any really good tutorials on this topic. The systems I have built tend to have the following characteristics: Use PW's page-based structure as far as possible for the database and straightforward edits; Use existing modules that suit the purpose to avoid re-inventing the wheel - I find ConnectPageFields and RuntimeMarkup/RuntimeOnly particularly useful; Use process modules for custom user interfaces - typically using MarkupAdminDataTable; Use the access control tools as required - I also use the RestrictTabView module; Use Listerpro for ad-hoc reporting; Tweak the interface as necessary with js. Inevitably you will take some wrong turnings, but PW is a great prototyping tool and genrally not too much time is wasted (certainly not compared with doing the design wrong in pure php). And the forum is great too, if your brain starts to hurt, as mine seems to frequently ?

Just a thought- have you tried setEncodeEntities(false) before writing the rows?

Version is now 0.0.13 - bug fixes and enhanced handling of image/file links in RTE fields. BTW, @teppo, in PW weekly, characterises this module thus: "DbMigrate focuses more on migrating page content, while RockMigrations is more about the structure of the site". I'm not sure this is really correct: while I have made an effort to deal with page migrations, the module was not designed to be used for mass page migrations. The driver behind including page as well as template and field migrations was to facilitate migrations that cut across code, database structure and pages - typically involving settings-type pages which are maintained by the developer, not general users. If it assists in other page migrations as well then that is a beneficial side-effect, but be aware that I have only tested the page migrations with a limited set of field types (and no pro fields).

Latest version on github is v0.0.12. This fixes a number of bugs and also adds 2 new features: When a migration has been 'locked', so that it can no longer be changed/uninstalled etc., the 'preview' button is replaced with 'review'. The review shows all the changes made by the migration (on the assumption it was properly installed before locking); it is completely derived from the json files (which should be kept unchanged on the system) and therefore is completely independent of the current database state. BTW, the purpose of locking is to prevent inadvertant overwriting of other migrations if there is an overlapping scope (although warning messages are issued if this is a risk). Hopefully it is now (mostly) multi-language enabled. If anyone needs this and finds something is missing, let me know. Obviously you will need to add your own translations ? I've been using the module a fair bit and am pretty happy with it so far. It has been very useful when updating help pages (using @Macrura's excellent AdminHelp module) on the dev system - I can then release them as a consistent batch to the live system. I have also found that it is a good way of migrating language pages as it will migrate the language .json files automatically with the pages - all that's needed is a migration item with selector "template=language".

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.

Quite easy, actually - just replace the return statement in the snippet with return strnatcmp($a->path, $b->path);

Thanks @Robin S. I installed PagePaths, but sort=path still didn't seem to work. By way of context, I was testing out my new DbMigrate module. I realised that if a page selector was used which resulted in multiple levels then the pages would need to be sorted in parent-child order before exporting to the json file, so that the subsequent import didn't try and load parents before their children. While my test may only have had 2 levels, in theory there could be any number of levels. "sort=parent.sort, sort=sort" didn't seem to do the business either. I notice that in @adrian's ProcessMigrator module, he just counts the number of path segments and then sorts by that, so that all parents are loaded first and then all children, then all grandchildren etc. I wanted the children to follow on immediately from their parents in the json which makes for a more human-readable output. (Why bother? My plan was to use the DbMigrate module as a way of exporting pages such that they could in theory be loaded in a different environment, possibly not even PW ?. In doing this, I find being able to visually review the data is helpful. Also, it seems more logical and more likely to fit a subsequent import process). I'm puzzled as to why PagePaths doesn't work, but my snippet seems to do the business - although it is a bit of a hack, it may be the best way to go as I would ideally like to refine the sorting so that numeric elements of strings are fully respected - eg. /bkg20/ should be before /bkg101/.

FWIW, I came across a similar problem with my DbMigrate module. In my case, it happened if the admin root was not just /processwire/. My solution was to use $pages->get(2) rather than $urls->admin for the admin root. This may be completely irrelevant in your case, of course ?

This seems to work (N.B. this is with a php array not a PageArray) $pages = $this->wire()->pages->find($selector); $pages = $pages->getArray(); // want them as a php array not an object if (strpos($selector, 'sort=path')) { usort($pages,function ($a, $b) { return ($a->path >= $b->path) ? 1 : -1; }); }

I mean path as in url (which doesn't work either). path is a property of page so, per the docs, should be available in sort=, but doesn't seem to be. Looks like I'll need to do the sorting after the selection ? Thanks for the comments.

I'm trying to get them in parent-child order. There are two levels below the 'has_parent' and I wanted to get each parent followed by its children. I thought that sorting by path would achieve that but, as you say, maybe its not available in a selector. Strange, because the docs say "This behavior can be overridden by specifying your own sort=property (where property is any property or field name)" (my emphasis). sort=sort doesn't work for 2 levels like this.

I have a selector, e.g. "has_parent=/property/bawd-hall/bookings/, sort=path" The results (in this case several hundred) are not sorted by path, they are sorted by id. Changing 'path' to 'name' or any other property/field works fine. It makes no difference what the first part of the selector is (I've tried several) - the sort=path always returns a sort order of id. No doubt I am being dim, but any ideas?

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.

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: A (collapsed) help field which contains the help.md text 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 ?

Version 0.0.2 now on GitHub https://github.com/MetaTunes/ProcessDbMigrate This version more fully allows for different page ids in source and target systems. A meta value (idMap) maintains the mapping. This allows the replacement of links in RTE fields provided the relevant pages are all in the migration. Also, all existing image variants are migrated. EDIT: Now 0.0.3 fixes install problem and adds upgrade via modules -> refresh.

Yeah, I did that and then came across the /> issue. Trouble is my diff method will report any diffs in the source unless I exempt them. I don't like it if you can't predict what will be returned. I think I'll stick with preg_replace for now since the parsing is very limited and see if it works out OK.