Leaderboard

ProcessWire 3.0.198 contains a mixture of new features and issue resolutions. Below are details on a few of the new features: Support was added for runtime page cache groups. This enables pages to be cached as a group—and just as importantly—uncached as a group. While it can be used by anybody, it was added primarily to add efficiency to $pages->findMany(), so that it can cache supporting pages (like parents and page references). Previously, it would have to load a fresh copy of each supporting page used by findMany() results (for every returned page) since findMany() used no in-memory caching. If it did cache in memory, then you could potentially run out of memory on large result sets, so that strategy was avoided. Consider the case of iterating over all pages returned by findMany() and outputting their URLs... that triggers load of all parent pages for each page in the result set. And without a memory cache, it meant it would have to do it for each page in the results. Following this week's updates, now it can cache these supporting pages for each chunk of 250 pages, offering potentially significant performance improvement in many cases, without creating excess memory usage or memory leaks. When the chunk of 250 result pages is released from memory (to make room for the next chunk), all the supporting pages (parents, page references, etc.) are also released from memory, but not before. Now findMany() can offer both memory efficiency and great performance. For as long as I can remember, ProcessWire has had an apparently undocumented feature for dependent select fields that enables you to have two page reference fields using selects (single, multiple or AsmSelect) where the selected value in one select changes the selectable options in the other select (Ajax powered). Think of "categories" and "subcategories" selects, for example, where your selection for "categories" changes what options are selectable in "subcategories". Part of the reason it's undocumented is that it is one of those features that is a little bit fragile, and didn't work in some instances, such as within Repeater items. That changed this week, as the feature has been updated so that it can also work in Repeater items too. The $pages->findRaw() method was updated with a new "nulls" option (per Adrian's request in #1553). If you enable this new "nulls" option, it will add placeholders in the return value with null values for any fields you requested that were not present on each matching page. This reflects how PW's database works, in that if a field has no value, PW removes it from the database entirely. Without the nulls option (the existing behavior), it retains the more compact return values, which omit non present values completely. For example, consider the following: $items = $pages->findRaw("template=user, fields=email|first_name|last_name"); If a row in the result set had no "first_name" or "last_name" populated, then it would not appear in the that row of the return value at all... [ "email": "ryan@processwire.com" ] By specifying the "nulls" option, it will still include placeholders for field values not present in the database, and these will have a value of null: $items = $pages->findRaw("template=user, nulls=1, fields=email|first_name|last_name"); [ "email": "ryan@processwire.com", "first_name": null, "last_name": null ] By the way, if you don't specify which fields you want to get (which is the same as saying "get all") then adding the nulls option makes it provide placeholders for all fields used by the page's template. As you might expect, without the nulls option, it includes only populated fields. Also included in 3.0.198 are 7 issue fixes, most of which are visible in the dev branch commits log. That's all for this week. Thanks for reading this update and have a great weekend!

Super OT: When I started using ProcessWire I only knew the templating syntax of Textpattern and was fine with it as it handled everything I ever needed. (I loved it! Really.) All I was able to do in PHP was a Hello World!. Within a day or two I moved my personal site from TXP to PW, launched a side project within the first week, did a rebuild of other side projects in the first few weeks and a real-life-project shortly after that run for about 5 years. Best learning experience ever! So yes... you can even learn the basics of PHP while using ProcessWire and go from there. Maybe PHP-Dev-Starters should use ProcessWire as a starting point - yes, that's my real and honest opinion. The tutorials and (later on) the docs can do that!

Oh my... that Heise comment-thread developed to a gold mine. Thanks to all of you that posted there. That was such a nice read! Looking around I think I found about 2 of the 3 commentators. Great job!

Padloper 2 has been released I will write a better post later. Need to know for now: Get it from here. We will be transitioning to a new website and/or shop in due course. For now, please get it from that old site. For now, and to allow it to bow out gracefully, initial purchases will be powered by Padloper 1. All hail Padloper 1 :-). Due to #2, and #3 and due to non-SCA compliance on that particular site, there might be Stripe issues. Apologies. Please contact me for help. Support for Padloper 1 has ceased. Security fixes will continue. Things I have promised to look at will be looked at :-). Support subscription period for beta testers' purchases commences today - 30 March 2022. It is a special day...in more than one way... Update 3 April 2022 Frequently Asked Questions A few questions are coming up with respect to this release. For now, I'll answer them here but might start a new threaded dedicated to FAQs. Q: Will beta testers have to purchase a new licence for this release? A: No. Your licence and download link are still valid. The only difference is the countdown of your VIP support commences on 30 March 2022. Subscriptions and updates are valid for one year. This download link was emailed to you when you purchased Padloper 2. Please contact me if you do not have a download link. Q: I have shops built in Padloper 1 that I'd like to migrate to Padloper 2. I don't have the expertise and/or time to do the migration myself. Is there paid support for this? A: Yes, paid support is available. We can migrate your Padloper 1 shop to Padloper 2 per your specifications. This includes both backend and frontend migration. You can purchase either or both backend and frontend migration. Please contact me to discuss. We will soon add this custom work information to our website. Q: Is there a backend/admin demo of Padloper 2 that I can test pre-purchase? A: Yes. We are currently putting final touches to it. An announcement will be made here once this is ready. Q: Which is now the official Padloper support forum? A: This forum will eventually become the official Padloper support forum Although it is a public forum, we will still be able to offer VIP support. The only difference is downloads will be not be available in the forums, since it is open. Support via email will still be available as well. Q: I am getting a called to undefined function bcmul() after install. What does this mean? A: Please see the minimum requirements for Padloper 2. You will need to install the PHP extension bcmath on your server. This is in order to get accurate rounding off of currencies.

@rick messaged me asking for advice about how to use dependent selects in a module config. That is, where the options of one select change depending on what is selected in a another select. I thought others might also find this info useful so I've put together a demonstration module: https://github.com/Toutouwai/DemoDependentSelects The general idea is that the dependent (target) select needs to include all the possible options, and then the options are hidden or shown by JavaScript depending on what is selected in the source select. See the source code for comments.

Just have a Look at this ?

What the hell are "outdoors" and "offline time"? I've never heard of this.

Sorry for the delay... I was outside (as in outdoors, enjoying the offline time) and took a while off from the desk. There is so much great feedback and yes... maybe I was wrong about the 7G firewall solution. Still can't find what I was thinking about. Nonetheless... the task was postponed a bit so I can dig a little deeper in all your comments and maybe give this a try. Thanks you so much @horst and @FireWire!

The problem: how to refresh a page's frontend content in real time without a page refresh when the page has been edited in the backend. This is an alternative approach to the one discussed in the topic below. The above topic attempts to solve the problem using SSE. The solution in this topic instead relies on Local Storage and htmx. There is no ajax polling. Please note that auto-refresh here refers to a page refresh during the same session and in the same domain. It is not cross-site. The solution can be summarised as follows: Use a hook in ready.php to inject custom JavaScript to the ProcessWire backend admin, specifically in ProcessPageEdit. This can be a JavaScript file or inline script. The purpose of this file is to update a given Local Storage key after a page has been edited. Instead of listening to the Save Button click, the script just checks on load if a certain hidden input whose value matches the page currently being edited is present. This hidden input is placed inside ProcessPageEdit form using a hook as detailed below. The hook in this step #1 can be: $this->addHookAfter('AdminTheme::getExtraMarkup', null, 'hookAddCustomScriptsToAdmin'); In ready.php, add a hook to listen to saveReady(), e.g. $this->addHookAfter('Pages::saveReady', null, 'hookNotifyFrontendOfBackendPageSave');. When the page is saved, the handler method hookNotifyFrontendOfBackendPageSave will check if there are changed fields. It will then write to a temporary session variable for the current page with the names of the fields that have changed. On page load/reload, there is a hook in ready.php that monitors ProcessPageEdit, i.e. $this->addHookAfter('ProcessPageEdit::execute', null, 'hookAddMarkupToNotifyFrontendOfBackendPageSave'); The handler hookAddMarkupToNotifyFrontendOfBackendPageSave will check if there is a session variable set in #2 indicating that the page has had recent changes in the fields names set to that session variable. If this is true (that there have been changes), this hook will simply append the hidden input in #1 to the ProcessPageEdit form. The JavaScript in #1 will detect the presence of the hidden input. It will then amend the Local Storage value in #1. It cannot simply set the value to the ID of the page being edited as that will not be construed as a change. It will instead append a timestamp to the id of the page as well and set that as the value. This will enable a listener in the frontend, described in the following steps, to detect that change. In the frontend, we have a simple JavaScript file that listens to changes to the Local Storage storage Event. The frontend also has a simple hidden input in the template file whose pages we want to refresh. This hidden input has htmx attributes. Its trigger is a custom event 'autorefreshpage'. It will listen for this event before firing a message to the server. This hidden input also has hx-swap=none as nothing will be swapped to it. Instead, the server will send back results of changed fields in various markup with hx-swap-oob=true. That will enable swapping markup in any parts of the frontend html in one go. When the Script at #4 detects that a given Local Storage value has changed, it first checks if the page ID for that Local Storage value matches the page ID of the page currently being viewed in the frontend. If the answer is yes, it will fire the custom event autorefreshpage. This will make htmx fire a message to the server whose only value is the page ID it has been passed. On the server, in home.php, we have code that is listening to ajax requests. If it detects an ajax request, it checks if the page ID that htmx sent matches an available session that was recently updated. This would be the temporary session detailed in #2 above. If a match is found, it calls a function in _func.php that will set variables for fields for that page. These use partial templates (optional). These partial templates are for different outputs of the page, e.g. images, headline, etc and all their markup have hx-swap-oob='true' in appropriate places. All these content is sent back as one output back to htmx. It will read the hx-swap-oob and find the markup to replace in the DOM using the html IDs of the markup with the hx-swap-oob. This approach allows the developer to have maximum control over what to send back to htmx and over the markup. In this step, we also delete the temporary session, ready for the next updates. The result is as demonstrated below. A simple and effective DOM swap that places very little strain on the server. I'll clean up the code for this and upload to GitHub. This approach will not work with Save + Exit and similar :-).

Actually it's a lot easier! // /path/to/pw/root/standalone.php <?php namespace ProcessWire; require "wire/core/ProcessWire.php"; $data = new WireData(); $data->foo = 'foo'; $data->bar = 'bar'; echo print_r($data->getArray()); // execute the script cd /path/to/pw/root php standalone.php How great is that? ?

Will submit to it on weekend.

Hi guys! ( @howdytom @olafgleba ) Please are you able to post your setups / configs to this github-issue? I think this would be of great help for Ryan. Please put in your image sizer config settings, the lines of code how you use and where you use it. (template-file, repeater, etc) Also please only issues with the core image field. I had posted example code there, to help reproduce the issue in an automated way, but I think that Ryan now think that the issue only is with my special code. !! Many thanks!

Back with more! Prepare for incoming wall of text... I mentioned adding custom directives to our .htaccess file and wanted to share some more detail on that as well as some other tips. I was reviewing our 404s as a matter of maintenance so to speak to ensure that we had redirects in place as necessary. While reviewing that I found a lot (a lot) of hits that were bogus, clearly bots and even web crawlers for engines we have no interest in being listed for. What I found was in just 48 hours we had 700 total 404s and I imagine on some websites that number could be higher. By analyzing that log and writing custom directives I was able to take 700 404s logged by ProcessWire down to 200 which are "legitimate" in that it's traffic that to be redirected to a proper destination page. I'm sharing my additional directives here as an example. Again, ANY bot/security directives should be at the very top of your .htaccess file. As always, test test test, and modify for your use case. # Declare this at the top of your .htaccess file and remove or comment out all other instances of this directive elsewhere RewriteEngine On # Block known bad URLs # Directories including sub-directories RedirectMatch 404 "\/(wp-includes|wp-admin|wp-content|wordpress|wp|xxxss|cms|ALFA_DATA|functionRouter|rss|feed|feeds|TKVNP|QXXLZ|data\/admin)" # Top level directories only - There are no assets served from these directories in root, only from /site/assets & /site/templates RedirectMatch 404 "^/(js|scripts|css|styles|img|images|e|video|media|shwtv|assets|files|123|tvshowbiz)\/" # Explicit file matching RedirectMatch 404 "(1index|s_e|s_ne|media-admin|xmlrpc|trafficbot|FileZilla|app-ads|beence|defau1t|legion|system_log|olux|doc)\.(php|xml|life|txt)$" # Additional filetypes & extensions RedirectMatch 404 "(\.bak|inc\.)" # Additional User Agent blocking not present in 7G Firewall <IfModule mod_rewrite.c> # Chinese crawlers that cause significant traffic to bad URLs RewriteCond %{HTTP_USER_AGENT} Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza|Datanyze|serpstatbot|spaziodati|OPPO\sA33|AspiegelBot|aspiegel|PetalBot [NC] RewriteRule .* - [F,L] </IfModule> Details on this additional config: It blocks some WP requests that get past 7G My added directives redirect to a 404 which tells the bot that it flat out doesn't exist rather than 403 forbidden which could indicate it may exist. I read somewhere that this is more likely to get cached as a URL not to be revisited (wish I could remember the source, it's not a major issue). Blocks a lot of very specific URLs/files we were seeing Blocks Chinese search engine bots, because we don't operate in China. These amounted to a lot of traffic. Blocks common dev files like .bak and .inc.* which aren't protected by default. Obvs you want to eliminate .bak altogether in production, but added safety fallback. I have not seen this cause any issues in the Admin. Also consider if directives could cause problems in another language. Customize by reviewing your logs Additional measures 7G and the directives I created are a healthy amount of prevention of malicious traffic. Another resource I use is a Bad Bot gist that blocks numerous crawlers that add traffic to your site but may or may not generate 400s-500s HTTP statuses. This expands on 7G's basic list. Bad Bot recommendations: Comment out: SetEnvIfNoCase User-Agent "^AdsBot-Google.*" bad_bot There's not really a good reason to block a specific Google bot If you make Curl requests to your server then comment this line out: SetEnvIfNoCase User-Agent "^Curl.*" bad_bot Reason: this will block all Curl requests to your server, including those by your own code. Be sure that you don't need Curl available if leaving this active. This is included in the list to prevent some types of website scrapers. If you want to leave this active and still need to use Curl, then consider changing your User Agent. Comment out: SetEnvIfNoCase User-Agent "^Mediapartners-Google.*" bad_bot Again, not necessary to block Google's bots, might even be a bad idea for SEO or exposure (only they know, right?). Testing There's no such thing as too much testing. These directives are powerful and while written well, may have edge cases (like 'null' mentioned previously). There's no replacement for manual testing, specifically it would be a good idea to test any marketing UTMs or URLs with GET strings you may have out there just in case. For automated testing I use broken-link-checker which can be called from the terminal or as a JS module. I prefer this method to using some random site scanning service. This will detect both 404s and 403s by scanning every link on your page and getting a response which is useful for ensuring that your existing URLs have not been affected by your .htaccess directives. broken-link-checker recommendations: Consider rate limiting your requests using the --requests flag to set the number of concurrent requests. If you don't you could run into rate limits that your managed hosting company, CDN, or you (if you're like me) have built into your own server. This terminal app runs fast so if you have a lot of links or pages those requests can stack up quickly. Consider using the -e flag, at least initially while testing your directives. This excludes external URLs which will help your test complete faster and prevent any false positives if you have broken external links (which you can handle separately). Consider using the -g flag which switches the request to GET which is what browsers do. Shortcut, just copy and paste my command: blc https://www.yoursite.com -roegv --requests 5 If you have access to your Apache access log via a bash/terminal instance then you may consider watching that file for new 404/403 entries for a little bit. You can do this by navigating to the directory with your access log and executing the following command (switch out the name of your log as needed): tail apache.access.log -f | grep "404 " You may consider also checking for 403s by changing out the HTTP status in that command. "This seems excessive" I think this is good for every site and once you get it dialed in to your needs can be replicated to others. There's no downside to increasing the security and performance of your hosting server. Consider that any undesirable traffic you block frees up resources for good traffic, and of course reduces your attack surface. If you need to think about scalability then this becomes even more important. The company I work for is looking to expand into 2 additional regions and I'd prefer my server was ready for it! If you get into high traffic circumstances then blocking this traffic may prevent you from needing to "throw money at the problem" by upgrading server specs if your server is running slower. Outside of that, it's just cool knowing that you have a deeper understanding of how this works and knowing you've expanded your developer expertise further. This isn't meant to be an exhaustive guide but I hope I've helped some people get some extra knowledge and save everyone a few hours on Google looking this up. If I've missed anything or presented inaccurate/incomplete information please let me know and I will update this comment to make it better.

I was thinking about this argument and this is something I also wish that could be improved. There doesn't seem to be a roadmap anymore. The current roadmap is from 2019: https://processwire.com/about/roadmap/ I think it would be nice to revive the roadmap or at least make a poll for what the community is wishing for the most. The last poll was at the beginning of 2021. The current approach that a feature will be added if @ryan has the need for it on a project is not bad, but that leads to many developer centric and less client centric features, which I personally often don't use, because there are already so many developer centric features. ?

Interesting discussion, and I'll add a rather ironic perspective. I inherited a largely non-functional website project that someone else had built in Craft, about 3 years ago, and at the time I found the Craft documentation wasn't particularly clear, whereas I worked out how to use ProcessWire after about 20 minutes of reading the documentation. I converted the whole project to ProcessWire, and actually got the project functional. I had to write several custom modules and deal with a lot of hooks and set up CRON jobs to interact with a third party API, and I found ProcessWire a pleasure to work with. That said, I can understand that there are pain points for some people with ProcessWire, and it's always good to look at other systems to see how they do things in case there's something useful that could be incorporated into ProcessWire. My personal preference other than ProcessWire is Umbraco, which is built on ASP.Net rather than PHP, but in many respects is similar, so I don't have a problem jumping between PHP for ProcessWire and Razor syntax and C# for Umbraco. It also is an open source project, but with commercial add-ons like a form builder (which makes ProcessWire FormBuilder look cheap). Now that .Net and SQL Server run on Linux, it's potentially even more appealing to me, although ProcessWire is still my first choice. Currently I'm a solo developer, but as my workload grows, and also clients are starting to ask for an insurance policy in case something happens to me, the potential to be able to manage collaboration on projects is something that's increasingly on my mind, and out of the box, this isn't something that ProcessWire handles, although there are third party solutions like RockMigrations by@bernhard

I had to comment there as well, because I couldn't leave this unfair comment alone. But in my experience this is normal for the heise community and a reason why I don't like to read articles there. ?

I agree it is unfair to make comparisons like this. I also don't think it's very nice to come to an open source project's support board and try to convince people to use a commercial CMS. Maybe the fact that a comparison can be made at all is a compliment. But Craft is a big commercial project with a sizable team and lots of resources and money behind it. ProcessWire is the opposite of that and the comparison seems inappropriate. But since you've stated this is a comparison, I'm not sure where the comparison is — you've focused exclusively on what you think Craft does better (by your own preference), but haven't made efforts to point out the areas where PW does better. So it comes across a little bit as an advertorial for large commercial CMS at the expense of a small open source project. Throughout you are stating a preference for something in Craft and claim a similar feature in ProcessWire is "not well thought out." This is wrong. A more honest statement would be that you and I clearly have different preferences, or maybe you don't fully understand something. But that does not mean that something that differs from your preferences or understanding is "not well thought out." I would never commit something to the core that hasn't been really well thought out, that's something I take really seriously. While much of Craft doesn't suit my own (and others) preferences, and may not be "well thought out" according to how I think things should work, I'm not going to join their forum and tell them it's not well thought out. That's because I respect them and trust that it's well thought out, according to their needs and preferences. So when you start telling someone that something they've put a lot of work into isn't well thought out, that's akin to saying that you do not respect them. I make no claims about being perfect at anything, and there is room for improvement in everything. What I take issue with here are the broad, subjective and largely false generalizations, and that's what I'm replying to. I'm also concerned that anywhere that you've quoted me, you've taken a statement by me out of context, extrapolating it as proof for an unrelated conclusion you've made. For example: In that link we are not talking about ProcessWire at all, and instead are talking about the processwire.com website in development, NOT the CMS. Why would you say I'm "opposed to the idea" of accessible development? This is something I'm interested in and passionate about. I don't understand why you are quoting me on one thing and saying another. In that link, I'm writing about a module called ProcessUser and something that is imposed upon it for a specific security purpose, unique to that particular module, and no other. But you have used my statement as proof that building custom features in ProcessWire isn't encouraged or supported. Nothing could be further from the truth. I have never had such a thought. My thoughts and intentions would be exactly the opposite. What you consider an advantage, I consider a major disadvantage. PW puts nothing between you and PHP, by design, that's a major advantage. I certainly would not be happy with Twig integration being a default. Clearly you like using Twig, which is fine for you to have that opinion, and I think it's perfectly fine for Twig to be an option. But I definitely wouldn't want to standardize upon it. Maybe it doesn't suit your preference, but I hope you can appreciate why we don't do things like that in PW. You are comparing two different kinds of caches. You are talking about a template engine cache. In PW there is no template engine, so likewise no template engine cache. Most of the time you would never need such a cache in PW at all. The $cache variable is something different, and while it can also cache markup, it is much more simple than you imply. PW's API is not string-based. You are writing about selectors (and specifically selector strings), not the "API". ProcessWire lets you specify selectors as strings or as arrays. Most prefer to use strings due to the simplicity of it. But this does not mean that arrays are not reliable. And if you use arrays, then there's no need to do value sanitization. But the majority of the time you are using selectors, you are not injecting user input into it either, so I would consider selector strings to be a major advantage for PW the vast majority of the time. And for times that it's not, you don't have to use it. The problem with chaining methods for this is that they are live code, you can't store them. Perhaps it has benefits in Craft, but they would not be appropriate for PW. In PW selectors can be specified as arrays or strings, and in cases where you want to separate the query property from the query value, then that's why we have the array option in PW. And yes, they are reliable, despite your claim that they are not. The same is true in PW. Fieldtypes build the query and sanitize/validate the value to be queried. The only thing PW asks you to do is IF you are using a selector "string" that ALSO happens to contain user input, then just sanitize that user input part with the selectorValue() method. If you are using an array, then such sanitization is already done for you. This has nothing to do with details of a fieldtype, which will do its own validation/sanitization. Saying "clunky" is a subjective and hardly fair statement to make. What might be clunky to you is optimal to others. You are writing specifically about the file translation system, so the whole purpose is to provide an interface to translate your site php files (primarily template files). The interface is geared to focus on that task only, and that's the point of it. I understand you value more layers between things (like with Twig), but I always prefer fewer layers, a more direct approach, so you'll see that throughout PW. If I'm using a file translation system, I want to know what file I'm working with and I want to be able to tell the translator what file to work with. That my preference, and I understand you have a different one. Of course you can, that's who it is for. Yes they are grouped by file, and that's how I prefer it, and I have never had a client have a problem with that. If you have some preference to keep translators/clients out of the admin, you can also ask them to translate from a spreadsheet (exported from PW) and PW will happily read that in and use it. None of those 3 statements is true. Translations may be stored in JSON files, but they can be exported/imported (all files at once) to/from CSV files. Translation files are not stored in "random" locations. They are stored with the language's files, which is a static location identified by its ID. Adding translations in the code editor is not impossible, because where else would you add new translations, if not in the code? If you need a new translation, go ahead and add your __('text') in your code, and it immediately becomes available as a translation. You are welcome to your opinion, but as someone that put a lot of thought and effort into field translations, it's hard for me to take your opinions seriously when you state things like this. Nothing about them is "tacked on" or "not well thought out", quite the opposite. So to me it seems like at worst, you don't understand what you are talking about, or at best (and most likely), you just have an alternate preference. This is fine, but I don't think that's obvious to everyone reading. So please don't make statements like "not well thought out" when you really mean that something doesn't suit your preference, or maybe you don't fully understand it. I appreciate examples but I'm not aware of any field where you need to "add the second language's field manually". This does not sound at all like PW multi-language fields. If you are talking about PW at all, perhaps you are talking about the "language alternate" fields option? If so, this is an option that is there to provide additional flexibility for specific cases, but it is almost never used in my experience. Please don't use it as a foundation for any comparison, as its borderline deprecated at this point and I don't expect many will ever use it. This conclusion is the opposite of the truth. The fact that PW doesn't impose a specific framework upon you means that all options are open. Anything is available to you. It is more open, not less open. It's you and PHP, and anything you can run in PHP you can run in PW. ProcessWire feature approach is built around constant improvement. It is driven by the community and the needs of clients. The development of PW has always followed this approach. I have a job working with clients just like most PW users and so I develop according to what's needed and when. Most of my income comes from client work. I work on the PW core for free, so development usually has to have some crossover with the other projects that I work on. Despite being open source and largely unfunded, the fact that PW and Craft can end up with apparently similar capabilities and feature sets—and the fact that they can be compared at all—I would consider to be a sign of efficiency and that we are doing something right. If you consider our approach "chaotic" then fine, but the accurate terms would be "flexible", "sustainable", "consistent" and "continuous". The approach been very successful for PW as a project. And PW is also one of the longest lasting projects in this area (open source or commercial), and will continue to be because it's not built around money. I don't add features without completely thinking them out. That's silly, why would we do that? I would never commit something to the core that has not been well thought out. I don't understand why you would say this unless you just don't understand it. Nothing committed in the core has been abandoned. Elsewhere, I've abandoned a ton of code, but most of it has never been seen by anyone. When I commit something to the core, I've spent a lot of time working on it and I'm also committing to supporting it, long term, for as long as there is value in it. That's another reason why I take a lot of time to think through anything that gets added. You are welcome to say that you have a different preference, and you can I clearly have different preferences, but please do not suggest something is not well thought out because that is not true. Well, I'm glad you think there are "hundreds" of features that look cool... though not well supported? I don't know what we're talking about. False. The only bugs that don't get fixed are those where they cannot be duplicated, or that don't have a clear solution and seem to be isolated to one person. And I don't know what you mean about "don't work well with each other and so on". ProcessWire's core focus is already a limited feature set, where much is left to modules. The aim is to have everything you might "need" and do it really well, but save things you might "want" for modules. This is one area where it certainly does help to have a big commercial company behind it, with full time documentation writers and such. While they do have a structure and hierarchy, I understand it may not be exactly the way everyone might want it. The site search engine is actually quite powerful and searches the API and all documentation pages, so I recommend that when you want to find something specific. This is fair, and it'll continue to be that way, the blog posts can do heavy lifting in between the time that features are added and documentation is updated (as does this forum). The blog posts do also end up as the linked documentation for features in some cases. I'm okay with it. I understand that if we were a big company it might be odd though. I don't put efforts towards pretending that PW is a big company, I work within the resources we have, putting most of it towards where it counts and less of it towards pleasing critics. The aim is that all versions are compatible, meaning you can safely upgrade from any older version to any newer version. I don't know of any other projects that do this as well as PW, so I would consider it a major benefit. If we get to the point where this is regularly not the case, then we likely would adopt semantic versioning. But the need isn't there at this point in time. Close, but not totally accurate. New versions are currently aimed at a group of new related features or a group of issue fixes. The version number goes into systems that prompt people to upgrade, at the time it is appropriate to do so. They are also for documentation purposes so that we can easily reference them in "since" statements. Lastly, it's useful to have version numbers to reference in blog and/or forum posts. Currently this system of version numbers is the most beneficial one for this project. This isn't what I'd consider a breaking change. This is something where it just asks you to install a module as part of an upgrade to the version, it doesn't break the API or the site, just locks down a specific admin feature for security until you install the appropriate module. And security always comes first in PW. But I don't think there are any actual breaking changes in PW. Again, if it became commonplace like it is in other projects, then we'd likely adopt the same version number approach they do. So perhaps that's something that will come in the future, but we're not at that point. I'm open to it at the appropriate time. A "template file" is a "file" for a "template". I don't know how to be any more clear than that. But yes there are instances where we're talking about template files that I might use the term "template" rather than "template file" since the context is established. I agree that terms like "template" and "file" are fairly generic, and it would be nice if templates were like cars where we could refer to the "car" but also have a label like "wheels" and know we are still referring to the bigger "car" above it. But "file" is a generic enough term that while accurate, needs context. I'll take it as a compliment that you consider RepeaterMatrix to be so valuable. The Pro modules were never intended to be "required" for any site. They are meant to be a luxury or a time saver, but there's nothing you can do with any Pro module that you can't do yourself by some other means. Though Pro modules might save you time in doing it. I've built example modules that show you how to do do just about anything that Pro modules can do, they just might require more of your effort. The original intention for Fieldtypes and Inputfields was that everyone would build their own according to their needs, but I don't know many that do that other than me. Have a look at FieldtypeEvents sometime to see how simple it is to do. I don't share your opinion on this. If you are of the mindset that the page tree reflects the front-end site 1-to-1 then you are in the mindset of a different system. I consider the tree to be essential, a major benefit, as you know everything has a place and hierarchy and you don't have to have various different kinds of navigations or buckets to find them. If you know one thing you know everything in PW. I've never been a fan of different bucket systems and the ambiguity that they introduce. ProcessWire was designed from the beginning to get away from what you are talking about, what I subjectively feel is a mess in other systems (again, my preference). PW aims to be simpler and more flexible than that, though pages can still be browsed as a tree or as buckets, even if the tree is the source. I don't agree with your premise, or the linked post. Having a link to someone else's opinion does not make it right, maybe just right for you personally, that's fine. I would agree that there are benefits to letting the page tree influence your navigation, but there aren't drawbacks to not using it that way either. It may have started that way. While I am currently the gatekeeper in terms of maintaining the core I consider ProcessWire to be a long term community developed project, and it becomes more that every year. Every open source project needs someone to start it, and someone to be a caretaker, ensuring the quality of it, and I see that as my role, which I take very seriously. But this is a team project and one that is much more sustainable long term than a commercial one.

ProcessWire 3.0.197 resolves 9 issue reports and adds 3 feature requests. For details in resolved issues and feature requests, be sure to see the commit log. I'll cover a couple of my favorite feature requests that have been added this week: New $files->getCSV() method This comes by way of feature request #400 via @bernhard to add something to abstract away the redundant details of reading a CSV file into one simple method call. This simplifies the reading of a CSV file by abstracting file-open, get-header, get-rows and file-close operations into a single method call, where all those operations are handled internally. All you have to do is keep calling the $files->getCSV($filename) method until it returns false. This method will also skip over blank rows by default, unlike PHP’s fgetcsv() which will return a 1-column row with null value. Here's how you use it: Let's say we have this CSV file (first row is the header): Food,Type,Color Apple,Fruit,Red Banana,Fruit,Yellow Spinach,Vegetable,Green Here's how you'd use the new method: while($row = $files->getCSV('/path/to/foods.csv')) { echo "Food: $row[Food] "; echo "Type: $row[Type] "; echo "Color: $row[Color] "; } There are also several $options supported, see the $files->getCSV() documentation page for more. There's also a new $files->getAllCSV() method that does the same thing but returns all the rows in the CSV file in one call. Improvement to InputfieldPageListSelectMultiple Next was feature request #339 that requested adding the enhancement developed by @Robin S (via the PageListSelectMultipleQuickly module) into the core. This enhancement keeps the selectable page list open for multiple selections rather than closing it for each selection. It also better indicates when an item is selected. While I ended up writing it in a different way than Robin S.'s module, the end result is nearly identical to Robin S.'s short GIF screencast below: Also added this week is a new "visibility" option for Inputfields: Open + Locked (not editable), along with some small hook documentation improvements in the Pages class. Thanks for reading and have a great weekend!

Generally that's correct, htmx.onLoad() replaces the standard jQuery initalizer. Only real trick is that you initialize stuff in the content passed in to the onLoad() callback, rather than initializing the whole document like you do normally in jquery: Note that the query selector is run against the newly inserted `content` element, rather than globally, so you can initialize the library just for the new content that has been added to the DOM (and avoid accidental double-initialization of things.) Alternatives are: using alpine to init the element on load using hyperscript to init the element on load The first one is sane, but not how I would do it unless I already had alpine in my code base and I was comfortable with it. The second one is insane and not recommended, but I do love hyperscript.

Some introduction... This module is experimental and there are probably bugs - so treat it as alpha and don't use it on production websites. I started on this module because there have been quite a few requests for "fake" or "invisible" parent functionality and I was curious about what is possible given that the idea sort of goes against the PW page structure philosophy. I'm not sure that I will use this module myself, just because I don't really see a long list of pages under Home (or anywhere else) as untidy or cluttered. I would tend to use Lister Pro when I want to see some set of pages as a self-contained group. But maybe others will find it useful. At the moment this module does not manipulate the breadcrumb menu in admin. So when you are editing or adding a virtual child the real location of the page is revealed in the breadcrumb menu. That's because I don't see the point in trying to comprehensively fool users about the real location of pages - I think it's better that they have some understanding of where the pages really are. But I'm open to feedback on this and it is possible to alter the breadcrumbs if there's a consensus that it would be better that way. Virtual Parents Allows pages in Page List to be grouped under a virtual parent. This module manipulates the page list and the flyout tree menu to make it appear that one or more pages are children of another page when in fact they are siblings of that page. Why would you do that instead of actually putting the child pages inside the parent? Mainly if you want to avoid adding the parent name as part of the URL. For example, suppose you have some pages that you want to be accessed at URLs directly off the site root: yourdomain.com/some-page/. But in the page list you want them to be appear under a parent for the sake of visual grouping or to declutter the page list under Home. Example of how the page structure actually is Example of how the page structure appears with Virtual Parents activated How it works This module identifies the virtual parents and virtual children by way of template. You define a single template as the virtual parent template and one or more templates as the virtual child templates. Anytime pages using the child template(s) are siblings of a page using the parent template, those child pages will appear as children of the virtual parent in the page list and tree menu. You will want to create dedicated templates for identifying virtual parents and virtual children and reserve them just for use with this module. Features Adjusts both page list and tree flyout menu to show the virtual parent/child structure, including the count of child pages. Works everywhere page list is used: Page List Select / Page List Select Multiple (and therefore CKEditor link dialog). Intercepts the "Add page" process in admin, so that when an attempt is made to add a child to a virtual parent, the child is added where it belongs (the next level up) and the template selection is limited to virtual child templates. Intercepts moving and sorting pages in the page list, to ensure only virtual children may be moved/sorted under the virtual parent. Superusers have a toggle switch at the bottom of the page list to easily disable/enable Virtual Parents in order to get a view of what the real page structure is. Usage Install the Virtual Parents module. In the module config, enter pairs of parent/child template names in the form virtual_parent_template=virtual_child_template. If needed you can specify multiple pipe-separated child templates: virtual_parent_template=child_template_1|child_template_2. One pair of template names per line. There is a checkbox in the module config to toggle Virtual Pages on and off, but it's more convenient to use this from the page list. Notes It's important to keep in mind the real location of the virtual child pages. This module is only concerned with adjusting the appearance of page list and tree menu for the sake of visual grouping and tidiness. In all other respects the virtual children are not children of the virtual parent at all. It's recommended to select an icon for the virtual parent template (Advanced tab) so virtual parents are marked out in the page list as being different from normal parent pages. Do not place real children under a virtual parent. There is some protection against this when moving pages in the page list, but when it comes to changing a page's parent via the Settings tab the only protection is common sense. https://github.com/Toutouwai/VirtualParents

would be awesome if core natively supported dependent selects in repeaters!