Leaderboard

Hey All, I thought I'd jump on here and share my first 3 ProcessWire sites! LatticeWork (https://www.latticeworkinc.com/) - This one is live but still being actively developed in preparation for targeting an international audience (so current translations need auditing and it's not yet GDPR-compliant). The multilingual capabilities offered by ProcessWire, in contrast to WordPress, were the catalyst for starting my PW journey. The added performance that will be necessary as we deprecate some international sites and push everyone here was another decision driver for choosing PW. Obviously many thanks to @ryan and other core contributors for such an incredibly refined core product that regularly surprises me with features and functionality that I didn't know I was missing. Additional thanks go to @FireWire for the Fluency add-on, @Mike Rockett for Jumplinks, @Wanze for SEO Maestro, @teppo for Search Engine, and again Ryan for Pro Fields. These were invaluable. The Mart Group (https://www.martgroup.com/) - This site was my second to build with ProcessWire, though it was completed first due to its smaller size. In addition to all the prior thanks, I really appreciated RockFrontend by @bernhard while working on this one. Lori H. Cole (https://www.editsbylori.com/) - I probably wouldn't mention this single-page site I built as a favor, except to point out that PW is so lean and easy to work with I was able to give the client the ability to edit their own site without much server overhead or added development time. I did the front-end development work on these, which as a designer/animator hasn't historically been an area I'm comfortable in. ProcessWire has been such a delight to use that it has re-kindled my interest in working more with code. So, in time I hope to get more creative with the front-end coding as well. Thanks!

Like last week, this week the focus has been on adding feature requests from our processwire-requests repository. Though I'd like to give it another week before bumping up the version number. Rather than repeating all that was added here, please see the dev branch commit log, which covers them all, several with more detailed notes in the commits. The biggest added feature request was likely the API updates for getting/setting multi-language values, but there are several others as well. I was excited to see the new jQuery 4.0.0 release this week, which we'll no doubt be upgrading soon (or once out of beta). Here's a quote from the intro of their new post: Some parts of ProcessWire's API were originally inspired by jQuery. It's always nice to see progress there with new versions, especially a new major version. Thanks for reading and have a great weekend!

@ryangorley Nice work, great sites! Would you consider adding them to the sites directory? https://processwire.com/sites/submit/

Really great sites, congratulations! Happy that RockFrontend was helpful and thx for letting me know ?

As of today on the dev branch, this is now possible with a new hookable method InputfieldPage::renderPageLabel() https://github.com/processwire/processwire-requests/issues/460

Makes sense to update to jQuery 4 once it's available and stable, but I must admit that when I read that article my first thought was "holy crap, they are still going on?" ? Serious question to @ryan: what's your take on jQuery these days, do you still see it as something we will be, or should be, relying going forward? I'm not trying to push any agenda here, but I am wondering if you'd be open to perhaps starting to migrate more of ProcessWire's core code to vanilla JavaScript. I'm also not going to go into the "but what about Vue / React / Alpine / HTMX / insert-name-of-any-other-library-or-framework-here" topic at this point; that's a whole different subject. Also: all modern libraries are advocating the use of native JavaScript API's instead of "framework specific magic" anyway, so vanilla JS would be a good first step towards something new. In my opinion (which I've probably voiced here on the forums a few times already) jQuery is now largely obsolete. And I'm saying this as a former fan — it was amazing back in the days when native JS API's were very crude and lacking. Today it's more of a problem. For those that don't know what I'm speaking about, one example is the way jQuery handles events: the API is nice, but also hacky and non-standard, leading to the fact that in order to combine (standard) JS events with jQuery events you essentially need yet another library. (And vendor lock-in, intentional or not, is not a good thing.) Personally I find myself reaching for jQuery in pretty much one specific case: many third party plugins/libraries still rely on jQuery. This is less of an issue every year as devs keep moving forward, but there are still many popular plugins that do require jQuery. For every need there is a non-jQuery solution, but it can take a bit of work to find / migrate to. Some things are admittedly more difficult to replace, and one of those is jQuery UI. But since jQuery UI is already in "maintenace updates only" mode, replacing it is likely something that has to be done at some point. (Also... form serialization. That is something they did really well. And no, vanilla JS FormData is not a direct replacement ?) Sorry for the long rant, but I just felt that this needed a bit of context. I for one would be happy to submit PR's etc. that would move us towards fewer dependencies for jQuery if that's something that'd be beneficial for the project. I believe it would be, but that's just me ?

Nice work as always. I upgraded 2 sites in development this week to jQuery 4 and everything worked just fine. Scripts we had made, Swiper, Splide, Fancybox and a few other go to scripts all worked fine. I think it's about 10% lighter as well, maybe more which is always welcome. Nice to see one of my request hit the commits. Have a great weekend.

Template Access A Process module that provides an editable overview of roles that can access each template. The module makes it quick and easy to see which templates have access control enabled (personally I like to ensure I've enabled it for every template) and to set the appropriate access per template. Usage The Template Access page under the Access menu shows access information for all non-system templates in a table. You can filter the table rows by template name if needed. Click an icon in the table to toggle its state. The changes are applied once you click the "Save" button. Sometimes icons cannot be toggled because of logical rules described below. When an icon cannot be toggled the cursor changes to "not-allowed" when the icon is hovered and if the icon is clicked an explanatory alert appears. A role must have edit access before it can be granted create access. If the guest role has view access for a template then all roles have view access for that template. https://github.com/Toutouwai/ProcessTemplateAccess https://processwire.com/modules/process-template-access/

One of the ways you can show support for ProcessWire is to help get the word out by including a small "Powered by ProcessWire CMS" tagline (ideally linking to processwire.com) in the footer of sites that you develop. This is a big help to the ProcessWire project. But I know there are many cases where it just doesn't work to do that because the client thinks of it as gratuitous. I think it's important to communicate to your client that it's not gratuitous at all. It is doing the right thing by showing appreciation and support for a software that is running their site at no cost. Even so, it's not always as simple as that, and I completely understand. We have no requirement or expectation that sites developed in ProcessWire do this. We just encourage and appreciate it when you can. Let your client decide One thing I've been doing lately is to put the control into my clients hands. They really appreciate that I've given them control over it… more so than if I'd left out mention of ProcessWire completely. It also makes them feel good as they are the one showing support, not just their site developer. Here's how to do it in 1 minute: 1. Create a new "checkbox" field in Setup > Fields called "toggle_powered" (or whatever you want to call it), and enter the following for label and description: 2. Add the "toggle_powered" field to your homepage template. 3. Edit the homepage and check the box (if possible in your situation). 4. Edit the template file or include file that contains the site footer and paste in the following: <?php if($pages->get('/')->toggle_powered): ?> <p> <a id='processwire' target='_blank' href='http://processwire.com'>Powered by ProcessWire Open Source CMS/CMF</a> </p> <?php endif; ?> The code above is an example, so adjust the markup, size, wording and placement to suit the site.

Hi all. I have decided to publish one of the plugins I have been working on in my free time during the last few days but actually was motivated by our needs at work. It is currently in early beta and much of the functions might be subject to change. Before you jump at my throat and tell me that I am copying RockMigrations by @bernhard, please read on! System Config Versions This module adds an admin interface for developers to manage configuration revisions. Think of it as git for PW configurations ?. It ensures that revisions only get run once. It is possible to run multiple revisions up to a certain point or even all available ones. Aren't you just copying RockMigrations? No. I made this plugin because at work, we needed more precise control over migrations and also do a lot more in migrations than adding&removing structural configurations. Often times, we use small snippets to change field data throughout the process of creating websites. And these may only be run exactly once. Actually, we are usually using RockMigrations alongside this plugin to use it's very impressive function set! Think of this plugin as a way to persist run status for any migrations and ensure any migration only ever gets run once. Simple Case Study The motivation behind the module is best described with a code example: <?php namespace ProcessWire; /** @var RockMigrations $rm */ $rm = $modules->get('RockMigrations'); $rm->createField('richtext', [ 'type' => 'FieldtypeTinyMCE', // ... ]); $rm->addFieldToTemplate('richtext', 'basic-page', 'textarea'); $pagesToUpdate = $pages->find('template=basic-page'); foreach ($pagesToUpdate as $pg) { $pg->setOutputFormatting(false); $pg->set('richtext', $pg->textarea); $pg->save(); } $rm->removeFieldFromTemplate('textarea', 'basic-page'); The goal of this revision file is to convert an existing textarea field of all `basic-page`s to a richtext field. The code snippet which maps the contents of the fields is obviously part of the revision and with bare RockMigrations, we have no control over how many times it gets run. With SystemConfigVersions, the snippet gets run exactly once. More Info & What's next? For usage instructions and details, refer to the repo's README. Do you guys have any first impressions or any recommendations or ideas for this project? Is there even a need for it in a broader sense? You can find the GitHub repo here: https://github.com/poljpocket/SystemConfigVersions Some ToDo's as of now: URGENT: Greatly improve error handling Add GitHub Actions support to automatically apply all new versions Add ability to reset run status down to a certain point Revise documentation below Add configurability for versions folder location and file naming scheme Add folder as version support (e.g. all files inside a version folder are executed and treated as one revision).

Hey @adrian please apologise for the subject ? I love Tracy - This is either a feature request or a question to understand why you built it in the way it is and maybe just a question of where I find info in the docs ? I'm creating a custom panel for RockFrontend so that RockFrontend can even live-reload pages that throw fatal errors or where latte {include ...} tags point to a wrong file. Until now I needed to hit refresh manually for those files which is tedious in the long run. All I really need to do is to inject my javascript: <?php namespace ProcessWire; $rf = rockfrontend(); $secret = $rf->addLiveReloadSecret(); $script = $rf->addLiveReloadScript(); if (!$script) return; ?> <script> LiveReloadUrl = '<?= $pages->get(1)->url ?>'; LiveReloadSecret = '<?= $secret ?>'; document.addEventListener("DOMContentLoaded", function() { var script = document.createElement("script"); script.src = "<?= $script ?>"; document.head.appendChild(script); }); </script> I even wouldn't need a panel for this, just a hook that adds my markup whenever the debug bar is rendered on the page. But I did not find one. Is there one? But the question remains why adding simple panels is so complicated. I found out thx to @teppo's WireFrame panel that I need to place my panel in /site/modules/RockFrontend/TracyPanels/MyPanel.php, which is already great. But still... if I only want to show an icon in the bar, a label on the panel and some HTML inside the panel body, this is what I have to do? <?php namespace ProcessWire; use BasePanel; class RockFrontendPanel extends BasePanel { // settings private $name = 'rockfrontend'; private $label = 'RockFrontend Panel'; // the svg icon shown in the bar and in the panel header private $icon = '<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24"><g fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2"><path d="M5 5a2 2 0 0 1 2-2h10a2 2 0 0 1 2 2v2a2 2 0 0 1-2 2H7a2 2 0 0 1-2-2z"/><path d="M19 6h1a2 2 0 0 1 2 2a5 5 0 0 1-5 5h-5v2m-2 1a1 1 0 0 1 1-1h2a1 1 0 0 1 1 1v4a1 1 0 0 1-1 1h-2a1 1 0 0 1-1-1z"/></g></svg>'; private $liveReloadStatus = 'disabled'; /** * define the tab for the panel in the debug bar */ public function getTab() { if (\TracyDebugger::isAdditionalBar()) return; \Tracy\Debugger::timer($this->name); $livereload = $this->wire->files->render(__DIR__ . "/livereload.php"); if ($livereload) $this->liveReloadStatus = 'enabled'; return "$livereload<span title='{$this->label}'>{$this->icon} " . (\TracyDebugger::getDataValue('showPanelLabels') ? $this->label : '') . "</span>"; } /** * the panel's HTML code */ public function getPanel() { $out = "<h1>{$this->icon} {$this->label}</h1>"; // example of a maximize button $out .= '<span class="tracy-icons"><span class="resizeIcons"><a href="#" title="Maximize / Restore" onclick="tracyResizePanel(\'' . $this->className . '\')">+</a></span></span>'; // panel body $out .= '<div class="tracy-inner">'; $out .= "LiveReload status: " . $this->liveReloadStatus; $out .= \TracyDebugger::generatePanelFooter($this->name, \Tracy\Debugger::timer($this->name), strlen($out), 'yourSettingsFieldsetId'); $out .= '</div>'; return parent::loadResources() . $out; } } Maybe it's already possible to do that in a simpler way? I'm thinking of something like this: <?php $wire->addHookAfter("TracyDebugger::getPanels", function($event) { $event->return->add([ 'icon' => '<svg ...></svg>', 'label' => 'RockFrontend', 'body' => $files->render(__DIR__.'/RockFrontendPanel.php'), 'allowMaximize' => 'true', ]); }); Where Tracy would on its own add all the necessary boilerplate that is necessary for measuring timings and memory consumption etc. Thank you for your time and for TracyDebugger in general!! PS: I have the same todo for RockFrontend's topbar ??

Before this ends in a yes, no, maybe, only with custom code answer: Give this a good read: https://processwire.com/docs/front-end/how-to-use-url-segments/ URL segments might feel a bit off at first, but at the end it's only a smaller thing in-between. The initial setup can be tricky but going from there it is like working with any other page or template.

These sites are outstanding! Fantastic work and couldn't agree more with your feelings on ProcessWire. Thanks for the mention as well, it's really cool to see Fluency out in the wild!

Hi @TomPich - the latest version allows blank default filters and hides the parent selector (I moved it from defaultSelector to initSelector).

The Image isn‘t working ?

@TomPich The sprit of the module would be to keep it simple, and create the more complex pieces as separate admin pages. The canonical solution would be the ListerPro module, but this can be done without commercial modules using just the built-in Lister process module that is the basis for ListerPro.

@d'Hinnisdaël Thank you. I’ll explore your suggestions. I’m not sure what you mean by "configuring a separate admin Lister page with filters". But it sounds like being quite straight forward. For now, I’ve been building a custom panel following your documentation. Seems a lot of work. I’m getting somewhere, but I’d rather respect the spirit of your module and and choose a more clever solution to achieve my goal.

@TomPich Nothing built in, so far. Philosophically, I've seen the dashboard as a jumping-off point for users to get oriented, then go off somewhere else in the admin to do more serious work. My suggestion would be configuring a separate admin Lister page with filters, or building a custom Process module if you're feeling adventurous. That said, there are ways of doing this manually: Option 1: render a select input using a `template` type panel, with some JS to auto-submit the form on change. In your php file defining the available dashboard panels, you can then use that input parameter to pre-filter the results. This only works smoothly with selects where a full page reload is acceptable UX, so text inputs would require a different solution. Option 2: create multiple panel tabs, one tab for each available filter option. Still, not very useful for text inputs.

I just pushed an update to the DEV branch that I really believe should be part of the core: That means you can still edit all settings on the module config screen, but you can override any setting in config.php like this: <?php $config->rockmigrations = [ 'syncSnippets' => true, ]; My module now shows that changes in a nice and easy way (bubble 2) and it also comes with links to edit a setting directly (1), which will scroll to the field in question ? What do you think, would this be helpful for your modules as well? Should this be part of the core?

I could probably add an option to support this but I can see it introducing worse issues than it solves. It would make it impossible to save any attribute value where that value has been deliberately set at a value that also happens to be the default. What if the user wants to create a tag where the values should be [[mortgage_calculator default_amount="70000" default_rate="4" default_type="repayment" default_term="25"]]? If all of those attributes get stripped out and you later change the defaults then the tag produces an unintended result. I think the scenario where you have attributes whose default value you intend to later change is a fairly rare one, and in that scenario you'd be better to not configure a default within the Hanna tag but rather use some other means (e.g. inputfield description or notes text in the dialog) to communicate to the user that there's a fallback value that's used when no value is specified and this fallback is subject to change. That way you can distinguish between when a user has chosen a value or not. But if you still want the feature and can live with the side-effects then let me know and I'll look at adding it.

If you like that approach you might like to try the Repeater Depth Helper module which is a development from that earlier idea. It gives you the depth structure for the whole repeater field from one method and also enforces a couple of depth rules to keep things sane.

Thanks @wbmnfktr! Yes, these are using ProCache. I forgot to mention that one, though I worked very hard to ensure uncached pages would be fast upon first visit, which I'm very satisfied with ProcessWire they are.

Looks like now is a great time to dive back in!

By the way, I had a private conversation with @elabx in which we discussed the Migrations module a bit more. Since it said "deprecated in favor of RockMigrations", I originally didn't look into it further. This was a mistake! It basically does exactly what my module does. Just better. And there is absolutely no reason not to combine it with RockMigrations! I have forked that module and put in some early work to update it to namespaces and PHP7/8 compatibility. I might talk to @LostKobrakai to maybe take over or provide some PRs to keep it alive since there is a commercial incentive now. https://github.com/poljpocket/Migrations/tree/pw3-php8 note the work is just on a separate branch for now.

HannaCodeDialogTiny is now in the module directory.