Leaderboard

This week I've been finishing updates for many of the Pro modules with new versions posted today for the following modules: FormBuilder (v55) ProCache (4.0.5) ProMailer (v13) ProDrafts (v10) ProDevTools Form Auto Saver and Reminder, also posted in FormBuilder (v3) ProDevTools Page Auto Saver and Live Preview (v8) ProFields Combo (v12) ProFields RepeaterMatrix (v11) ProFields Table (v25) ProFields Verified URL (v6) ProFields Textareas (v10) ProFields Multiplier (v15) These new versions don't necessarily contain new features, with a few exceptions. But they do contain maintenance updates for PHP 8.2+ and jQuery 3.6+ where needed. They also contain various small fixes, improvements or documentation adjustments. Pro modules not mentioned above will also receive updates in the coming week (or weeks). I thoroughly tested all of these modules with ProcessWire 3.0.227 before posting. But all of these versions are posted as "dev" or "development" versions. What does that mean? It means that that at the time it was uploaded, I was the only one using it so far, and thus they've only been tested thoroughly by me, today at least. The term "dev" doesn't mean that the version isn't stable. In fact, often times the dev version may be more stable than the last posted non-dev version. (Kind of like how the core dev branch is often more stable than the master branch). The dev designation just means that I can't claim it to be the most stable version until it's been out for a little while longer, with more people testing it. If you see a dev version posted that has been out for several weeks, then you can usually consider that the current stable version. The exception would be if it also says "beta", or something else to indicate it's a testing version. Early this week the core master/main branch was also updated to version 3.0.227. This version contains fixes for bugs reported since 3.0.226 master/main was released. A 3.0.228 bump is also in the works for the core master/main branch. I'll likely be working on Pro module updates for another 1-2 weeks here, along with issue fixes to the core. As a result, the 3.0.228 version will likely be merged to the master/main branch in the next couple weeks as well. I figure we might as well keep updating the main/master branch with small fixes and such until we get into more major dev branch updates. Thanks for reading and have a great weekend!

The module provides a paths under which cronjobs can be registered. It lists all registered cronjobs and can execute individual ones manually. The last execution, the last status and, in the event of an error, the last error message are displayed. Download & Install Github: https://github.com/neuerituale/ProcessCronJobs Modules directory: https://processwire.com/modules/process-cron-jobs/ Composer: coming soon

That's why Softaculous announced a new version in their installer. Until this moment I thought they'd support the DEV versions now and was totally thrilled... but ok. I'm totally for it. That signals ProcessWire is alive and well (see the Softaculous post above) and people can see it. To be honest here: we all should push way more details about your and the overall work on and the features of ProcessWire to the outside world. But that's another topic for another day. Have a great weekend, @ryan!

There seems to be a module that does what you need: https://processwire.com/modules/restrict-tab-view/ (at least for the tabs! I haven't used it though). But you can do both quite easily with two hooks in /site/ready.php - unfortunately you can't do everything in one hook because you need to hook "before" and "after" the buildForm(Content): <?php // hook to make the title field non-editable $wire->addHookAfter("ProcessPageEdit::buildFormContent", function ($event) { // get the page being edited $page = $event->process->getPage(); // check if the page has the desired template if ($page->template != 'your-template') return; // check if the user has the desired role if (!$this->wire->user->hasRole('admin')) return; // get the form that was built in buildFormContent() method $form = $event->return; // make the title field non-editable $f = $form->get('title'); $f->collapsed = Inputfield::collapsedNoLocked; }); // hook hide the settings tab $wire->addHookBefore("ProcessPageEdit::buildForm", function ($event) { // get the page being edited $page = $event->process->getPage(); // check if the page has the desired template if ($page->template != 'your-template') return; // check if the user has the desired role if (!$this->wire->user->hasRole('admin')) return; // set noSettings property dynamically $page->template->noSettings = 1; });

You all are such professional designers that I hesitate sharing my site here, but it might show what Processwire can do even for 'average' users. I created this site with Processwire for the County of Ventura's Assessor's Office. It is a redo of the previous site done in ASP that was showing it's age. The goal was to provide a more modern design that would work with desktop or mobile while at the same time providing more features for the taxpayers to access data and communicate with us. While most of the County Government sites use WordPress (or similar) they graciously allowed me to give Processwire a try. I think it performs admirably, is easy to maintain, very fast, and actually fun to work with (most of the time....?). http://assessor.countyofventura.org Most of the site is handled by two main templates, one for the summary pages, and one for the detail pages. I also created a 'dummy' template to act as a folder to hold the pages for each category (to make a manageable hierarchy) . This made it easier for me to find things on the back end and mimics the front end nicely. On the back end there are several templates that hold things like forms (pdf downloads), links, glossary terms, frequently asked questions, form responses, and more. All of these are dynamically included into the front facing pages based on their content and how they relate to the individual pages. Fillable forms were the hardest part for me. I tried working with some of the free modules for this sort of thing but I could never wrap my head around them. In the end, I just did it by hand with standard PHP forms combined with using the Processwire API to save the results to the database. It works fairly well but I'm sure there is a better way. A big thank you to everyone on this forum for their help and tips both directly and indirectly, and to Ryan who makes this fabulous software available to us. Any suggestions on the site are welcome.

Hi @Stefanowitsch I think it is safe to delete the one in /site/modules. If you want to be more cautious, you can move /site/modules/InputfieldTinyMCE to another location first to see if there is any side effects. Gideon

unpoly is good! I used it in some of my project and I really love it. The tailwindcss standalone CLI is another wonderful tool, too. Gideon

@szabesz, I am quite with you as I have been toying with unpoly and htmx a bit, and understand quite well that one should sometimes work hard to achieve with htmx something that comes with unpoly out of the box. I was just saying that AlpineJs has a different purpose (Js sprinkles, jQuery replacement) and is used with either htmx or unpoly.

Yea these is how I think about it as well. HTMX is less opinionated and I like it that way. However HTMX is not the "JS sprinkles" (it's more for HTML over the wire requests) so that's where Alpine.JS comes in. While Unploly is definitely more opinionated for sure, that's also its strength and weakness at the same time. If someone starts using AlpineJs along with Unploly, then that person should use HTMX + AlpineJS instead in the first place. While Unploly is definitely more opinionated, it does not mean that based on Unploly is not possible to implement the same features that one would implement using HTMX + AlpineJS. You just need a completely different mindset when using either this or that. By using HTMX + AlpineJS one gets a sort of "lower level" solution while Unploly provides "higher level" tools. Using high level tools has the benefit of also dealing with documented conventions out of the box, while building upon a low level tool requires you to put more work in your documentation. High level tools has the drawback of sometimes having to find workarounds for different use cases, while low level tools introduces less of such issues. I don't want to persuade anyone to use Unpoly, but I want to mention that I use and love it, particularly because upgrading to major versions is always backward compatible. (Backward compatibility support extends to the previous major version.)

If Unpoly was non existent I would sure use AlpineJS + HTMX these days. However, https://unpoly.com/ does exists and to me, having to use only one technology instead of two (or more) is very important. The fewer I have to deal with the better. More importantly, easy upgrade path is essential, so no wonder I am not willing to leave ProcessWire :)

Nice site, congrats! Tip for everyone outside the US: Try visiting with the Tor browser. I could access it without problems from Switzerland. re: forms I can highly recommend the Pro module FormBuilder from Ryan. Well worth the money.

You forgot to call the fieldname 'button' - you are echoing the repeater items (which uses the ID as toString output). Try this: <div class="caption-cta-wrapper uk-margin-medium-top"> <?php // 'buttons' is a repeater field, so '$btn' is a repeater item foreach($page->hero->buttons as $btn) { echo $btn->button; // <-- fieldname! } ?> </div>

I like to re-use most of the fields. For example in most projects i have one body field, one headline field and one (single) image field. With fieldsets I can reuse these fields as often an as much on a single template as I want. As long as the field settings not differ that much there is no use to create a "body2" or "body3" field. BUT if you need to alter the field settings in one case it is possible to override these changes on a fieldset-basis. For example I have this fieldset here with two generic input fields: A single image field and a body copy field. These are generic fields that I use all over the place. If I want to make slight changes to those fields in the context of the fieldset I can edit the fieldset and then click on the name of one of the fields inside it. This will open a dialogue where you can override very basic field settings. It is in most cases not possible to customize a field very much this way. For example you can't change the width and height cropping properties on an image field.

Actually you should leave the styling of the uk-container untouched, because that it is a necessary UIkit class. You can get the container to be full width by adding the class uk-container-expand. <div id="masthead" class="uk-container uk-container-expand">

My use of Node was as follows (well it was based on Laravel Mix): downloading packages (package.json / node_modules); for example, getting UIkit, jQuery and whatever else a project required compiling SCSS or Tailwind creating a dist folder with that CSS, other compiled JS and images cache busting As for downloading packages, I have my own ProcessWire module that contains unminified and minified versions of the packages I commonly use or that I deem to be worthy enough to be in the module. I built a very simple way to update those packages and include them in my project as well as well. UIkit is a special case in that it's both SCSS and JS files. If I want to include HTMX for example, I just do this: setting('htmx-enabled', true); and everything gets inserted as it should. The potential drawback of this approach is that because I use this module across many different projects, all projects automatically get upgraded to the latest version of a package which could potentially break things, but that's rare and not a big issue for me. For compiling SCSS, I would have stuck with ProCache (SCSSPHP) but it's completely outdated and that's just not going to change. Therefore I use DartSass. You can download the executables here: https://github.com/sass/dart-sass/releases I've hacked ProCache (because it doesn't have the necessary hooks) so that instead of using SCSSPHP, it uses DartSass. Ryan has expressed the ability for ProCache to be more friendly to using outside compilers so hopefully a future version of ProCache doesn't have to be hacked directly. As for Tailwind, during dev I use Tailwind Play CDN. During production, similar to DartSass, I use TailwindCSS CLI and I hacked ProCache to make it work with it as well: https://tailwindcss.com/blog/standalone-cli https://github.com/tailwindlabs/tailwindcss/releases/tag/v3.3.3 Both DartSass and TailwindCSS CLI have minifiers built-in, so therefore I avoid using ProCache's CSS minifier which has been a a little buggy (although I think it's now fixed?). Technically speaking, TailwindCSS CLI is Node.js under the hood, but it's wrapped up into one executable which feels clean. For what would typically be a "dist" folder, I just avoid that. ProCache Buster handles that in its own way. Yea these is how I think about it as well. HTMX is less opinionated and I like it that way. However HTMX is not the "JS sprinkles" (it's more for HTML over the wire requests) so that's where Alpine.JS comes in.

I'm also very interested in this answer! I feel I'll never leave compiling SCSS/Less in PHP, even it means using an outdated subset of Less, it's just so convenient! I'm very sold on HTMX + AlpineJS, main reason being it saves me from the build step.

Hi, and welcome to the forums! I suggest starting with this thread, which gives various options: Let us know if you need further help!

In your CSS you have .uk-container { display: flow-root; box-sizing: content-box; max-width: 1200px; /* <<<< */ } That's the culprit.

@Jonathan Lahijani, would you mind elaborating on this a bit? How do you manage your frontend without node based build chain? I am very interested as I am moving along a similar path, having ditched gulp. Now I do not even concatenate my js leaving it to http2. The only thing i still compile is scss) How do you do it nowadays?

This week there have been a few updates to the core on the dev branch, but nothing major. Next week I'll be bumping up the version to 3.0.227 and then likely merging back to the master/main branch again. While there aren't major updates relative to 3.0.226, that means there isn't a lot to test or break, so it makes sense to keep updating the main/master branch until we get into more significant updates on the dev branch. In addition to getting into more significant dev branch updates, I'm also planning to put out version updates on nearly all the Pro modules in the upcoming weeks. Thanks for reading and have a great weekend!

Yes it is... Instead of using composer just download the 2 libraries: Google recaptcha for validating the user is not a robot (https://github.com/google/recaptcha) Valitron validation library for validating the form fields (https://github.com/vlucas/valitron) unzip them inside a folder ...and replace the lines: include(dirname(__FILE__) . "/../../vendor/vlucas/valitron/src/Valitron/Validator.php"); include(dirname(__FILE__) . '/../../vendor/google/recaptcha/src/ReCaptcha/ReCaptcha.php'); with: include(dirname(__FILE__) . "yourfolder/vlucas/valitron/src/Valitron/Validator.php"); include(dirname(__FILE__) . 'yourfolder/google/recaptcha/src/ReCaptcha/ReCaptcha.php'); Hope it helps! Actually composer doesn't do any magic...it just downloads the libraries inside the vendor folder but you can always do it manually if you want.