MarkE

Now solved. For the benefit of others, you need to set the sort property of the repeater rather than use a custom property. i.e. for each repeater page: $subPage->sort = $j; // where $j is the required sort index $subPage->save(); then after all 'subPages' have been set: $page->$repeaterName->sort('sort'); and save the page.

I am editing repeater field subpages for a page using the API. As I edit each one, I assign it a sequence. I then sort them by that sequence, viz: $page->$repeaterName->sort('sequence'); When I look at the page in the UI, the sort seems to have worked OK. However, when I then process the repeaters, the processing happens in the original sequence, not my sort order. Inspecting the page with Tracy (see below), it is clear that the array keys retain the original order even though the displayed order is correct - and it is the array keys that determine the processing sequence. Any ideas how I fix this?

I’ll look into that @antpre, but it is possible that the warning message is being shown in error. It may be that the migration still works ok. Let me know either way. BTW I don’t see any migration items for the fields in the repeater templates - that’s ok if they already exist in the target, but please check.

Hi @antpre. It is not obvious, but every repeater field has a system template which is the field name preceded by repeater_ . If you go to setup/templates and enable system templates in the filter you will see these. You therefore need to include the details of this template in your migration, before the field itself - as indicated by the message. Also, if your repeater uses any other new or changed fields, you will need to specify these before the template.

Hi @antpre. Could you post a screenshot of the migration page showing the migration items (open)?

For @antpre and anyone else trying this module - there is a minor bug in the presentation - please update RuntimeOnly/dbMigrateReady.js and copy it to your templates/RuntimeOnly folder.

@thetuningspoonI have forked this at https://github.com/MetaTunes/AdminPageFieldEditLinks Changes to : Show 'view' links for locked page fields in case of multi-pages. Add 'new tab' as alternative to modal for edit view (configured in field input settings). Bump version to 3.1.4

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; }); }