bernhard

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

v0.0.63 Thx to the feedback of @wbmnfktr I've made it a lot easier to get started with RockMigrations! The readme has now a dedicated quickstart section: https://github.com/BernhardBaumrock/RockMigrations#quickstart The example that was shipped with RockMigrations was also improved. I removed some complexity and used real world example names (a simple blog setup) instead of "foo" and "bar". This should make it a lot easier to understand ? Also I improved the page name replacements feature introduced lately: Page name replacements now ship with the module. They are saved in a dedicated folder and named "de.txt" for german replacements. If you need any other replacement options just let me know! (maybe @apeisa ? ) $rm->setPagenameReplacements("de"); https://github.com/BernhardBaumrock/RockMigrations/tree/master/replacements

Not sure about performance, but I'm always using $this->wire->... because this supports intellisense while the other variants do not (in my setup): $this->wire->... correctly suggests the class properties and methods: $this->wire('files')->... does not: I guess $this->wire needs an extra call of the magic getter, but I have no idea if that really matters?! Whereas having intellisense matters a lot for me in my daily work...