bernhard

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 ?

Hi Rudy, nice, thx for sharing ? Have you considered using a custom search of your browser? I've created one using the "ui" prefix, so I'm typing "ui alert" and get to this result page: https://www.google.com/search?q=site:getuikit.com/docs+alert

Hi @Goca welcome to the forum ? There's nothing wrong about creating a template that is only used for one single page. On the contrary. We even have a setting for that in the template's settings: As alternative to what the others have already said you can also use URL hooks that we have since 3.0.173: https://processwire.com/blog/posts/pw-3.0.173/ Note that when using url hooks you need to take care of access control yourself while when creating a template file you can use PW's access control system from the backend ?

Thx @axelino I've merged your PR yesterday ?

<?php $page->of(false); $page->yourfield->add("https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Processwire_logo.svg/2560px-Processwire_logo.svg.png"); $file = $page->getUnformatted('yourfield')->last(); $file->description = 'hello world'; $page->save(); getUnformatted ensures that you get the files as array and then retrieve the last file ?

Wouldn't that be $wire->files->copy(src, dst); ?

You can set any file that exists and is readable on your server already... $rm->createViewFile("mytemplate.php", "/path/to/your/source/file.php");

Actually it already has a second parameter to provide a file to take the content from. This means you could add a skeleton folder to your module holding the initial markup and the module will copy that content to the templates folder: https://github.com/BernhardBaumrock/RockMigrations/blob/3844b697be393b98dbc9a47b55370c4fa521c20b/RockMigrations.module.php#L1817 One could also make it sync files or add the file having a single "include" to reference the markup from within a module folder. But I didn't want to overcomplicate things ?

Hi Ivan, good question ? My workflow is based on RockUikit - a module for Frontend Development similar to WireFrame. So I need the file solely for making the site visible on the frontend. Markup is placed in a different location. Now that you are asking I realize that this might not be the most helpful addition for others. Anyhow I'm just keeping you updated so maybe someone will pick up some inspiration or have suggestions or input for me ? But in general my workflow is now a little bit like "everything is a module" ? And RockMigrations does everything related to template/field/page creation ?

v0.0.64 adds a new method $rm->createViewFile('yourtemplate'); that creates a file /site/templates/yourtemplate.php That might sound like overkill, but when used with class constant and OOP that makes it clear and easy: <?php namespace RockTeam; use ProcessWire\Page; use ProcessWire\RockMigrations; use ProcessWire\RockTeam; class TeamPage extends Page { const prefix = RockTeam::prefix; const tpl = self::prefix."teampage"; const tags = RockTeam::tags; /** * Triggered in RockTeam::migrate() */ public function migrate(RockMigrations $rm) { $rm->migrate([ 'templates' => [ self::tpl => [ 'tags' => self::tags, 'icon' => 'users', 'fields' => ['title'], ], ], ]); $rm->createViewFile(self::tpl); } }

$rm->setFieldData(...) Best docs we have so far is using intellisense of your IDE and looking into the code ?

If execution order is important you can always use the declarative syntax: $p1 = $rm->createPage(...); $p2 = $rm->createPage(...); $p2->setAndSave('pageref', $p1); does that help?

Hey Adrian, I like the idea! But I'm not sure what would really be the best way to achieve something like this. I've created a module for my style to make it easy for me to maintain it and also it has lots of helpful background information about admin themes/styles: https://github.com/baumrock/AdminStyleRock The main reason for putting everything into a module is my git submodule based setup. So I can simply add my theme as submodule and pull and push changes to any of my projects. My module can also serve as an example for others that want to provide a style for AdminThemeUikit. It could be simplified even more, but maybe it's good to wait a little to see how and if the community will come up with other styles at all? I think what we have now is only a first step. But I'm really not sure what would be a good next step as there are many good options... ?

Hi and welcome to the forum never used it, but there is a module that should do what you are looking for: https://processwire.com/modules/import-pages-csv/ or several posts: https://www.google.com/search?q=site:processwire.com+import+pages+csv

Thx @wbmnfktr for the explanations and thx @Ivan Gretsky pushing me to (hopefully) make it even easier to understand everything and to build custom styles. I've created a new module for rock style development that also has docs that should explain everything.

Not yet. Ryan asked me if we should use RockLess for the new admin theming feature but I voted against using RockLESS as it is more a proof of concept than a polished module. It lacks proper docs and some methods are redundant but slightly different. Ryans Less module is a simple wrapper around the same less parser that RockLESS uses but it lacks the file/directory monitoring part. I'd like to add that to ryans Less module one day for the same reason you are talking about, but I have no idea when that will happen. I thought it would be a good idea to start simple and solid with the new Less module and add features there when we need them. If you don't miss any features with Ryans module: Go with his module. If you miss features: Stay with RockLESS or even better make a PR so that we can shift to the new Less module ?

Reno style: Rock style: Uikit offers SCSS but the PW backend is based on LESS - see the uikit-pw folder: https://github.com/processwire/processwire/tree/dev/wire/modules/AdminTheme/AdminThemeUikit/uikit-pw/pw This means that it is very easy to build an admin theme/style based on the core LESS files while it would need a total rewrite using SCSS I guess. I'm not an expert on frontend/CSS stuff. Maybe there are converters between LESS and SASS? I've tried https://less2scss.awk5.com/ and it seems to be working?! Or maybe https://jsonformatter.org/less-to-scss; But I've read some articles now and I'm not sure if a transition would be that easy... You just need the less module and you can use it for your frontend as well: https://processwire.com/modules/less/ $less = $modules->get('Less'); $less->setOption('compress', true); $less->addStr('@color: #4D926F; h2 { color: @color; }'); $less->addFile('/path/to/file1.less'); $less->addFile('/path/to/file2.less', '/url/to/images/'); $less->saveCss('/path/to/file.min.css'); A simple timestamp checker could look like this: <?php $src = $config->paths->templates."myfrontendstyle.less"; $dst = $src.".css"; if(filemtime($src) > filemtime($dst)) { $less = $modules->get('Less'); $less->setOption('compress', true); $less->addFile($src); $less->saveCss($dst); } $url = $config->urls->templates."myfrontendstyle.less.css"; echo '<link rel="stylesheet" href="'.$url.'">'; So the basics are really easy. This does not check if files exist and it does not check for changes in imported files. You can try RockLESS which has options to monitor files and/or directories for changes.

Thx @ryan for all the additional effort you put into this and of course for providing me with all the necessary files and information to work on that PR. I'm really happy that everything worked out so well and I hope we see lots of great designs from some css ninjas in the community ? I've created a dedicated thread for discussion and issue reports related to the rock style that might be easier to find in the future: Happy styling ?

AdminStyleRock Easily style your ProcessWire backend with two simple settings: Or via RockMigrations: $rm->installModule("AdminStyleRock", [ 'rockprimary' => '#0069B4', 'logo' => '/site/templates/img/kollar.svg', ]); ----------- Background: As of PW 3.0.179 we have a new style in AdminThemeUikit called "rock" style. This thread is here to report issues or ideas for improvement. The goal of the rock style is to make it as easy as possible to adapt your backend to the CI of your client. That's why it uses only ONE single main color and keeps all other design elements in a neutral grey. Download & Docs: https://github.com/baumrock/AdminStyleRock Here is an example screenshot using default uikit colors and a custom base font:

Nice! I've done a similar thing (but very basic and only PNG) lately. The webmanifest is generated on page save and simply exposed via url hook ? Looking forward to seeing what you came up with. That will get a lot easier with the next dev release of PW ?

this tool looks interesting! what are you building here? a pw module? or an online service?

I got a promising response by the Intelephense developer: https://www.jetbrains.com/help/phpstorm/ide-advanced-metadata.html#override Does anybody know how to do that?

Thx @teppo that helped a lot already Did you try that? It does not have any effect at all for me... The only way I got that working is changing the return hints of the wire() method in wire.php // from this @return ProcessWire|Wire|Session|Page|Pages|Modules|User|Users|Roles|Permissions|Templates|Fields|Fieldtypes|Sanitizer|Config|Notices|WireDatabasePDO|WireHooks|WireDateTime|WireFileTools|WireMailTools|WireInput|string|mixed // to that @return ProcessWire |mixed But that is really ugly and incorrect of course. @ryan do you have any ideas what ProcessWire could do about that "problem"? Or would it be better to ask the Intelephense developer for help to support multiple return types in the @return hint? Maybe it should just return the first listed class by default or maybe it should list all listed classes and all derived methods? I've created an issue to ask at Intelephense as well: https://github.com/bmewburn/vscode-intelephense/issues/1800 The wire property already returns the ProcessWire class correctly. But if wire() is used as the new standard I'd prefer to make that work on my setup and start using it in my own modules as well.

Thx Ryan, I knew about the extra hop, but didn't know about the fuel thing. Nevertheless $this->wire()->... is no option for me at the moment, because I simply don't get any suggestions while $this->wire->... does bring me everything I need. Does anybody reading this know how to make VSCode recognize $this->wire() calls? Maybe I'm just missing a setting in Intelephense or maybe we are just missing some typehints in the core where PHPStorm is clever enough to work while VSCode is not? Thx