Leaderboard

This week we have ProcessWire 3.0.205 on the dev branch. Relative to 3.0.204, this includes 23 new commits including several refactored classes, issue resolutions, several pull requests and various new features. While there's no single major new feature to write a blog post around, there's still a lot here so for full details see the dev branch commit log. This week there's also a new module released in the ListerPro board called PageActionCrawl. This is a ListerPro PageAction module that crawls all pages sent to it. You can use this to crawl your entire site, some portion of pages within it, or even crawl external URLs referenced in URL fields. This is useful for any number of things such as priming caches, finding errors, quality assurance, doing security testing and more. Features include: Supports crawling with GET, POST or HEAD requests. Supports optional query strings and/or URL segments. Reports the HTTP response code and render time for each URL. Highlights error URLs (http code >= 400) in red. Optionally supports crawling of multiple URL variations per page. Supports inclusion of custom POST variables in POST requests. Supports page URLs or URLs stored in FieldtypeURL fields. Supports success and error hooks for custom behaviors on crawled URLs. Speaking of ListerPro actions, I've moved all of the 9 ListerPro action modules into their own new subforum of the ListerPro support board, so if you subscribe to ListerPro be sure to look for the new ListerPro Page Actions board in there. That's also where this new PageActionCrawl module is posted. Thanks for reading and have a great weekend!

If by "featured" you mean "linked to within a CKEditor field" then it's pretty easy. You just upload the file to the first page it will be used on (Page A), and on any of the other pages you use the CKE link dialog to select Page A and then select the file.

I'll try to spare you from the, "Why would you want to [...]" question, as there are any various reasons why someone would want/need to migrate one way or another. Because ProcessWire is a Content Management Framework that helps a developer create a Content Management System, it's so varied in how it could be created that it might not be a simple export and re-import. Custom tools might need to be built -- or you might be lucky if the site is simple enough, you could potentially take advantage of something like the Import/Export modules, but those are often purpose-built for singular purposes as well. With few exceptions, all content should be in the template files and in the database. With some properly crafted SQL queries, you could get the data that you need. You could then rearrange those SQL queries as an insert into WordPress -- or convert it into a format that WordPress has an importer for. If this is your website though, it looks fairly custom with page partials used to build out the full page. If you're not a developer, you might need the direct help of a developer.

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, ?

Hello all, I have released RockFrontendTailwind, an extension module for RockFrontend. It extends Bernhard's module and adds an installation profile for site development with Tailwind CSS. Obviously RockFrontend is a required dependency for my module to work. This module aims to give you a quick start with a Tailwind based project. What RockFrontendTailwind does: A folder "rockfrontendtailwind" will be installed in site/templates. That folder contains all the configuration files needed to get you started with a webpack-based build pipeline for JS and CSS with webpack tailwindcss postcss with postcss-preset-env (for autoprefixing) babel (for transpiling) So rather than just building the CSS with Tailwind, the build pipeline also takes care of transpiling your Javascript based on configuration in a .browserslist file. Of course, the setup is opinionated. But people who are comfortable working with webpack can easily adjust / extend the configuration to their liking. The default configuration watches your JS and CSS files and compiles them into site/templates/assets main.css and main.js by default. All paths are configurable through a .env file. Live reloading during development is not part of the webpack configuration since this is handled by RockFrontend already in a very efficient way. Also a _main.php file including a very basic boilerplate for a typical setup will be placed insite/templates. It includes examples on how to render your JS and CSS assets. More detailed instructions over at github. Adding new profiles to RockFrontend through your own modules is quite straight forward thanks to the clear structure in @bernhard's module. RockFrontendTailwind can serve as a boilerplate. The only important thing is that the "profiles" folder structure remains the same. The module is currently in beta but runs very stable. It will eventually be released as an official module in the directory soon. If you want to give it a shot, I shall be happy to hear your feedback. If you are looking for a standalone webpack build pipeline with webpack-dev-server, you might want to have a look at https://github.com/gebeer/tailwind-css-webpack-processwire-starter Happy Coding!

That's of course true, but it would still be interesting to hear. For example if the reason is that the ProcessWire page is slow and a WordPress site would be faster, than that would be a wrong assumption and making the ProcessWire site faster would be maybe two hours of work while migrating the site to WordPress would easily be multitude of that... 23.4MB for the homepage is really not a good value and just by optimising your slider images (which should be as easy as using $img->maxSize(...)->url instead of just outputting the image in its original resolution via $img->url what your site is doing) you are able to speed up the site significantly. Then purchase and install ProCache and your site is insanely fast. That might be all you need. Because I think the design is nice and it also looks nice on mobile. So why throw that in the bin? If there are other reasons then these optimisations might be irrelevant of course. So it would be nice to hear your reasons ?

Check out the blog post that introduced InputfieldTextTags: https://processwire.com/blog/posts/pw-3.0.177/#using-with-options-fields If you use a Page Reference field for your tags then you can add new tags via the inputfield if the field settings are configured to allow it. From the blog post:

Ryan has already stated lots of times that he is not interested in growing the user group just for the sake of growing it. In other words, it is very low priority for him, as far as I understand it. He is also not interested in page builders as such, but happy to add features to Repeater Matrix that support such use cases whenever he has the time to work on it. I guess that will be the closest to "page building" from Ryan. "Theming" will certainly never be possible with ProcessWire as a core feature as that would be agains its philosophy, wouldn't it? A solo or a team of developers can surely come up with their own theming schema and implement it for themselves but that is a different story, I think.

This last week my wife and daughter took a trip to NYC and it was my daughter's first time there. I was browsing around online looking at things they could do and so I visited the Guggenheim museum website to look into that option... I've always been a fan of the building, a Frank Lloyd Wright masterpiece. In addition to New York, I learned from the website that Guggenheim also has museums in Abu Dhabi, Bilbao and Venice, so I clicked through to view them as well. I really liked the Venice Guggenheim website, which had a much nicer website than the other locations. It was such a nice site that I was curious what they were running, so I viewed the source and... not WordPress (like the others), but ProcessWire. What a nice surprise. Then I was curious about who made such a nice site and there was a credits link in the bottom right corner that says the site was made by basili.co, nice work! It's always fun to come across a ProcessWire powered website randomly like that, and I thought you all would enjoy this one too. This week there are fairly minor updates on the core dev branch. Though the updates include one I've been meaning to do for a long time: improve the API for processing Inputfield forms. Previously there's been no way to check if a form is submitted, short of checking an $input variable yourself. Today I committed an update that adds a $form->isSubmitted() method that solves that, and more. It can identify which form was submitted, which submit button was used, and it also performs additional checks to make sure it's a valid submission before deciding that it's a form worth processing. It improves reliability, accuracy and security. Next week I'll be updating several of the admin forms to use it, among other updates. A few other useful helper methods were added to the Inputfield forms API as well. I realize that these updates may only be of interest to module authors, but I like keep you up-to-date with the week's updates either way. Thanks for reading and have a great weekend!

Version 2.0.2 Fix Issue #2 Fix taglist for "Grouped add buttons" Add PW and PHP version requirements Add german translations ... and with hardcoded version number #3

Thx for sharing @zoeck It's always a little disturbing to read comments on such posts... So many wrong assumptions and judgements... It's such a shame... ProcessWire is such a brilliant and powerful tool. I've been working with PW extensively for several years now and still sometimes get the feeling that I'm just scratching the surface... And with all that power and complexity (beauty) behind the scenes ProcessWire still looks like something that even an intern can read and understand at first sight. How genius is that? And how wrong is this guy with his judgement?! But I can't blame him. I was in the same situation 8 years ago... I think that is a quite common reaction. And I wonder if we could do something about that. Or if we should? I don't know ?

Look at this example. Its made with the old version of RestAPI first made by @thomasaull years ago. To get the context, you can navigate to https://kingspark.fr and https://valideur.mykingspark.fr . I am speaking about a system which give the possibility to some of our client use their mobile or a barcode scanner device to give "free of charge parking" of their customer. Its composed with custom hardware, software and devices or mobile apps (you see it on GooglePlay). Image #1: List of Parkings // Image #2: The custom made SAGAS Terminal // Image 3: A configured User / Device available for registration and use. On the first picture, you can see a list of "Parkings", and some can have the "Valideur" functionality. We can configure attached devices and some users with specific role to get access for registration. And then, imagine the following. A customer land on the parking, grab a ticket and go to their rendezvous At the end, the guy in the office use his "Barcode Scanner" to "validate" the ticket of the customer; This mean that the customer will not pay anything when landing on the terminal to exit the parking, and when he will present the ticket on the barcode-reader installed on the terminal (the "black hole" you can see on the center in the picture), it will be recognized by another software and thought a call on ProcessWire Rest API backend. I made you two screencasts, the first is the software which once installed and registered, get the quota (number of validation available) from the user assigned to the license-code, and the second is my mobile which get notification sent from ProcessWire (by this module) from a monitoring system to get real-time information on registration. If you have any question, do not hesitate. There a more example, but you should get the whole idea ?