MarkE

I agree that would be nice. I’m still hoping to release my module before Christmas but you know what it’s like - tracking down bugs. For example I’ve been adding Page Table Field compatibility as an alternative to RepeaterMatrix, which throws a few issues especially if the table is hosted under a “foreign” parent. I’m just about there now….. To your specific point @bernhard, it had already occurred to me that there might be a way of combining the best of both modules - e.g. GUI in the development environment with deployment via code; or maybe creating a RockMigrations migration from my json files. However, I don’t even want to think about this until I have released my module and had feedback from other users.

With my system, the times are filled in automatically from the default for the property or system, but can be changed if, for example, early access is granted. Since the system also generates email correspondence with the guests, it needs to tell them the arrival and departure times. Sure, it could be done with separate fields, as it is now. Having thought about it a bit more, I can see that there might be some complications arising from including times in the range and you would certainly want it to be hidden in some circumstances. I have another app with event booking, where date and time are essential. Using the current interface, similar to the one in my example, is a bit fiddly.

You'll have to write some code for that @ShadowByte. This is my code for my blog tags (in Latte) which I'm sure you can adapt for your purposes (my blogs are in a repeater matix field here): {var $blogsPage = $page->motif_display_pageref} {var $blogs = $blogsPage->find("template=MotifDisplay, parent=$blogsPage")} {var $tags = []} {foreach $blogs as $blog} {foreach $blog->motif_layout_components as $component} {if $component->type == 'blog-post'} {var $blogTags = $component->motif_blog_tag->explode('title')} {* {bd($blogTags, 'blogtags')}*} {foreach $blogTags as $blogTag} {if !array_key_exists($blogTag, $tags)} {do $tags[$blogTag]['name'] = $blogTag} {do $tags[$blogTag]['count'] = 0} {/if} {do $tags[$blogTag]['count'] += 1} {/foreach} {/if} {/foreach} {/foreach} {* Sort the tags in descending order of frequency so that the most used are at the top *} {var $tagCount = []} {foreach $tags as $key => $tag } {do $tagCount[$key] = $tag['count']} {/foreach} {do array_multisort($tagCount, SORT_DESC, $tags)} {*<section>*} <ul n:foreach="$tags as $tagKey => $arr"> <li> <a href="{$blogsPage->url . 'tag/' . $tagKey}">{$tagKey}</a> </li> </ul> {*</section>*}

That's not how RockMigrations works. At least not at the moment. And that has several good reasons. I'm not saying that such an approach is bad. But it is very complicated to implement, it comes with a lot of (maybe unsolvable) problems and even if everything worked it has a lot of limitations by design. I didn't want that for RockMigrations, so I built it differently. Quite correct, except "even if everything worked it has a lot of limitations by design". I'm not sure what those might be. ProcessDbMigrate is working pretty well now and I will let people know when I am happy with the testing (and documentation!). Yes, it was very complicated to implement but it is now coming together nicely. I think RockMigrations is great for people who want to work that way, but I chose a different path and will happily accept criticism (and, even better, constructive suggestions) if it doesn't work as intended. That is a risk, but I don't find it a problem with my module. It deliberately omits some unnecessary properties. Yeah - that's nice. I wonder.... ProcessDbMigrate uses multiple migrations and you can define one to export the database to another project. I am using it to install another module in new projects and plan to use it to create a template project from a live one. I'll admit that it is early days yet and that it is probably not as flexible as RockMigrations, but I'm not convinced it is a 'huge drawback'. With ProcessDbMigrate, you use a Page class module in the same way (without all the field definitions etc.), create a very simple 'export' migration of the required fields and templates manually (just specify the names in repeaters), sync to your target and hit 'import'. 😉Agreed, but I don't blame @bernhardfor that. I would welcome his comments when my module is released. True in my case too, as the module interprets them and presents differences etc., but they have been useful in debugging 🤪 ProcessDbMigrate uses names and paths not ids. If a name is changed it tracks that, so that it updates the target correctly. So ids do not need to be the same. You cannot change fields etc. in the target if they are the subject of a live migration (unless you disable that feature), but you can after it has been fully installed and 'locked'. Of course if someone updates the live then someone else creates a new migration from an old database version that over-writes it, that is a problem! So far I have not had a problem with any type of change that you can make in the UI (including parent id and template id references - these are converted to names and then converted back on installation) Sorry if the above sounds a bit defensive, but I just wanted to set the record straight. Of course, you can disagree once the module is released and you have used it! Just to emphasise a couple of points: RockMigrations is a great free module and if it's what you want then use it. ProcessDbMigrate does what I want and I thought it would be helpful to share it (but only when I am happy that it will not cause any difficulties). I have no desire ever to sell it or to position it as some sort of 'competitor', but I would be grateful if others do not knock it without just cause.

I am assuming you selected 'text tags' as the inputfield type on the field 'input' tab and also selected a parent and template for the tags. Further down that tab, you need to select 'Allow new pages to be created from field' - please note the requirements listed there.

Use a Page Reference field for your tags. Then you can do pretty much what you will.

One thing I should mention (and would appreciate some feedback on) is that my migrations module (and I guess any that uses json files) is declarative. Even if you create a migration automatically while making your database changes, what happens is the module logs what objects have changed and exports the final state. It does not operate as a 'macro' logging each change separately. The disadvantage of this is that problems might arise where there is a 'dependency cycle' - e.g. a new field (say a page ref type) depends on a new template which includes the field. With my module, if this happens while you are logging changes it will (should 😉) warn you. If you create the migration manually and then 'sort on save' to get the items in dependency order, it will give you an error message (see video at end). I think there are 3 ways of dealing with this: Do more than one migration, so that all required objects are present in the database. Include an item twice in the migration - firstly without the dependency, then with the dependency after the other object has been added. Install the migration twice and hope it will sort itself out (i.e. the misssing objects will be there on the second installation). My module encourages (1) but permits (3) - as you will see. It does not attempt (2) - this might be feasible by detecting the cycle, and breaking it for the first item, but a bit complex to implement. I'd be interested in any thoughts people have on this issue (and indeed on how RockMigrations deals with it - @bernhard?). Meanwhile, to amuse you (??) here is a video of a big complex migration I did as part of the testing process. As you will see, there are lots of cycles, but it installed with just two clicks of the 'install' button 🙂. cycle errors.mp4

Will do. Please note that the code on GitHub may be behind the latest version and may well contain bugs. I will post on the Forum when I am happy with it. I haven't tried this. It might work if you have not changed any pages at all. I would be afraid of breaking relationships and, personally, I sometimes use pages to hold settings that are not user-updatable and which I might need to migrate, so that would not be a solution for me. Fair point. Particularly re any special field types introduced in modules. ProcessDbMigrate does cater for most of them (I am just updating it for FieldtypePageTable) including some which store attributes as objects, but would need updating if there are major changes or additions to the core (my guess, though, is that these are very unlikely to be breaking changes). It is clear to me from previous discusssions that @ryanis not convinced of the need for this in the core and, indeed, does not feel the need for it personally. I consider that a shame as the lack of this functionality is in my view the only major missing feature in ProcessWire. The topic has been debated here numerous times with no clear conclusion. As a consequence, those of us who feel the need have had to turn to modules - either our own or others'. RockMigrations has been released for a while and is well-supported. Both that and ProcessDbMigrate are open-source so, unless @ryanchanges his mind, it will be up to the community to contribute to module development or, indeed, take it over should the original author no longer maintain it. That will depend on how important the community thinks it is. I think I reported some issues without any action being taken. Also, I recall that the export functions were left as work in progress some time ago. But I may mis-remember...

I have a json based migrations module that I released some time ago (ProcessDbMigrate). It needed further work, so I have not publicised it further after the initial proof of concept. In the meantime I have improved it enormously and tested it quite extensively with multiple field types including RepeaterMatrix. It is almost ready for re-release. It is a completely different concept to RockMigrations, which is an excellent and well-established module. My module will automatically track database changes as you make them in the back end UI and then export json for installation in the target. It also provides for roll-back, database comparisons and much more. Hopefully out before Christmas. PS I found during the course of development that there are quite a few flaws in the native export functions and had to re-write quite a bit.

Actually, I realised that even for the cottage booking system, although the booking form is only dates, not times, I use date and time in the back end because the time is the access/leave time (see below) - the default times are auto-filled from settings

That’s brilliant @ryan. I wish I’d had that a few years back when I was developing my holiday cottage booking system. Could have done the booking form for it in a jiffy! Shame it is only days though, not times, as I can’t use it for events in an app I am currently redeveloping.

@da² What I meant was being able to add them interactively in the back end

There also some (paid for) page builder modules that will do this (and more). I have my own page builder module which I might release for free, but which uses repeater matrix. So it looks like a choice between paying some money or writing some code.

I thought YOOtheme pro was a Wordpress/Joomla thing

Hi @Kiwi Chris. I have sent you a PM with the module.

I’ve had the same need and dealt with it via such that when a “locked” page is edited, it gives an option to create a new one like this. In my implementation it is all dealt with in a process module, rather than in the page list. I can supply more details if you want.

That’s probably fine if you don’t want to add other types of relationships dynamically.

Hi @joe_g. How about 3 templates: person, role and article. Role has 3 fields: title (name of the role) and page ref fields to each of person and article Person and article have page ref fields to role. Use ConnectPageFields module - 2 entries for each of the 2 relationships. Allow new pages to be created when in the page ref fields of person and article templates. You can then add a new role page when editing person or article, complete with the required linkage. Use API to get all the role/article combinations for any person etc. If you want to restrict roles to a list then you could use a select options or even another page ref field, and just put a ref in the title.

Generally this is addressed by appropriate setting of roles and permissions. Do you have a specific problem that cannot be dealt with that way?

About 8 secs for me with cache cleared. That's with about 50mbps download

This does the business nicely, but I wonder whether the 'Modules' menu item could be optional or modifiable. I want to include the module config links on a webmaster's dashboard - which I can do easily (and include a &collapse_info=1 param, which I think makes sense in this context), but then I don't really need/want the 'Modules' menu item. Edit: Maybe something like a config field "Menu name" with "Modules" as the default. Blanking it would remove the menu, or a different name could be used. Edit2: And maybe an option to collapse the info section 😉

I'm planning to upgrade one of my PW apps to include a better set of pagebuilding tools (easy to use but powerful!) - at present it just uses the standard PW CMS so there is not much scope for users to customise their site. A while back (for another site) I wrote my own pagebuilder which relied heavily on RepeaterMatrix, Latte, CSS grids and RockFrontEnd. It works well but is more complex than I would like. I know there has been quite a bit of discussion about this topic in the past (and in particular I think @Jonathan Lahijani wrote this), but things have moved on a bit, with @jploch's PageGrid and @bernhard's (waiting, waiting...) RockPageBuilder. Also, I would like to make some custom widgets available in my page builder and the new component module by @ukyo looks interesting. Does anyone have any experiences and insights they would like to share?

Megastar! My module was going to be a process module a la SettingsFactory, but that does the job perfectly and saved me a task. Ta muchly!

Should getModuleConfigInputfields() be declared in a module as static or not? Also, I am confused that som modules use an array as the parameter whereas others use an InputfieldWrapper. For example, WireMailSmtp has static public function getModuleConfigInputfields(array $data) whereas WireMailRouter has public function getModuleConfigInputfields(InputfieldWrapper $inputfields) I am trying to build a module that allows certain configs to be set outside the modules themselves (to allow non-superuser access), so I need to call the getModuleConfigInputfields() method, but without knowing what parameter to supply. If it is an array, I can use getConfig(), but otherwise what. And why do different modules do it differently anyway?

OK, the problem here seems to be that values of fieldset children are omitted by ProcessSettingsFactory. Somewhere between (in the buildForm() method) line 136 $form->add($fArray); and line 174 return $form; the values of the fieldset children get dropped. If I comment out the section foreach($inputfields as $key => $cField) { ... } the field values load correctly