Leaderboard

This week I've bumped the dev branch version to 3.0.241. Relative to the previous version, this one has 29 commits with a mixture of issue resolutions, new features and improvements, and other minor updates. A couple of PRs were also added today as well. This week I've also continued work on the FieldtypeCustom module that I mentioned last week. There were some questions about its storage model and whether you could query its properties from $pages->find() selectors (the answer is yes). Since the properties in a custom field are not fixed, and can change according to your own code and runtime logic, it doesn't map to a traditional DB table-and-column structure. That's not ideal when it comes to query-ability. But thankfully MySQL (5.7.8 and newer) supports a JSON column type and has the ability to match properties in JSON columns in a manner similar to how it can match them in traditional DB columns. Though the actual MySQL syntax to do it is a little cryptic, but thankfully we have ProcessWire selectors to make it simple. (It works the same as querying any other kind of field with subfields). MySQL can also support this with JSON encoded in a more traditional TEXT column with some reduced efficiency, though with the added benefit of supporting a FULLTEXT index. (Whereas the JSON column type does not support that type of index). For this reason, FieldtypeCustom supports both JSON and TEXT/MEDIUMTEXT/LONGTEXT column types. So you can choose whether you want to maximize the efficiency of column-level queries, or add the ability to perform text matching on all columns at once with a fulltext index. While I'm certain it's not as efficient as having separate columns in a table, I have been successfully using the same solution in the last few versions of FormBuilder (entries), and have found it works quite well. More soon. Thanks for reading and have a great weekend!

Using RockFrontend in a real project for the first time since yesterday – I'm totally blown away! Currently I am only using Latte templates and LiveReload, but these two features alone are such game changers. @bernhard Thank you so much (again!) for donating such a genius module to the community! I don't know if anybody already asked/answered this, so I'll leave this info here: If you want to add additional folders to be watched by LiveReload, you can define them this way: /site/config.php: $config->livereload = [ 'interval' => 1, 'include' => [ $config->paths->root . '/some/folder', $config->paths->root . '/another/folder', ], ];

Hey, I think this forum could benefit from a pinned thread where we can talk about anything and everything without needing to create a new topic, like a pub conversation that lasts all night, but goes on for years. ? If you are a moderator and like the idea, please pin this topic, otherwise just delete it, I won't hold it against you. ?

I have a huge collection of "never posted in the forums"-posts somewhere. So I really understand, enjoy and love that idea. And yeah... the Drupal-forum is a bit weird, yet the CMS and people have big place in my heart. Most of them are good people, yet the... exterior (if this is even a word) is a bit off-putting sometimes. Count me in on a off-topic/sh*t-talking thread while being polite, and not that mean.

Yes, sometimes I want to post some random message but I don't find a place for this. Today, I was looking for a Drupal forum, and when I found this, I thought it was created to discourage people from asking for help. ? Look at a topic, seriously...

Not a moderator at all, but I LOVE THAT IDEA... a full-fledged-off-topic thread. If I understand that right. And the later the day, the more interesting the topics (besides those excluded in the forum rules of course) become. My first off-topic just to crash this thread here already: ?

Just a thought for future in case performance really becomes an issue for someone: it's possible to add a generated + stored column to a MySQL table that feeds itself from a dedicated value in a JSON column, and this column can of course have a fulltext index. A hook on PageFinder::getQueryUnknownField could then "redirect" the query to the generated column. Would only work on single valued fields, of course. For anybody interested in creating such a generated field from a JSON field, here's a blog entry that explains it better than I could.

Can I get access to the repo? Can't guarantee I can tackle this right now, but when I can I'd be happy to work on it!

That would be nice to have for sure. If anybody wants to add it I'm happy to merge ?

session issue. add site/config.php $config->sessionCookieSameSite = "None"; and make sure site is https.

I've been wanting to review the 5 pages of responses and summarize the findings, but what I will say before (if?) I get to that: There seems to be three primary audiences that PW is catering to, or that it can potentially cater to: Developers (ease of development, API, headless, documentation, module development/sales, etc) Clients (security, continuously developed, version stability, availability of developers) Consumers: A developer and client all in one (all the ways in which it competes, and how it's different) It may not be evidently clear what the project is primarily aimed at catering to, and perhaps that needs to be clarified, whether directly by Ryan in terms of what he is interested/able in supporting, or by the community's desire (as Ryan seems amicable to our opinions on steering it). That may also help guide any potential website redesigns. I think this is an important question to really consider and have answered. Although it can be done, it's really hard to properly target all three of the above, all at once.

I don’t think that’s a bad thing per se, but I agree the big PHPStorm background could probably be replaced by just the slideshow of PW admin screenshots that currently plays awkwardly on top of it. Perhaps with one or two code screenshots intermixed. In general though, maybe I’m just old, but the site doesn’t look outdated to me at all? At least the frontpage looks as fresh as ever to me. Welcoming, professional, you name it. Certainly no worse than the examples mentioned? Wordpress has a trendy serif typeface which I get is part of their printing press shtick, but I honestly find kind of offputting for what it is (also the footer is grade A pure unadulturated organic cringe and all their images are blocked by Firefox’s default tracking protection). Structurally I think the ProcessWire site could use some improving, especially these “hub” pages like https://processwire.com/docs/, especially especially if they link to the next identical looking hub page (eg. https://processwire.com/docs/start/). Someone mentioned earlier that it’s a shame a lot of great nuggets and frankly vital info can practically only be found in blog posts. I know I’ve searched for specific blog entries I knew existed plenty of times, wondering how someone who hasn’t kept up with PW for over a decade would find out about stuff like custom user parents, for example. It would be great to have a more official tutorial section for these things which the blog posts would then link to. The current tutorial section only has 10 tuts, most of which, including the "More Tutorials" link, are secretly external.

Still interested. I agree the site doesn't do justice to the product. Wordpress is looking pretty good these days, and the only other alternative I've seen deserving of notice, CraftCMS, is also looking pretty good. I think our site is directed too much at the developer audience, and I often found myself having to convince my clients that this is a better option than Wordpress or whatever platform they have in mind. And the site doesn't help much at that. If you guys want to consider a redesign, I'll gladly join that effort.

@Christophe, I can't follow what you're doing so if you have a question specifically about Custom Inputfield Dependencies rather than the core show-if features then please rephrase it and include some screenshots. For now what I can say is: Custom Inputfield Dependencies uses the $pages->find() selector syntax as described in the PW docs. This is a different syntax than the core show-if selectors, so you can't just copy/paste selectors from one to the other. Syntax like "parent.id=1314 || id=1250" and "parent.id=1314 | id=1250" is not valid for $pages->find(). If you want to match one field/value combination OR a different field/value combination then you need to use OR-group syntax: https://processwire.com/docs/selectors/#or-groups And InputfieldSelector (the inputfield used by Custom Inputfield Dependencies for "Show only if page is matched by custom find") doesn't support OR-groups so you would have to use a selector string in "Show only if page is matched by selector". (parent.id=1314), (id=1250)

@soyerH, calling deleteAll() on a single image field is also working for me, so something unusual is going on for you. A couple of ideas... 1. Is the page a "normal" page or is it a User page that involves the alternate template/parent for users feature? Your page path and field name made me wonder this. If it is an alternate user parent/template and you can identify the steps to reproduce the problem please create a GitHub issue for it. 2. Does it work if you set the field value to null instead of calling deleteAll()?

Clickbait title aside, I recently found a cool new feature in PHP 8.1 and wanted to share it with you, in case you didn't know this either. Starting with PHP 8.1 you can write $this->method(...) (yes, that's the actual syntax, not a placeholder) to reference a method. I find this super convenient, especially for defining hooks. Plus the IDE can refactor this much better than the traditional [$this, 'method'] callback. <?php class MyModule { public function init() { $this->addHookAfter('ProcessPageView::finished', $this->doSomething(...)); } private function doSomething(HookEvent $event) { // TODO: something } }

Hello There @ryan just wanted to add my concerns here. I am not an "advanced" developer, i just develop sites or conduct experiments on my own personal website thats been running PW for a very long time now. That being said, i have read through this tread and i have become a little worried that PW would be going away from it´s root that made me many years ago fall in love with it. I am concerned that many of the more advanced users of the CMS want´s to take it to a more complicated place instead of keeping PW simple for us beginners to pick up and use wich is why i love it. As a laymans dev i can actually understand most of the API and what i can use it for. Ryan have made some posts in this tread that makes me feel calmer that the core simplicity is not going to go away. I also feel that many of the more advanced devs are missing the point of PW simplicty and why not everything should be in the core. There is modules for a reason,, want something special?, then create a module. Reasons PW appeal to me: 1. It´s API made sense from the start, logicaly and was adopted fast by my Authistic brain. 2. It´s does not interfere with how i want to render my website. 3. It´s has a great admin backend that should not confuse anyone. 4. PW is not WP. Thank you all.

From my perspective this is mostly spot-on @poljpocket. Yet there are a few things I'd like to add here: those of us that are active in the forum, read the weekly posts from Ryan, read weekly.pw from Teppo and follow every last bit... ProcessWire is evolving each day, each week, each month, all the time. YET... the last commit to master was 9-10 months ago, which is a century or two ago in the fast-living webdev-world - mostly due to the JS-sphere. I know a lot of people that look very close at this metric, but unfortunatelly on the wrong branch in this case. I'd love to see (and I personally keep it this way) the master branch as something like an LTS, while dev is more like a stable-rolling-release of some kind. I'd probably even use an unstable branch in some projects, even though there is no branch for it. BUT this isn't about naming, but MARKETING. And the last push on master is really bad marketing for ProcessWire right now. That's all I am saying. It doesn't look good. This needs to be changed. I don't care how, but it needs to be fixed. Fast! I don't care if we use SEMVER, ROMVER, WHATeVER, or any other way of versioning (besides the one from Ubuntu, which is really a bad look in the long run and introduces a lot of stress as there has to be a release no matter what at a specific date). All I need to know is if there are breaking changes or new requirements, like min. PHP 8.x and similar. I won't see (as in recognize) this in the version number and wouldn't even think about breaking changes the moment a ProcessWire 4.2 pops up in my upgrade module. Yeah, sorry... I just click UPGRADE as most of the users out there. Maybe the upgrading process/module needs a few upgrades, tricks, and markers to show and tell breaking changes, changed requirements, and what not. Sure more work for module developers but probably not really. Modules already have all these details like requirements. I'm not that deep into developing but as a user... that would be nice! One more thing... In this thread a lot of things were mentioned but mostly like "I'd like to have this feature and this, and that, and ..." which is fine. I'd support most of that. But I'd like to know and ask: Where do we want to see ProcessWire in 5-10 years? What can I do to support ProcessWire/Ryan more?

I think ProcessWire has a well-estabilshed versioning plan: Ryan is increasing the version every few commits whenever some notable new feature was introduced. And the master version then just follows suit. I think a set release schedule with fixed time intervals is a very bad idea. I have been working with WordPress in the past and they have been notoriously bad at using their fixed minor release schedule. Sometimes a version introduced very important and big features and other times, there was barely anything new but both were minor releases just because the schedule said so. I have only been in the ProcessWire game for almost three years and thus have started out around where version 200 was released. At that time, I didn't look at GitHub too much though. I didn't notice the "slow releases" at all and was mostly influcenced by the forum and the website. For me, they did a good job. As many before me have mentioned, community activity is very important especially for new potential users (and even more to the target audience: fellow developers). This could also be reflected in more activity on the master branch. Finding a good solution might not be the easiest endeavour though. Has there ever been a situation where old versions needed to be patched for some bugs or security vulnerabilities? I haven't seen one yet. I think this mostly stems from the slow master releases which only ever get done when high stability has been reached. So for me, every master release is a "LTS" version, which is a big strength of ProcessWire: I have no reason to ever update a PW website I did years ago. As long as it doesn't get outdated because of external influences (PHP EOL comes to mind). I think using time-based releases like Ubuntu or Windows don't make much sense for ProcessWire. Years give a feeling of outdatedness. This directly contradicts ProcessWire's strengths: It does away with the stability and ease of upkeep arguments. How do you explain to a client that PW 2016.3 is still completely fine in 2024 and doesn't need any updates whatsoever? With operating systems, you want a sense of outdatedness simply because there is much more incentive to update to never versions, e.g. for hardware compatibility or platform support. Why not stick with semver with a few adjustments? One idea is to keep the patch part of the current versions as sort of like a build number which would primarily be used on the dev branch to indicate new features and fixes. And then every master version gets a minor version bump which corresponds to a dev version (indirectly that is). This would then allow for security fix updates down the road. Not that this would be needed much :).

I'm not totally against that. I'm using semver for all my modules as well. But it also has downsides: Complexity: SemVer can be complex to implement correctly, especially for large projects with many dependencies. Subjective interpretation: Determining what constitutes a "breaking change" can be subjective, leading to inconsistent version bumps. Rapid major version increases: Frequent breaking changes can lead to quickly incrementing major versions, potentially causing version number inflation. Dependency hell: In ecosystems with many interdependent packages, strict adherence to SemVer can still lead to compatibility issues. Limited expressiveness: SemVer doesn't capture all types of changes, such as performance improvements or security fixes. User expectations: Users may expect significant new features with every version increment, which isn't always the case. Backward compatibility pressure: Developers may avoid making necessary breaking changes to prevent major version bumps. Learning curve: New team members or contributors may need time to understand and correctly apply SemVer principles. I've experienced some of them on my own. Personally I can't remember of a single situation where upgrading PW was a big problem. Maybe I had some minor issues, but I can't even remember a single one. Everything that is pushed to the core is listed in the commit log, so you can easily have a look there and check if upgrading is a problem for your specific instance or not. I think that's our responsibility as developers. I understand that it's tempting to go with SemVer, but I'm quite sure that once we have it there will be people complaining that they did an upgrade from PW 4.xx to 4.yy and there was something wrong... For the upgrade from 2.x to 3.x Ryan even added an upgrade guide: https://processwire.com/docs/start/install/upgrade/from-2.x/ So I'm not sure if your suggested switch to SemVer would improve things a lot, at least I don't understand it from what you wrote. Not saying that release cycles like in my ubuntu screenshot above would solve all problems, but I like the strong message that it sends out and I don't see such a message in PW 4.x, 4.y, 4.z ? Having regular releases could imho help in keeping focus. We (Ryan) could for example state that for the next LTS release the focus lies on improving the admin theme. In the next LTS the focus could lie on building a module ecosystem. In the next LTS ... you get it. Not sure if mixing LTS versions with stuff that is not code but project-related would be a good idea, but I wanted to throw in that idea. Maybe it would help to split the roadmap/ideas/requests into two parts, one for PW itself and one for the project/community around it.

@theoretic It's actually the opposite of that. ProcessWire is an API and that's all it is. Any output comes from the user of the API and not from ProcessWire, as it doesn't output anything on its own. ProcessWire started as a headless CMS, before the term even existed. The admin was later added on as an application built in PW, and then grew from there. But the base of PW is still just nothing but the API. ProcessWire itself doesn't output HTML. But since most use it for that, all of our example site profiles output HTML. There could just as easily be a site profile that outputs JSON or XML, or whatever you want it to. The point is PW has always been separate from whatever you choose to output with it, so that it has no opinion about what you use it for. While we could have a site profile that outputs something other than HTML, I don't really know what we would have it output or who it would be for, but maybe someone else does (?), it would be a simple matter.

This is super true. Gideon

Output logic is a part of the view. When I build a site profile to share with others my primary goal is to make it as simple and easy-to-follow as possible. For most websites powered by ProcessWire the template files are the views, and that's where I think most should start too, as it's very simple. As needs grow, many will naturally isolate the views to reusable files separate from the template files when it makes sense (like that parts directory in the invoice profile). But I think it's good for PW to be less opinionated about that because people may be using different template engines, different output strategies (direct, delayed, markup regions), etc., or they may not even care about following an MVC pattern, even if PW naturally leads there. This pattern was around before we had web sites/applications, so the "view" part is not like it was when we were building desktop applications in the old days with Borland C++. With HTML we've got server side markup and the additional layers of client side CSS and JS. Not everyone always agrees about where to draw the lines and it can depend on the case. I don't think we should decide that for people and I think it's good to be flexible on on this part of it.

@bernhard Good questions and I'll answer according to the design of the core. These considerations are rigid when it comes to what the core does with these Page classes, but flexible outside of that. You are using Page classes in a way that gives them multiple roles. Whether that's good or not depends on your architectural point of view. But it sounds like you are happy with how it's working, and you've got a well defined strategy, and this is valuable. So none of this may useful for your case, so keep that in mind. That sounds okay to me. Why does it load an extra 10-20 pages? Or does that just depend on what pages are used in the request? As long as that magic page interface isn't increasing resource usage each individual Page object significantly, then it should scale just fine. It shouldn't be related to either. It should be independent of environment. A page is a type that aggregates content for a location in the tree. The problem with having front-end-only or admin-only stuff in a Page object is that it's code in the page that steps outside of its role and applies for one environment and not another. It can be seen as a type of bloat, turning a Page object into a jack of multiple trades. If you've got significant code that's just for one environment or another then the idea is that it's better to keep it separate from the Page. Perhaps delegated to a different class like my earlier example (or even a function outside of a class). But if it's just for a one-off case or something then I wouldn't bother. Take that getPageListLabel() method, that's something to represent the Page in the admin only, which is why it makes me uneasy. It's a tradeoff. It's a one-off case, so I think it's okay as long as we don't add more like it. Potentially the method might have front-end value in some cases too, so maybe that's another reason it's an okay compromise. But if we found ourselves starting to put a lot of admin-specific methods in Page classes then those would be better in a separate supporting class or function, or better yet, decouple it from the class entirely. That way it doesn't add code to the page class for something that goes outside its responsibility. Another point is that often code added for one environment or another will be the same between different page classes. To avoid repeating yourself, you'd have to repeat the same methods in multiple classes, or more likely add complexity with more levels of inheritance or traits to share that code. Moving that code to a dedicated class makes it more contextual, maintainable and extendable across multiple classes. There's that word "things" which seems like it might mean "everything" in this context. Here we're treating the Page like it's a Swiss Army knife for the type, rather than the type itself. It's like being the car and the carwash, the lawnmower and the grass, or not just the ball but the bat and glove too. That editForm() method looks like it's got the Page class now involved in manipulating forms in the admin. In that case Page is not just a type representing an aggregate of content, but also a form editor, adding application logic, giving the Page class multiple unrelated responsibilities. Some responsibilities which apply to all instances of the page and others which might only apply to one instance on occasion. If the Page must be the gatekeeper for multiple responsibilities, the idea is that it would be preferable that it delegates those responsibilities rather than implements them itself. That would enable it to provide that interface without expanding the internal role of the class. If you find benefits in using them differently then I'm not suggesting you change anything. Since you asked I have to give you an accurate answer of what Page classes are originally designed for and what I consider best practices around them. These are how the core considers them and doing likewise ensures things stay simple, efficient and scalable in the long term. But in PW flexibility is more important than rules and this is also true of Page classes. There's more than one way to do things well, I like your creativity and if you've found something that works well for your projects over time and scale then stick with it.

I know this is ancient, but I wanted to note that if this worked in the past, it no longer works. I think I recently even saw reference to placing $config->debug = true in ready.php. None of these options work properly. If you want conditional debug mode, you need to use the debugif option: https://github.com/processwire/processwire/blob/35df716082b779de0e53a3fcf7996403c49c9f8a/wire/config.php#L56-L71 Keep in mind that setting it to true in a module or ready.php etc might make it look like it's working because the "Debug Mode Tools" link and icon will appear in the admin, but it will not output any errors/notices/warnings to the browser. Also, in the debug panel you'll notice that the "Database Queries", "Timers", and "Autoload" sections are not populated because they require debug mode to be on Also, of course, with Tracy enabled you don't really need debug mode on (or if you do have it on), it will take care of capturing any errors, and hiding them from users, anyway. The only thing you will be missing with it off, are those "Database Queries", "Timers", and "Autoload" sections.* Anyway, hope that helps to avoid any confusion for those who come here in the future. * This really wasn't meant to be a Tracy advert, but thought it was relevant because it solves the reason why you would want debug mode on only for superusers or the like.

just for the record, it is possible to add html to description via hook without messing around with str_replace or the like: $this->addHookBefore('InputfieldPage::render', function($event) { $field = $event->object; if(!in_array($field->name, array( 'fieldname1', 'fieldname2' ))) return; $field->entityEncodeText = false; $field->description .= ' <a href="#">test</a>'; }