ryan

@olafgleba Edit your /site/config.php file and look for: $config->httpHost and/or $config->httpHosts. In most cases the $config->httpHost should not be present (since PW will set it automatically at runtime), but the $config->httpHosts (plural) should be present, and it should be an array of http hosts ProcessWire is allowed to auto-detect and use. It will pick one of the hosts in that array to use for the request, so long as it matches the $_SERVER[HTTP_HOST]. If it can't find one that matches the $_SERVER[HTTP_HOST] then it will simply use the first one in your httpHosts array: $config->httpHosts = [ 'www.company.com', 'dev.company.com', 'localhost:8888' ]; If it just contains one host then it'll always use that one, regardless of what's in $_SERVER[HTTP_HOSTS] … $config->httpHosts = [ 'www.company.com' ]; If you do have the non-plural $config->httpHost present (like below), then it forces use of that hostname, rather than letting PW auto-detect from your httpHosts array. Though if there's only one host in your httpHosts array (like above) then of course the effect would be the same. $config->httpHost = 'www.company.com'; My best guess is that you either have $config->httpHost or httpHosts set with '127.0.0.1', or that you have httpHost/httpHosts undefined in your /site/config.php file. To fix it you need to add your www.host.tld to a $config->httpHosts array and preferably as the first item in it. If you do see a $config->httpHost (non-plural) in your config.php them I would remove it.

@ttttim In my experience a 504 gateway timeout comes prior to PHP max_execution_time and may not even be related to it (?). Which is to say, I think it's a server timeout setting that is probably specified somewhere in Apache or prior, rather than PHP. But my experience with 504s is mostly limited to this server we are typing on, and in the case of this server, I will get a 504 timeout on a long running process and the 504 comes from the load balancer rather than the actual node that is running the script. So when a 504 occurs here, it just breaks the connection with the browser but the script continues running till it finishes, interestingly. I have no idea if your case is similar, but one thing I can suggest in your script is that you call PHP's set_time_limit(600); within your long-running loop to reset PHP's timer on each iteration (600=10 minutes, or a different time if it suits you), otherwise you likely will be subject to PHP's max_execution_time as well.

@JerryDi I don't think there's a right answer as to what would be the best structure for your case. It really comes down to your needs, which I don't have enough familiarity with this to give an ideal answer. You'll be able to build your search for championships by club, player, etc., either way, as PW will make that simple. You can have any kind of parent/child relationship for those championships such as… /years/year-num/championship-name/ /clubs/club-name/championship-name/ …and so on. But another route to take (and what I might recommend here) would be to have a /championships/ parent and have all the championships under there, perhaps auto-sorted by year. Each with fields for "year", "club", "players", etc. /championships/championship-name/ And perhaps fields like "club" and "players" on each championship page would be page references to other pages setup in a similar structure: /clubs/club-name/ /players/player-name/ …and so on. Taking this route (where all championships share a common parent) may not be perfect for any one need, but will likely be a good fit for a diverse range of needs, a solid choice overall. So without knowing the details of your needs that's the route I'd probably take.

@Manaus This is a case where you should do a 302 redirect $session->location($article->url); rather than render different articles at the same URL. Otherwise folks won't be able to accurately bookmark it, and it'll confuse search engines, so it'd be an SEO problem. But I'll assume you know that and you want to do it anyway. What Zeka mentioned above is a good way to go, and probably the one I'd choose. But here's also another option below. It assumes you have a "latest-article" template and it is used by the page /latest-article/. /site/templates/latest-article.php $article = $pages->findOne("parent=/articles, sort=-created"); if(!$article->id) wire404(); echo $article->render(); If you are using prepend/append template files, then you'd also want to check the box to disable them in Setup > Templates > latest-article > Files (tab).

@Robin S @bernhard @teppo I would say it's less important to limit how many fields you create than it was before, but it's still worthwhile to make efficient use of fields for other reasons (at least for the way I work). But the technical reasons for doing so appear to be much less than before. If you look here at the performance numbers on a system with 1000 fields you can see that prior to lazy loading, it took 0.5167 ms (half second) to load the fields. This might sound reasonable, but note the fields were created with an automated script and not as diverse as they would be in a real environment, so I'd expect the numbers to be higher/slower in real life. After lazy loading that part of the boot process was reduce to 0.0062 ms. Even without lazy loading enabled, the field loading was reduced to 0.0322 ms (in that 1000 field environment) just due to the other optimizations made in support of lazy loading. So there's some question as to whether lazy loading is even necessary anymore now that everything else more optimized. But using less time and energy is always good thing, even if not felt on individual requests, small differences add up to significant numbers over thousands of requests. The way lazy loading works is that everything in the database table (for fields, templates, fieldgroups) still gets selected and loaded, but into an array rather than into objects. That data doesn't get loaded into and converted to actual Field (or Template, Fieldgroup) objects until that specific object is requested. TheTuningSpoon found that overhead came from actually creating and loading the objects rather than selecting them from the DB, and I was able to confirm that. But it also means that the more fields you have, the more memory they will consume. But the memory consumed by the raw field data is very little and I think you'd have to have many thousands of them for it to even be a consideration. Lazy loading fields don't change the way I use fields, at least. I like to have as few fields as necessary just because it's easier for me to keep track of, fewer things to remember when writing code, fewer things to manage during changes, etc. But if your workflow is like the one Bernhard describes above then that seems like a case where more fields would appear to be a benefit.

This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.

@chrismac That error seems to indicate that you might potentially be running a very old version of ProcessWire 2.x (last updated 7 years ago). While the module (ProcessHannaCode) is designed for ProcessWire 3.x (the current one). That's the only explanation I can think of for that error message, as there is no "ProcessWire\WireData" in ProcessWire 2.x versions. The only way to resolve this is to remove the files that were installed, removing the /site/modules/ProcessHannaCode/ directory that was added. This has to be done by someone with access to the server files, such as your web developer or someone with FTP access to the server.

@Matzn Your TestModuleChild.module is overriding the getModuleConfigInputfields() of the TestModule.module and replacing it. In PHP, if you want the parent method to run, then you need to either omit the method completely in your child class, or call the method parent::method() so that it will run (like what you are doing with your __construct method). What you are doing currently is replacing the method with one that has no code in it. What I think you are wanting is this in your TestModuleChild.module: public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); } After doing the above, now it will inherit the code of the parent class. And after calling that parent::method() maybe you want to add another configuration setting to it, i.e. public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'test_field'); $f->label = 'Test field'; $f->val($this->test_field); $inputfields->add($f); } But if you don't want to add anything new to the getModuleConfigInputfields() then just leave the method out of your TestModuleChild.module completely, and it will inherit automatically. Also, module configuration data should be defined with runtime calls, so I recommend you remove this: public $field_1 = "parent module property 1"; and replace it with this in your __construct(): $this->set('field_1', 'parent module property 1'); I see you are using static getModuleInfo() methods in your classes. In cases where you've got one module extending another, unless the child module literally does an include() at the top of the parent module's file, then you should define your child module's info in a ModuleName.info.php file like I described in my previous message (including the 'requires' statement), and omit the getModuleInfo() static method. Otherwise, if PHP/PW happens to include() the child module before the parent module, you'll get a fatal class error. By using a separate ModuleName.info.php, PW can learn about the module without having to load the class file, and it can see from your 'requires' statement that it needs to load the parent module before your child module, ensuring no fatal errors. If you can't do this, or don't want to, then make sure your child module does an include() or require() of the parent module's file, somewhere before your "class TestModuleChild ...".

@DrQuincy Yes, sorry, it should be "return $this->halt();" rather than just $this->halt(), I have updated my example. If you don't do a return then it'll still do the same thing (see below), but instead it'll continue executing your code in that file after the halt() call. What $this->halt(); does is tell the current request not to render any more files. So if you call $this->halt(); from your template file, then it's not going to include any further files specified to render afterwards. For instance, it will skip rendering your _main.php file (if you are using one). But everything else about the request will continue normally, so it does a normal shutdown, etc.

@Matzn ProcessWire classes are just PHP classes, so there would be no difference. Note that I don't think you can have a class named "Parent" as I think that might be a reserved word in PHP. I wouldn't bother trying to do an external configuration class. Start with an internal getModuleConfigInputfields() method, and when all works, then consider moving it to an external one if needed. Make sure your module implements the ConfigurableModule interface, indicated at the top of the class. I also think maybe you shouldn't try to extend your Parent module/class and instead should just write another module that pulls from the Parent module what it needs. Module inheritance is useful in many situations but it's not clear to met that this is one of those situations, though I could be wrong. This is fine the way you are doing it, but note that your class "Child" need not extend "Parent" given the approach you are using. Your "Child" module could just extend WireData instead, and the code in your myMethode() would do exactly the same thing.

@DrQuincy Is this from a template file? You could do this: echo "<p>An error occurred!</p>"; return $this->halt(); That halts the rendering of output but lets PW finish everything else in the request. Another option is to throw a WireException. This will also halt the request but allow PW to still shutdown. The response is an http 500 error. The error message will be displayed if in debug mode or if the user is logged in and a superuser. throw new WireException("An error occurred!"); Often times on the front end a fatal error is about a resource not available, and a 404 is the appropriate response. So you can do this: throw new Wire404Exception(); or this does the same thing (I prefer this shorter version): wire404(); Lastly, while the above are preferable, it's also okay to do an exit() or a die(), is shouldn't break anything at least.

@Matzn Are you wanting a parent/child class relationship, or are parent and child modules separate modules where you want the child module to pull a value from the parent module? If you just want to pull a configuration value from "ParentModule" to use somewhere in "ChildModule" (or anywhere else) then you don't need to have a parent/child relationship between the modules and can instead just pull the value you need: $api_user = $modules->getConfig('ParentModule', 'api_user'); On the other hand, if you really do want a parent/child relationship between the module classes, and they will be two separate installed modules, then it is possible. Many Inputfield and Fieldtype modules use this approach. For instance, InputfieldCKEditor extends InputfieldTextarea, and InputfieldTextarea extends InputfieldText. The reason is that they all have similar configuration needs, as they are all inputs for text. InputfieldCKEditor builds upon the configuration of InputfieldTextarea and InputfieldTextarea builds upon the configuration of InputfieldText. When it's possible that someone might attempt to install the ChildModule without having first installed the ParentModule then it's recommended to keep your module-info in a separate php (or json) file like ModuleName.info.php, at least for the modules that require another (i.e. ChildModule requires ParentModule). This ensures that if ChildModule is on the file system, but ParentModule isn't, PW can identify the requirements for the ChildModule without having to load its class file. (If it loaded its class file, then it would result in an error since ChildModule extends ParentModule, and ParentModule isn't present, so that's why we want to avoid that). Let's say we've got this ParentModule: // ParentModule.module.php class ParentModule extends WireData implements Module, ConfigurableModule { public function __construct() { $this->set('api_user', ''); // establish default value parent::__construct(); } public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'api_user'); $f->label = 'API User'; $f->required = true; $f->val($this->get('api_user')); $inputfields->add($f); } } And it also has this ParentModule.info.php file to define module info. Since ParentModule doesn't extend another module, it could also be in a static getModuleInfo() method if you preferred it, but we'll stick to the file for this example: // ParentModule.info.php <?php namespace ProcessWire; $info = array( 'title' => 'Parent module', 'version' => 1, 'summary' => 'Parent module description', ); Here's a child module that extends ParentModule and also adds an "api_key" to the configuration: // ChildModule.module.php class ChildModule extends ParentModule implements Module, ConfigurableModule { public function __construct() { $this->set('api_key', ''); // default value parent::__construct(); } public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'api_key'); $f->label = 'API Key'; $f->required = true; $f->val($this->get('api_key')); $inputfields->add($f); } public function test() { $this->message("API user is $this->api_user and key is $this->api_key"); } } …and the ChildModule's info file is below. Note the "requires" that says it requires ParentModule: // ChildModule.info.php <?php namespace ProcessWire; $info = array( 'title' => 'Child module', 'version' => 1, 'summary' => 'Child module description', 'requires' => 'ParentModule', ); Zeka's example above is also a good one, but just adding my example as another variation.

@cpx3 There's definitely something strange going on with that selector performance, so I'd still recommend that strategy of removing things from it (in the order mentioned) to identify the bottleneck. Once we know the bottleneck we can focus in on the particular field or fieldtype that is having the performance issue and hopefully find a solution. That's interesting that adding a "created>date_minim" helped, but it makes sense as it would just reduce the quantity in the set from which it has to match, so likely the bottleneck is still there. How many pages total are in this site?

It's been a quiet week on the dev branch (mostly), and so this post will also be short. That's a good thing, as it means we are at a stage where there's no new major things to immediately fix or add. Assuming that remains the case, by next week at this time we should have 3.0.200 released on the main/master branch. In next week's post I plan to outline all that's changed since our last master version, 3.0.184, stay tuned and have a great weekend!

@cpx3 First, make sure that the issue isn't that the selector is getting called repeatedly in a loop or something. Once you've confirmed that it's only getting called once per request, the next step is to identify what in the selector is making is slow (1200ms is slow). Remove the "id!=" from the selector, as that doesn't do anything. Update the order of the selector to the following. This is the order that I think represents the most likely bottlenecks towards the end, and the least likely towards the front, so it'll be easier to debug in this order. template=template-news, limit=5, sort=-created, checkbox_not_startpage=0, checkbox_not_startpage=0, select_countries=oesterreich, select_categories!=tipps|shortcuts, begin=(start_date=''), begin=(start_date<=today), ending=(end_date=''), ending=(end_date>=today) (Note that I've replaced your "end" with "ending" since "end" is a reserved word in PW, though it may not matter here.) Using your debugger (Tracy?) start removing parts of the selector from the end, until it starts performing fast. For instance, first try removing this from the selector: ending=(end_date=''), ending=(end_date>=today) Note what difference it makes, then remove this also: begin=(start_date=''), begin=(start_date<=today) and then this: select_categories!=tipps|shortcuts ...and so on until you get to "limit=5" and stop there (don't remove "limit=5"). Let me know what you find.

@David Karich I was working on the snapshot module for awhile, then got sidetracked on another project and lost the momentum on it. Hopefully will return to this, though now that I've been away from it for awhile, I can see I was having a lot of fun developing it but am starting to question whether it's really that useful. The language translation export/import module is currently in development and a sponsor split the cost of development with me. It is currently fully functional and in client testing right now. The major features are built but there's still a few smaller things I want to finish developing before it is ready for production use. This one is pretty close to being finished though. @szabesz The control of types is still on my radar. Are you looking for it with nested repeaters or with depth repeaters? I think depth repeaters is where people were looking for it, but wanted to confirm. The background-color for repeater matrix items was implemented last year, and should be fully functional. Where do you see the hex codes show up, in the page editor? They shouldn't be, I've not seen it, and it's not been reported before as far as I know, but if it's something you are seeing (dev branch and latest RM) please let me know.

This week's commits for ProcessWire 3.0.199 focus primarily in wrapping up several remaining reported issues in preparation for our master/main release version. So you can think of 3.0.199 as very close to a release candidate for the next master/main version. A few of the issues resolved this week were ones that had been around a long time, due to being difficult to reproduce, or issues that had been held off for awhile because they were going to take additional time to resolve. (See commit log for details). Having closed out a few of those older issues this week, I'm feeling good about where the dev branch is right now and think we're just about there. If you have a chance to test out the current dev branch (3.0.199), please let us know if you run into any issues. At least one person has asked about why we're not bumping the version to 3.1 (previously, or now). The reason is that all 200 versions of 3.x should be compatible with each other, enabling one to upgrade (or potentially downgrade) between the 3.x versions, without any drama. That's a good thing I think, and so I'm kind of proud that we are approaching version 3.0.200, which will hopefully be our next master. I'm sure we'll have a 3.1 at some point in time, but I'd like to keep on the 3.0.x track so long as upgrades remain drama free. Thanks, and have a great weekend!

@theoretic Sounds like a fun project. If I understand correctly, you are doing a select to read the value, then incrementing the value in PHP, then writing the value. With concurrent requests doing that, there's always a gap between the read and the write, so you should expect that some of the requests are naturally going to collide, unless you use a different strategy. What you probably need instead is a single update query that does a "col=col+1" instead. Otherwise you'll have multiple requests reading a value (like the number "3"), incrementing it, then writing the same number "4" to the DB. So the final number would always be less than the number of requests sent. The reason being that some other request may have incremented the value in between the time another request read and then wrote the value, so they'd always be overwriting each other, writing the same "4" to the DB. If you need separate read/write queries, you'd need to obtain both a read and write lock to the table row you intend to update, before you even read the value. And you'd need to release the lock after you write the value. You'd also have to account for the cases where you cannot obtain a lock (due to being locked by another request), by having a retry mechanism. Without a retry mechanism, you'll also end up with some unaccounted for requests. A good example of the pattern you are trying to achieve is implemented in the SessionHandlerDB module. It has to obtain a read/write row lock and read the session values. Then at the end of the request, it has to write the session values, then release the row lock. That way concurrent requests in the same session can't overwrite each other's data. But it also means that concurrent requests are queued and have to wait in line for their turn to control the data. The same would be true in your test case. Lastly, pay attention to the http response code on the concurrent requests. Requests can be refused, especially if concurrent from the same session or IP. They can be refused by Apache or PW. So a request cannot count towards a total unless it returns a "200 OK" response code (this would be true for any concurrent testing of web requests whether w/PW or elsewhere).

This week on the dev branch we've got a good mix of updates and issue resolutions, though not quite yet enough yet to bump the version number just yet. But here's a few highlights: There's a PR from Adrian committed which adds configurable columns for Selector fields. System update 20 was added which fixes the "created user" for several system pages. WireHttp was updated to support sending cookies in GET/POST requests powered by CURL. Lister was updated to recognize non-sortable fields, preventing unnecessary error messages. There were also 3 issue resolutions this week. We are getting down to the smaller stuff in terms of updates, which means it's about time to get that next master version out. I know I've been talking about it for awhile, but think we'll likely have one more dev branch version (3.0.199) and then it's looking like our 200th 3.x version will tentatively be the next master version (3.0.200). Thanks for reading, Happy Earth Day, and have a great weekend!

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!

I figure this is an off topic board among friends here (like our pub, or a real one) and it’s okay to write with honesty and engage in spirited or sometimes heated conversation. So just want to be clear that I like and respect @MoritzLost and value his opinions, even if I don’t agree with all of them. We will all have a diversity of views and everyone should feel free to share them, and likewise others should feel free to question those or state their own, which is what I’m trying to do. But I’m glad MoritzLost shares his opinions here. Plus, a little controversy also helps to engage the community, and drags me out of the code for a bit, so I can’t fault anyone for that. Once I can state my thoughts, I carry no concerns, but thought I should defend the things that deserved defending, as I always should. As a caretaker of this project, part of my responsibility to add my honest point of view to a conversation like this, especially when something is posted where I don’t fully agree. I think many in our community know the subjectivity of statements here (whether OP’s, mine, or another’s), but an equal number may not, as this is a public board. So some counterpoint or back-and-forth is not only clarifying to the larger audience, but also useful, as we explore different facets of it all, and lead to the most important takeaways. I appreciate that MoritzLost continues to defend his point of view on parts, despite my own defense or heated questioning of those parts. It helps me to better understand and know which are the parts that he thinks are most important and deserve the attention. We obviously don’t have the resources to pursue everything Craft does, so narrowing in on the most important parts—the meat of it—is helpful here. I’m traveling right now so can’t participate as much as I’d like to at the moment but just didn’t want MoritzLost or anyone else to think I was angry or something. Likewise I didn’t want anyone else to think they had to moderate themselves either. When I’m among friends I feel comfortable to express and be honest, and so should you. If you get a heated reply from me it’s because I care about it and value your opinion. I’ll spend more time reading everything when I get back, but I can see already it’s a good and helpful discussion.

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.

A few weeks ago I told you about a new module I was working on that automatically saves front-end form submissions and can send email reminders for the user to finish their form. The module is called FormAutoSaver. This week I finished up that module and have released it both in the ProDevTools board and the FormBuilder board, and it's available for download now. Note that it is first release/beta test version right now. This module can be used with or without FormBuilder. Though when used with FormBuilder it is more of a turn-key setup that can be done in the admin. I've put together a dedicated FormAutoSaver documentation and information page on the site, so rather than repeating a lot of information here I'll point you to that, if you are interested in it. I also wanted to mention that a new version of FormBuilder has also been released this week (v52). There aren't any major feature additions to write about here, but there are several small improvements and bug fixes. By the way, I've added FormAutoSaver to one FormBuilder form on this site: the site submission form. There's not much to see, since it silently works in the background. But if you want to try it out, fill-in some or all of the form (making sure to fill in your email address), but don't submit the form. Feel free to leave the form or even switch devices. You should get a reminder email in 5-10 minutes with a link to finish your form. While you are there, please submit recent sites you've built in ProcessWire, we love seeing your work! My kids are starting spring break from school next week, so I'll be mostly offline and likely won't have any updates next week, but will be back to core updates after that and hopefully getting ready for a release candidate of our next master version shortly after. Thanks for reading and have a great weekend!

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!

This week's commits are primarily focused on resolving reported issues (via GitHub issue reports). While that doesn't make for exciting reading here, it's an important part of working towards our next master version. Though I am working on various other projects including client websites running in ProcessWire, ongoing updates to Pro modules and development of other ProcessWire modules. One module I've been working on this week (and last week) enables you to export translations for multi-language fields into JSON or CSV files. These files can be read into other translation systems, edited, and then imported back into ProcessWire. So if you need all the content for a site translated from one language into another, it provides a very convenient means of doing so. More details on that one soon. That's all for today but stay tuned and thanks for reading. Have a great weekend.