bernhard

Update: Here's a little snippet how to use dynamic navigation items using the NavJSON feature: // in getModuleInfo() 'useNavJSON' => true, // enable JSON nav feature 'nav' => [ [ 'url' => 'contacts', 'label' => 'Contacts', 'icon' => 'users', ],[ 'url' => 'mailings', 'label' => 'Mailings', 'icon' => 'folder-open-o', 'navJSON' => 'mailings-nav', // this will call executeMailingsNav() to get items ],[ 'url' => 'groups', 'label' => 'Groups', 'icon' => 'users', ], ] // and in the module /** * JSON nav for mailings */ public function executeMailingsNav() { $options['add'] = null; // no link to add pages $options['edit'] = $this->mailer()->url."new/?channel={name}"; $options['itemLabel'] = 'label'; // use the label property as item label (default is name) $options['items'] = []; foreach($this->mailer()->channels as $channel) { $data = $this->wire(new WireData()); /** @var WireData $data */ $data->name = $channel->short; $data->label = "New ".$channel->name; $data->icon = "plus-circle"; $options['items'][] = $data; } return parent::___executeNavJSON($options); }

Hey @adrian thx that is the same that @Robin S proposed just without using AOS ?

Hey @horst is this module still necessary? I think there have been some improvements to $pages->sort() some time ago so that this solution by @Robin S might be better than your module? Or am I missing something?

Yes, it does. You didn't say anything about manual sorting ? See here and for some background here:

Hey @Robin S this looks interesting! Could you please add an example of the output of such a field? What data is the field's value? An array of url strings? Can we use the PageImage sizing functions? What is the use case you developed this for? Thx ? PS: Ok read in the other thread that it seems to return Pagefile/Pageimage object(s). Follow up question: How do you handle deletion of referenced images on the storage page?

You can define the sort settings for children in the parent's settings family tab. There you can select "created" and "reverse sort order"

Another handy update on v1.0.19 ? map(column, labels) Sometimes the value stored in the DB is a key that is not as descriptive as a text label. For example it could be that the returned value of a "sex" column is f for female or m for male. One option is to replace this value via JS which could have benefits regarding performance on large datasets, but it is a little more work to make everything work as expected (eg you need to take care of formatting of the cell as well as the sort and filter values). It might be easier to map the returned value of the finder to an array of labels in such cases: $sexes = ['f'=>'Female', 'm'=>'Male']; $rockfinder->find(...) ->addColumns(["sex", ...]) ->map("sex", $sexes); The column will then show male and female instead of m and f.

Even if that's unlikely but if you are using RockMigrations that's as simple as setting a config variable: $config->filesOnDemand = "https://www.example.com"; https://github.com/BernhardBaumrock/RockMigrations/blob/02bc1b348b3e854d9a46b4cd79929f40233a2732/RockMigrations.module.php#L413-L453

dont think so ? Usually I do that via hooking ProcessPageEdit::buildForm and the wrapFields method of RM <?php $this->addHookAfter("ProcessPageEdit::buildForm", function(HookEvent $event) { $page = $event->process->getPage(); if($page->template != "yourtemplate") return; $form = $event->arguments(0); $rm = $event->modules->get("RockMigrations"); $rm->wrapFields($form, ['field1', 'field2'], [ 'label' => 'your fieldset label', 'icon' => 'bolt', ]); });

Yes, and I think you don't even need this module for that... simply send a HTTP request to their API: https://github.com/sms77io/ProcessWire/blob/30ac489026bb0f1a5dfdb181b45baef2a5ad5399/Sms77.module#L253-L260 The module seems a little like a marketing thing to me ?

Ok I understand now... But there's nothing we can do here. The admin theme/style is the base for backend styling and modules usually inject their scripts lateron. If you have problems with AOS style rules you'll likely be better off trying to request changes there.

I think you should be able to define custom files via $config->AdminThemeUikit = [ 'style' => '', 'recompile' => false, 'compress' => true, 'customCssFile' => '/site/assets/admin.css', 'customLessFiles' => [ '/site/templates/admin.less' ], ]; see https://processwire.com/blog/posts/pw-3.0.179/ That means you should be able to do something like this: $config->AdminThemeUikit = [ 'customLessFiles' => [ '/site/templates/admin.less', '/your/custom/style.less' ], ]; Does that work for you?

What are you trying to achieve? What is the situation? What is the goal?

Do you know why/how the redirect happens? I'd try copying all files as they are on the server, copy the DB and then see if you get it running that way on your dev machine. Once you have it running do the upgrade of PW (which will replace the wire folder) and inspect all the files in site folder carefully. Good luck!

I've never used symfony (only the CLI component) so I have to admit that I don't understand what you are doing here, sorry ?

OK I understand ? Maybe you could cache the result of a findRaw() ? That should be a plain php array that you can use for foreach and dynamic "active" class? ? But still not sure if what you found is an issue or just a limitation... maybe ryan tells us something about it.

I don't know anything about the issue, but for a quick solution: Why don't you cache the resulting markup instead of the pagearray?

This should be quite straightforward: https://processwire.com/docs/multi-language-support/multi-language-fields/#getting-and-setting

No - the name will be set ONCE on page creation. The title will be set on every save of the page.

Yeah. The simplest solution I can think of would be to set visibility of the title field to "hidden (not shown in the editor)" --> setup > templates > yourtemplate > click on title field > visibility Then just do whatever you want with that field via a simple hook. To test it place it in /site/ready.php - to get a good setup create an autoload module that handles your business logic and place the hook there. <?php // create a unique name on page creation (when id=0) $wire->addHookAfter("Pages::saveReady(template=yourtemplate,id=0)", function(HookEvent $event) { // set unique name, see options array $page->name = $this->wire->pages->names()->uniqueRandomPageName(); }); // set title to full name (forename+surname) on every save (id>0) $wire->addHookAfter("Pages::saveReady(template=yourtemplate,id>0)", function(HookEvent $event) { $page = $event->arguments(0); $page->title = $page->forename." ".$page->surname; });

Hi @Goca and welcome to PW ? My learnings from 2018: Don't use Repeaters for such a use case!! ? Agreed. Pages are great! They are the most important part of PW, they are robust, versatile, scale well and everything will work with pages while not everything will work with repeaters or repeater matrix. Take RockMigrations or RockFinder or findRaw as examples... To be honest I don't know. But what I usually do is leave the title field there and use it for whatever I need (and I always need anything). That could be a unique ID of that page that could be used as some simple password protection or you could use it to concatenate data from two other fields or to create a better readable label that is simply shown in the page tree. You can simply set the field to locked or hidden and populate it via saveReady hook. Maybe 10 lines of code. No mess. No danger. And ideally some other benefits. If you are building your own dashboards and lists I'd even consider structuring your page tree more like traditional database systems: - schools - modules - quizes - students I can't prove that by good arguments now and I know too little about your exact system but for me putting too much business logic into the page tree did more harm than good. Hope that helps a little ? You are already asking good questions ?

v0.0.67 has a fix to setModuleConfig method that might change how existing implementations work: $rm->setModuleConfig("AdminThemeUikit", [ 'maxWidth' => 0, // use full width of screen ]); Before the fix from today this code would have reset any other module settings (like a custom logoURL). No it does only update the maxWidth setting (as it merges existing config data). If you want the old behaviour you can set the third parameter to TRUE: $rm->setModuleConfig("AdminThemeUikit", [ 'maxWidth' => 0, // use full width of screen ], TRUE);

That would be super cool stuff ?

Yeah. That makes sense ? Just thought maybe your approach and mine could somehow be merged? Eg maybe migrations could not only live in /site/migrations but also in /site/modules/mymodule1/migrations and /mymodule2/migrations ? So each module could have a separate view of what you already have for the central migrations? Just brainstorming ?

PS: Thanks for your interest and efforts in migrations - always very welcome to see someone is working on solutions ? ?