Leaderboard

ProcessWire 3.0.179 adds great new admin theme customization tools that put you in full control over the admin styles, thanks to PR #189 from @bernhard — https://processwire.com/blog/posts/pw-3.0.179/

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:

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 ?

Very cool, thanks @bernhard and @ryan! Any thoughts about supporting an SCSS version of AdminThemeUikit and customising via an admin.scss file? Uikit offers a Sass (SCSS) version and my impression is that SCSS is more popular than LESS. Google Trends: One person's opinion from 2015: https://www.telerik.com/blogs/why-bootstrap-4-means-sass-has-won It would be interesting to conduct a poll of PW users to see which is the more popular CSS pre-processor.

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.

Cool thing, @bernhard! It is clear you put a lot of effort and talent into this. Thanks for sharing with the community! I think it would be great to have an example to understand, which modifications are possible and how to implement them. If you have something that could be shared, please do.

Thanks Bernhard and Ryan! I agree. Especially regarding .../wire/modules/AdminTheme/AdminThemeUikit/uikit/src/scss which is never used. However, I disagree with "forcing" us to use node.js. There should be no need for node.js just to use core features. Maybe an additional module which is not bundled with the core but still maintained "as if it was" a core module could solve this. A lot of times there is no need for admin design customizations, for example when just installing PW for "clean install" testing purposes. What if there were a set of "additional core modules" which can still be installed with a few clicks but kept separately from the main zip file of PW? Ideas for such modules: https://github.com/ryancramerdesign/FieldtypeTextUnique https://github.com/ryancramerdesign/FieldtypeEvents https://processwire.com/talk/topic/2708-module-process-changelog https://processwire.com/modules/module-release-notes/

I’m a nearly brand-new ProcessWire user, and I’ve got to say I’m really impressed — not just with this functionality, but with how easy @ryan and @bernhard have made everything. I installed the new version of PW on my cloud server, installed the Less module, updated config.php and put a few Less statements into admin.less — and had it all working perfectly within about 15 minutes. Nicely done!

Thank you @bernhard and @ryan This is really brilliant and exactly the type of skinning ability that I think we've been missing!

Here is another little tutorial about files structure in ProcessWire. https://www.spiria.com/en/blog/web-development/tutorial-the-file-structure-in-a-processwire-site/ Comments welcome as always.

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 ?

"C" is the default value for the the "C" field in the translations, so I'm guessing it's taking it over your "de_DE.UTF8" , I noticed that you are mixing different locale languages on that call to setlocale. The idea is to add different forms of locales for only one language, to find out which one is recognized by the server. Can you try exactly what I suggested above, and see which one of them is echoed? <?php echo setlocale(LC_ALL, 'de_DE.UTF8', 'de.UTF8', 'de_DE.UTF-8', 'de.UTF-8');?> Also, a correction to what I wrote before: If you add a list of locales to the "C" field, you should add them separated by commas, but without the quotation marks. de_DE.UTF8, de.UTF8, de_DE.UTF-8, de.UTF-8 instead of 'de_DE.UTF8', 'de.UTF8', 'de_DE.UTF-8', 'de.UTF-8' I modified my other post to reflect this.

@bernhard @ryan Thanks for admin theme customization option But i didn't like uikit source files under AdminThemeUikit/uikit, no need these files. Folder size is big ! I can give an idea about using uikit less or scss files: - You can install uikit via node with package.json file - You can load source uikit files from node_modules/uikit/src/less/uikit.less - You can add node_modules folder to .gitignore - If a user want to modify admin theme, user can define uikit source from less file With this way, we don't need uikit source files under AdminThemeUikit folder

@fruid - I'll admit the database vs in-memory can be somewhat confusing in PW in terms of what selectors are support for one but not the other. This definitely needs improvement and better documentation, but I don't think that is really relevant in this case. Once you assign an array of pages to a variable and then do a find on that, you are using an in-memory selector - you're not querying the database anymore. This means if you are loading so many results that you need to paginate, then you're losing some of the benefits of pagination. This is not PW specific or even PHP specific. Regarding the two subsections - are you grouping results into these subsections? It's hard for me to advise on that without having an example of exactly what you are trying to do.

What sort of field is user_id? If it's an integer or text field that only stores the ID (I assume it is because of the name and way you are getting the user page via the ID) then you should change to a "user_page" Page Reference field that will hold the actual User page object. On the Advanced tab of the settings for the user_page field tick the Autojoin checkbox. That way the User object associated with each portfolio-detail page will automatically be loaded in a single database query when you do... $profiles = $pages->find("template=portfolio-detail"); ...rather than needing multiple database queries within the foreach. In the foreach you will get the field values from the User object like this: echo $portfolio->user_page->firstname;

I think the "correct" way to do it, is how you have it implemented now: for each portfolio, you query the related user to obtain the additional data. It's true that if you are constantly making queries of this type (ex: inside a loop), that performance is not optimal. Maybe if you use some kind of page/template cache you can solve it. Another way could be to keep a copy of the user's data in a "user" field of the portfolio template (using a textarea field and save all user data in JSON, or use the new ProFields Combo field) and implement a synchronization system based on hooks, then in the users' Page Save hook, find the related portfolio and updates that JSON field. ?‍♂️

I thought this would be a nice job for a PW dev, so decided to advertise it to all of you: https://blog.documentfoundation.org/blog/2021/05/26/tender-to-implement-the-new-tdf-membership-committees-web-based-tooling-202105-01/ Deadline for applications is June 23, 2021. I was not involved in writing the specifications, but I will be reviewing the applications. The spec has some unfortunate language discrimination, but you can ignore it: "we strongly prefer Python/Django or Ruby on Rails over PHP". The spec also has very detailed definitions for database tables and configuration options, but I would treat them as inspiration rather than dogma. Plugging into our single sign on service would preferably be done with SAML 2.0 and fortunately there is a module for that. I have also been in the Membership Committee, so am able to answer questions about how it works.

The Architekturforum Freiburg sees itself as a regional platform for information and exchange about architecture, urban planning, landscape architecture and building culture. On the website you can register for events, view presentations or become a member. The website uses UIkit as framework and Workbox for the PWA. architekturforum-freiburg.de Features: Dynamic primary color Structured data Dynamic primary color The events are grouped in programs and every program can have its own color. For this I used the awesome module Color. I defined a fixed color palette, so that no ugly colors could be selected and I worked for the first time with CSS variables. With CSS variables you are more flexible than with f.e. SCSS variables and can change the primary color for the whole website on the fly. This is used on the detail page of events with a different primary color. Structured data It was important for me to provide the correct structured data for the events. Since the pandemic they have been enhanced for online, offline and mixed events. Modules used: Repeater Matrix Form Builder Functional Fields Map Marker ProCache Upgrades TOTP two-factor authentication Tracy Debugger Color Sitemap Email Obfuscation (EMO) Regards, Andreas

Note that when using id="date" you may only use one date on one page. I'm not using HannaCode at all, maybe you can use PHP to generate an unique id? <?php $id = "date_".uniqid(); ?> <p id="<?= $id ?>"></p> ... document.getElementById("<?= $id ?>").innerHTML = datum;

I'm making a function which just returns an image based on the current page. I set global image options in '_init.php' and wanted to use this variable in '_func.php' but it throws an undefined error. '_init.php' is appended on every page. Below is how it works now, but I've had to redefine the image options twice: // _init.php // Global image options $options = array("quality" => 80, "cropping" => "center"); // Include shared functions (if any) include_once("./_func.php"); // _func.php function getMetaImage() { $page = wire("page"); $pages = wire("pages"); // max height of uploaded landscape image = 1200px $imgHeight = 1200; $imgWidth = 1200; $options = array("quality" => 80, "cropping" => "center"); // <<<< want rid of this // if /tutorials/blog-entry/ if ($page->postThumbnail && $page->parent->id === 1017) { $metaImage = $page->postThumbnail->size($imgHeight, $imgWidth, $options)->httpUrl; } // if /tutorials/blog-entry/blog-entry/ elseif ($page->parent->postThumbnail) { $metaImage = $page->parent->postThumbnail->size($imgHeight, $imgWidth, $options)->httpUrl; } // default image on /site-settings/ else { $metaImage = $pages->get(1319)->postThumbnail->size($imgHeight, $imgWidth, $options)->httpUrl; } return $metaImage; } // /includes/header.php <meta property='og:image' content='<?= getMetaImage(); ?>'> Is there a way to define the global options just once and use them in my functions file? Thanks for any advice.