bernhard

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 ? ?

Hi @LuisM thx for the great writeup - it's always hard to understand complex topics! To be honest I'm not sure if I like what I see ? On the one hand sometimes I wished I had some kind of overview/list of migrations and some place to manage them, but on the other hand I'm using migrations in a totally different way and your approach feels like a step back in many ways. No offense here - both approaches have pros and cons and it might simply be a matter of preference ? The problems with that approach are the following (for me): One central place for migrations That might sound good and it might be superior from a technical aspect, but for me and my daily work it's not. I'm building my sites with many different modules and my main goal is productivity and quality. Almost anything that I do is done via modules nowadays. These modules do often need to create the necessary fields and templates, and they do that using RockMigrations. It's great. I get a module that is reusable across projects and it's quite easy to develop and to create all the necessary database stuff. And it's easy to push new versions to production and after a modules refresh I have all that I need. Having a central place for migrations locks all the work that I do in one single (and not reusable) project. Or am I misunderstanding your concept? So my solution would be: Create different modules that do different things (eg a newsletter module, a sitemap module, a slider module) and all those modules ship with their own migrations. They are separate pieces and can be used across several projects. Then on the main project I'd have another module (sometimes I simply call that Site.module.php) and that one has migrations to install other modules or do stuff that does not fit into a reusable module. Such a migration could look like this: $rm->installModule('Slider'); $rm->installModule('Sitemap'); // create home page // set page title // create imprint page // etc etc I know that this approach has other drawbacks, but for now it works quite good for me ? Template/Field/Page migrations I think I also don't like the approach of splitting every migration into a dedicated field/template/page migration. Maybe I'm misunderstanding you again, but usually such migrations are related. Eg you want to add a field to a template so you need to create that field and then you need to add that field to your template. Having those changes in seperate files leads to a mess of migration files that are very hard to understand afterwards. You lose the big picture imho. My approach is to place all that in the migrate() method and you'll end up with a static "snapshot" of your system that you'll easily and instantly understand when you look at it. That get's even better when you use GIT: The drawback is of course that it get's harder to revert such changes. Backup/Restore is one technique or custom downgrade migrations could be another concept. What I sometimes do is adding a "cleanup()" method on top of the migrations that removes fields that I do not need any more. So if I needed to remove that reminder field, I'd do the following: Again: Reverting would be a challenge, but I've never needed any reverts until now and backup/restore has served me well enough ? Hope the post was helpful nevertheless ?

Hi @Chris Ernovsky glad you like it! That is a good but not so easy question ? My primary goal was to make it easy to make the admin look and feel more like the brands of my clients. I don't have further ambitions. That's why I introduced the wording "theme" vs. "style" --> a style is really just a modified CSS. Everything that modifies more of the admin might be called "theme". On the oder hand this module shows that you could combine both. Change the style on the one hand but also modify the theme via hooks on the other hand. You have lots of possibilities. Going further you could create your own admin theme as well. I have no idea how hard that would be to build and maintain. I'm afraid of that, so I'll not do it ?