Leaderboard

*NOT 🤣

This week I’m going to briefly tell you about what we’ll have for you next week. If all goes according to plan, the new admin theme will be committed to the dev branch by this time next week. Technically it’s not a new admin theme in the module sense, but rather a new look for the AdminThemeUikit theme. (The original look will be there too, should you want to keep using it.) There are a lot of cool things about the new look, but here’s a few things to whet your appetite: 1. It comes with a “dark” mode, and a really fantastic dark mode at that. Every user can choose whether they want a light or dark version of the theme, or they can switch on-the-fly from any page. Both the light and dark versions of the theme are equally beautiful and refreshing. 2. The configuration screen lets you choose what your “main” color is for the theme, whether using predefined traditional PW colors, or a color picker where you can choose your own. 3. This theme also customizes the look of TinyMCE, so that it fits right in with the rest of the interface. 4. If you want to change more about the appearance of theme than what’s on the module config screen, you can do so with a custom CSS file. And there are more than 30 CSS variables that are easy to understand and customize. More next week, so stay tuned!

Most Markdown parsers allow raw HTML to pass through by default. This is the case with Parsedown, the parser used by TextformatterMarkdownExtra. I've just tried Test Markdown in TextformatterMarkdownExtra settings (v. 1.8.0, PW 3.0.210) and it passes through HTML as expected.

Hi again, actually it's sooner in the code that i would have siwtched to array functions like foreach, map and so so on, more something like $allEvents = $pages->findMany("has_parent=$player->id,template=event,date>=$dateStart, date<=$dateEnd"); foreach($allEvent as $ae){ if(...) { // here come your conditions like $e->template == '... ' $ae-date>= and so on $player->negAttitude = ... // and here trhe details/pages... you store } } the case you descibe is normal, allEvent (result of a pages find is an array of pages and as much as i love working with objects, php is reallt fast and strong with arrays and in your code you switch from object ($pages) to array ->find() result) and then again to object methods ($player->negAttitude = $allEvents->find...), i can try and guess why foreach may become a little reluctant to eat what you give 🙂 honestly, what i do in this kind of situation is to dump/print_r the result step by step to see exactly what i get and then which will be the best method to use and parse it and of course, once i've switched from object to array i try to stay with it to avoid surprises 🙂 have a nice day

Hey @Bia welcome to the forum. I might be wrong but to me it sounds like you still have a wrong assumption what ProcessWire is and how it works. ProcessWire is a development tool to build websites or anything similar. You can not only build websites with it but also intranet applications, backends for single page applications, etc... That means whoever built your website did it THEIR way. Nobody else can know how the website that you are looking at works under the hood. That means if you really want/need to change anything on your website there is a 99% chance that you need to change some code for this. That also means you need access to the files of your website. That also means that you might need to understand how your website is deployed to the server. Your developer might have just copied all files to your server. But he/she might have setup an automated deployment pipeline. It also means that it would be wise to first test all your changes locally before you push them to production. Otherwise you risk to break your site and then it might be down until someone can fix it. If you don't have someone for that at hand you risk to have a very bad time with some very uncomfortable questions 😉 But of course it also depends on the type of website you are working on. If it's not important and does not have lot of traffic this might not be a big deal... Who knows. I think in your situation it would be the best to find someone experienced to have a look at your project for maybe an hour or two that can explain to you how everything works, how it is setup and what to expect in terms of future maintenance or development and hosting. I'm not talking about how it works in detail but to get the big picture. Then you can decide how to proceed. If you want me to do that you can write me a PM or request a meeting at https://www.baumrock.com/en/contact/. There are probably cheaper options though. You can also ask for help in the jobs board or, of course you can always ask questions in the forum. It's a friendly community and answers are free, but while usually you don't wait long for answers it would probably not be the quickest way in your case. Having said all the above to answer your question: If that form is built in code you'd have to open an IDE and search for the term "Culoare:" or "Colored" or "White" in your codebase. Then you might find the file that is responsible for the dropdown. If you don't find anything in code then it means that your developer used some kind of form builder and the data is stored in the database, not in code. Hope that helps 🙂

Ever needed a color picker on some kind of settings page? Didn't want to install and setup a full-blown colorpicker module? Here's a quick and dirty hook to change a regular text field into an <input type="color"> type of input: Before: After: <?php public function init(): void { wire()->addHookBefore('Inputfield::render', $this, 'changeFieldType'); } public function changeFieldType(HookEvent $event): void { $f = $event->object; $colorFields = [ Site::field_col_primary, Site::field_col_secondary, Site::field_contrast_primary, Site::field_contrast_secondary, ]; if (!in_array($f->name, $colorFields)) return; $f->attr('type', 'color'); } So right before the text input is rendered we change its "type" property to "color" and the browser will render a default color picker 😎 It once more shows how versatile ProcessWire is. And maybe it helps someone... 🙂 PS: Be advised that with that hack you only modify the optics of the field. The field will under the hood still be a regular text field, which means you'll not get any sanitisation or such from it and you might have to take care of that on your own. In my case it's a superuser-only settings page. So it is no issue at all.

I am considering open-sourcing Padloper (and my other commercial modules). Please read and hopefully participate in the discussion in the Beer Garden (away from Google's prying eyes). Thanks.

LogMaintenance A simple ProcessWire module to give some maintenance control over log files. I found myself often having lots of log files for different things that can grow more or less quickly to a size where they can be difficult to maintain. The built in Logger of PW does a good job of giving you the possibility to delete or prune logs. But it has to be done manually and sometimes a log grows into millions of lines, which makes it often impossible to even prune it as it's too large. LogMaintenance uses LazyCron to run the maintenance task and there's several settings you can setup on a global or per log basis. Archive: will create zip files for each log file in logs/archive/ folder and add the log each time the maintenance is run to a subfolder containing the datetime. Lines: keeps logs to a certain number of lines Days: keeps the log to a certain number of days Bytes: keeps the log to a certain amount of bytes Each setting is checked from top down, the first setting to contain something is used. So if you check the "Archive" option, all other settings are ignored and logs are archived everytime the LazyCron is executed. If you want to keep your logs to a certain amount of bytes just leave all other settings to 0 or blank. Per Log Settings There's a textarea that you can use to setup a config for a specific log file one per line. All the logs you define here ignore the global settings above. The syntax for the settings is: logname:[archive]:[lines]:[days]:[bytes] errors:1:0:0:0 // would archive the errors log messages:0:10000:0:0 // will prune the errors log to 10000 lines The module can be found on github for you to check out. It's still fresh and I'm currently testing. https://github.com/somatonic/LogMaintenance

This module has several bugs. Line 113 must be: if($archive == '1') { Line 159 must be: if($this->archive == '1') { Line 295 must be: $field->attr('name', 'bytes'); Forked here: https://github.com/techcnet/LogMaintenance

@adrian thanks! I've found one more solution that addresses own Q and does not require code. It is as simple as (1) setting "Don't allow unpublished pages" in template advanced settings and (2) adding role-publish permission in template access tab. As a result, there are no unpublished pages => no "pub/unpub" buttons while user in role is allowed to edit published pages.)