Leaderboard

For me too. In the past I had to manage a Contao website and Contao is since version 4 build on Symfony. So you have to use Composer for almost everything, as far as I know. They have a tool Contao-Manager which provides a GUI instead of using the CLI, but its better if you are very experienced with Composer. This website in particular had many extensions and dependencies, some of them were discontinued, which could easily break the complete Composer setup and with that the whole website. I had spend hours and days just to init, rebuild, upgrade the composer dependencies, just to get the website running on my local environment. I am glad that ProcessWire websites cannot break this easily and I don't have to be a Symfony/Composer master just to install modules. ? Of course as you can tell I am biased and maybe not experienced enough with Contao and Composer. To be fair, you can in theory install extensions in Contao without Composer. Also this just could have been a problem of this particular website.

Whether or not the system is built on top of a framework is, in my opinion, largely irrelevant. Or perhaps it would be better to say that "it is impossible to guess if and how it would've mattered in the big picture". Call me cynical, but dependencies are never free. Each adds weight to the codebase, requires upkeep and maintenance (sometimes including major updates or rewrites), and increases potential attack surface. Also many dependencies — and especially frameworks — bring in their own way of doing things, and since ProcessWire's architecture (hooks, data structure, etc.) is really a major selling point for the system, using a framework could've had a massive impact on that. Part of the reason why ProcessWire is such a brilliant system could very well be due to it not being powered by a framework itself. This means that every decision could be made without considering how that would fit the framework. What is also interesting, in my openiin, is the framework landscape itself. Back when ProcessWire 2.0 was launched, Laravel — now considered the latest state of the art PHP framework — wasn't even around yet. Zend Framework was probably the biggest name back then, or at least the one that most serious developers considered "most likely to thrive and stay around"... yet it was discontinued. Had ProcessWire gone with the "safe bet", that would've meant a big rewrite later, or alternatively staying on a platform that is merely a shadow of its former glory. Long story short, I think Ryan made a good choice ? Don't get me wrong, though: I'm a big fan of the Composer ecosystem — almost all of my modules are available as Composer dependencies, etc. And, in my opinion, ProcessWire actually integrates quite nicely with external dependencies. Since HTTP clients were mentioned, I'll use that as an example as well: in some recent projects I've used Guzzle together with ProcessWire. I may not be able to (easily) swap the client used by the core itself, but I've yet to come across such a need anyway. Of course this comes with a cost: I recently had to migrate one project to a new server simply because a third party dependency decided to drop PHP 7.4 support. In a minor version, because why the heck not. Not that it's a bad thing necessarily to bump up the PHP version, but having to do that sort of thing in a hurry just because I prefer to use a recent and patched version of a dependency is just bollocks. This is starting to get a bit rambly, so I'll just leave it here.

Honestly, the fact that PW does not require composer is a selling point for me. I develop on multiple hardware, depending on where I'm at (home on my gaming machine, at work on a business class PC, or on my 2011-era Macbook Air) - all running a Docker-based solution with shared file access to a Dropbox instance (in other words: very slow access to host OS files in the virtualized host OS). It took well over an hour for my Macbook Air to finish its composer install of Statamic. When the non-composer version of it was available, it took a little over a minute to unpack everything. There are absolutely massive benefits to standing on the work of others who have come before, but the massive inclusion of unnecessary code also exists (and @wbmnfktr already mentioned the additional attack vectors and need to keep things up-to-date, and how things can break from dependencies). I'm always concerned with one small included library in a composer setup getting a repository pull request from a bad actor that gets accepted...and then any/all platforms that use that little library (and keep up-to-date) are now essentially, unknowingly, vulnerable. I'm glad that ProcessWire offers both options. Having a composer option is awesome. When solutions don't offer a simple alternative to composer, it just sucks (for me). I wish I had more to provide in terms of similar CMSs to compare to ProcessWire, but the only ones I'm aware of, and I don't even entirely consider them all too similar, have already been mentioned. ? Some features of Grav CMS, maybe, are comparable in terms of its intention for customization.

I want to set up one of the many self-hosted project management systems that exist, but I haven't really thought about this since the late 2000s (I experimented with Redmine a long time ago). My needs are not intense. It's mostly ticket creation and tracking. What's a good, preferably PHP-based, system that you recommend? Some options: https://github.com/awesome-selfhosted/awesome-selfhosted?tab=readme-ov-file#software-development---project-management

Thanks to @Sanyaissues for the great work and PR that makes FormBuilderHtmx work when rendering in loops of repeater field content ?. Latest version on Github has the fix merged. Available for download on the main branch.

I oftentimes create a checkbox field called 'test' and assign it to certain templates. I check the box if the page is a test page. These pages may exist on the live site and I don't want to hide or unpublish them, but at the same time, I don't want them to appear in the XML Sitemap. (not part of this tutorial, but I also noindex,nofollow those pages using a meta tag in the head so search engines don't index them) In that case, you can remove them from the WireSitemapXML like this in /site/ready.php: $wire->addHookAfter('WireSitemapXML::allowPage', function(HookEvent $event) { $page = $event->arguments('page'); if($page->hasField('test') && $page->test) $event->return = false; });

Change Default Language to be None-English | Walk Trough When you start a new (single) language site and the default language shouldn't be English, you can change it this way: Go to the modules core section: Select the Language ones by the filter function: We have four language related modules here, but for a single language site in none english, we only need the base module, named "Languages Support". So go on and install it. After that, you can leave it, ... ... and switch to the newly created Language section under SETUP: Select the default language Enter your new language name or its Shortcut and save the page. I will use DE for a single language site in german here as example: Now I go to the ProcessWire online modules directory, down to the subsection for language packs and select and download my desired (german) one: After downloading a lang pack as ZIP, I go back into my SETUP > LANGUAGES > default language page in admin, select the downloaded lang pack ZIP and install it: After the ZIP is uploaded, the files are extracted and installed, most of my screen is already in the new default language. To get all fully switched, we save and leave that page, ... ... and completely logout from the admin. Now, of course, we directly login back, ... ... and see, that now also the cached parts of the admin have switched to the new default language. ? That was it for a single language site in none english. If you want to have a multi language site, just add more languages to the SETUP > LANGUAGES section. When using a multi language site, I think you also want to use multi language input fields, and maybe different page names for your language page pendents. If so, you need to go into MODULES > CORE > filter LANGUAGE and install what you need or want to use of it, (if not already done). Thanks for reading and happy coding, ?

The symptoms all point towards ProcessWireUpgrade. It does have a login hook for checking available updates, after all. I'd first check outgoing HTTP(S) connections and, if those work and are performant, possible DNS lookup hickups on the server. The message about SchedulePages is normal, as it's not listed in the module repository.

@Robin S, you're fantastic! GD libary is working fine for me! Thanks a million for the quick update!

The error persist @FireWire Update 1: I created a new template that only renders the form (loaded with Markup Regions), and it is working. However, in another template with a repeater field that I render with <?= page()->render('banners') ?>, I see the error above. The repeater isn't related to the form, but there is something in the way I'm rendering the content inside my repeater that is breaking FBhtmx. I will try to find out why the error occurs and keep you updated. Update 2: I found the issue! Imagine a template with a Page Reference field, where the value is a PageArray allowing users to select multiple values. The field is rendered using <?= page()->render('myField') ?> and the field template is: // /site/templates/fields/myfield.php <?php namespace ProcessWire; foreach($value as $item){ echo $item->render(); } ?> When our page with the form and myField is rendered, the hook after Page::render will be executed for each value of myField as well as for the page itself. If $this->renderHtmxResponse($e->return) is executed with the pages of myField, a null value will be returned. My temporal fix: private function addPostFormProcessingHook(): void { $this->wire->addHookAfter( 'Page::render', fn ($e) => !empty($e->return) && ( $this->isHtmxRequest() && $e->return = $this->renderHtmxResponse($e->return) ) ); } private function renderHtmxResponse(string $renderedPageMarkup): string { $pattern = "/\n?<div id=[\"']{$this->htmxFormId()}[\"']((.|\n|\r|\t)*)(<!--\/.FormBuilder-->|<span data-formbuilder-htmx-end><\/span>)/U"; preg_match($pattern, $renderedPageMarkup, $matches); return $matches[0] ?? ''; }

I don't know for sure but it looks like a problem with your Imagick configuration or file permissions. The module won't be able to solve that but if you update to the newly released v0.2.2 there is an option in the module config where you can choose to use GD for the conversion instead.

If you want to serve the english content from / instead of /en then you need to go to the home page (id=1), edit it and go to settings: In this example it's default = german and I'm serving "de" from foo.com/... English has url "en", so it's served from foo.com/en/...

Hey @Techno "default" means the default language of your specific ProcessWire instance, not more, not less. It does not refer to your default spoken language, not your default browser language, not a global default PW language, nothing like that. It only means this is the default language of your own website. Which language that is is up to you, it can be anything. For me the default is often german, for you it could be PT, for others it could be FI, etc.. Have a look here:

It now also works on Mac with Firefox. Some other changes are also included. The new optimized and vanilla-js QuickSave version 0.1.7 is available as a new download in the first post.

Great, thanks for the feedback that it also works under Linux. Can you also save directly from an active TinyMCE-RTE field using a keyboard shortcut under Linux without the optional TinyMCE plugin? It doesn't work for me on the Mac without the optional TinyMCE plugin. I already mentioned a complete implementation better without jQuery at our meeting yesterday. Now, without knowing it, @dotnetic converted it to “Vanilla JS” almost at the same time. I think pure JS is great. (Whether the file size is really that relevant, if so, I can integrate a completely minimized file into the final module version.) The pure JS version doesn't work optimally for me yet - see post above. I had already started replacing jQuery with JS in an unpublished version. I also had a change for the scroll position, because from what I read, you should tell the newer browsers that you want to determine the position yourself, etc. I will compare and combine and then put a new version in the first post above . I would like to avoid that we end up with a jumble of versions of module downloads. I hope I'll find the time to do it soon, but at the moment both versions seem to be working quite well. Short feedback from you too, about the direct shortcut saving from the activated text in a TinyMCE or CKE field under Linux would be great. Really interesting that operating systems and browsers handle this differently. (If it really only doesn't work on Mac, I would also like to adapt the module description in the new version). Greetings to everyone and have a nice weekend.

Done

CraftCMS comes to mind. It's very powerful and customizable. The Solo version is free, but the rest of the versions are not.

I have already mentioned it a few times, but I can recommend Kirby CMS as alternative to ProcessWire. It is very similar to ProcessWire in the structure and API, but needs no database because it is file based. Also they have a nice website, documentation and marketing including detailed changelogs. It is not as feature rich as ProcessWire and not free, you have to pay a license for commercial use, but the marketing and presentation is better in my opinion.

Jep Firefox is looking automatic for a favicon file if it is not provided in <head> section.

Hi, This message is to be taken as informational and being transparency, NOT as a security alert. In short: The module code do not contain vulnerabilities, you are safe to use it. In depth: Years ago, I could spot some offsec users cloning/forking the project on Github. Theses last days, the project got more activities that can be seen on this graph and it look like the module is now included in some open-source offensive security tools. I took a few hours to find and go back to these tools and took the liberty of testing them myself on three online sites, based on Processwire with the module installed. I obtained no negative results, no red flags to deplore. What's more, the code is now monitored to automatically find and correct vulnerabilities in open source code and dependencies with security tools and DeepCode AI. If you ever find something or even if you are not sure about it, feel free to contact me by following the Security Policy. Have a nice day.