Leaderboard

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.

Client quote: We just want a simple event calendar. Simple, right? We just add a DateTime field! Not really... One DateTime field is not enough, as we might have a date range, like summer holidays. Ok, so we add a second DateTime field? Ok, but what if we want a single full-day event, like one single holiday? And how would we easily query all events that are "active" in one month? The module is a commercial module and can be downloaded here: https://www.baumrock.com/releases/rockdaterangepicker/ Docs: https://www.baumrock.com/en/processwire/modules/rockdaterangepicker/docs/ Note: There's also a Pro Module by Ryan, which you find here: https://processwire.com/blog/posts/date-range-fields/ - For my use case this module was unfortunately not usable, because the daterange picker that Ryan chose does not support time inputs. As this was a no-go for me and I found the library www.daterangepicker.com which does exactly what I need, I went ahead and built that module. PS: When using AdminStyleRock it automatically applies the primary colour to match your admin style 😎

At the risk of repeating myself: semantic versioning would be a small but extremely helpful step toward a more seamless upgrade experience. Having an unusual versioning scheme would be perfectly fine if there was a public changelog available. Currently, upgrading is a crapshoot — you can't tell from the version number if it's a fix release or a feature release, and there's no changelog to help figure it out. Going source-diving is an option, but not feasible for every single update. One could stick with the master version, but the latest master was released 11 months ago and it's common to aim for quarterly security updates, so we're back to the dev branch.

As a non professional webdesigner (pure amateur...) I'd like to add to the discussion of versioning. I experienced that a potential "client" I wanted to convince of PW got the impression that in 3.0.xxx the quickly increasing values of xxx would indicate a continously need of fixing lots of bugs. (At the end he changed his opinion.) But also for me it's not comprehensible that we didn't have steps to 3.1 or even 3.2 back already, since there have been some notable achievements in the meantime.

@bernhard That sounds good to me. Probably out of scope relative to our resources in the short term, but longer term this sounds like the ideal. This is one of many reasons why I like to get a new main/master version out, but it's probably not often enough. Maybe one way to keep the main branch fresh for folks looking at the date you pointed to is if we maintained a changelog type of file that covered all the versions, including the dev branch versions. This changelog file would exist on both branches and get merged to the main/master branch every time the version number was increased, regardless of branch. Also a good point about the README links. That makes sense that those links should move closer to the top. Maybe at the top it should also mention that there are new dev branch versions at least every month. Good ideas. Growing the user base is good for everyone. Good for us and the community, and good for those new users who get something great they didn't know about before. I think I mentioned "overhaul of this website" in the message that started this thread. We are ready for a redesign after 7 years no doubt. Ideally I'd like to have a pro design it, someone like @diogo or one of the other great professional designers in the community, like those you mentioned. I've thought a redesign could be both of the website and the admin, and that perhaps they even use the same design/theme. I have some rough ideas about the design concept but I'm not the right one to design it. It's definitely not a default Uikit theme by any stretch, but if that's the impression you get, then understood. One thing that looks dated is the computer on the homepage, it's still my 2017 iMac that I use everyday, so my computer is a bit outdated too! But until we have a new design in place, I've thought I should just remove that computer and leave the text. Something like this might be good at least for instances where someone wants priority attention to one thing or another that might not otherwise get priority. I focus largely on issues that are easily reproducible and affect many people. If an issue only appears naturally in very rare instances and is a simple matter to work around, or if it's difficult to reproduce (requiring a lot of set up or combinations of factors), then I try to delay those until time is more abundant. I can easily lose days of work trying to identify and fix obscure issues that won't help many people. The reality is I love going down these rabbit holes, fixing things is actually quite fun, but I have to be careful and pick-and-choose or I'll lose valuable time with little to show for it. I love it! I do wonder if the modules showcase is relatable enough to people that don't already know PW, and thus may not know what modules are. Might also be confusing in the admin side, where there's also a Modules tab, and folks might get mixed up about what is what. But I like the idea of having a different demo site, regardless of what data it is showcasing. What about if we linked to off-site demos? Your demo for RockFrontend is fantastic and I like how it actually lets them edit everything and resets it every hour (is this really secure?). But I imagine you and others in the community could also build a great ProcessWire demo that we could link to. The win-win of it would be that we'd be sending you traffic and you could promote your tools in the demo as well. The same demo page on the ProcessWire site could link to the demo for RockFrontend, PAGEGRID, and others. Basically, a compilation of PW demos, rather than just one. I could also update the Skyscrapers profile and make that one of them, but even an updated one should probably be near the end of the list of demos at this point. Always a good idea. We kind of do that already in the About section, but it needs a content refresh. Also, having the year in there is a good idea since I think that's what people are searching for, and thus attracts search traffic. Good points. The "sell" part of it isn't really in my bloodstream, so as you say, it's something where we'd need experts. I was looking through your website the other day and actually think you do a great job of communicating and thereby selling your products and services. Your skills here also come across in your recommendations, thank you for all of the good ideas.

@ryan On topic of the website: There is a YouTube video embedded on the documentation for multi-language fields, which is set to be private since a while: https://processwire.com/docs/multi-language-support/multi-language-fields/ Also the ProcessWire Developer Directory has still the old design and is now broken for years: https://directory.processwire.com/ ? Regards, Andreas

@ryan you're right, my checkbox was configured to be a "reversed checkbox" via the module CheckboxReversed. I changed the value to 0 and now it works perfectly.

The issue with any kind of demo site catalog is that someone needs to make sure there are no outdated profiles and new ones should also be added frequently (preferably). It would be possible to have the profile import its catalog data upon install, so new installs would receive up-to-date data, but who would be the one to keep that data up-to-date in the fist place? I also have a similar idea and that might not be visually as attractive as a catalog of nice looking websites, but would be much more useful for us and also for a newcomer: https://processwire.recipes/ but with some trained (on PW) AI tool added, like: https://huggingface.co/blog/how-to-train https://www.google.com/search?q=how+to+train+my+own+language+model And community users could maintain its database somehow...

The animation on the homepage is a bit hard too read at its current size. Getting rid of the iMac and the IDE background and showing just the Safari windows should allow things to get a bit larger. Apart from that, the design of the site is fine in my opinion. Not sure if a complete overhaul is a great investment of time here. I agree that the content of the demo site should be unrelated to the ProcessWire ecosystem to make it relatable and understandable by newcomers. Skycrapers were and are pretty great here. Birds would also be fun ? If we create and link to demo sites, I'd be wary of using (too many) commercial modules. Otherwise we're creating the impression that people need to buy a bunch of paid modules to create nice websites with ProcessWire. We should definitely strive for a commercial module showcase, but mixing that with demos sends the wrong signal in my opinion.

I don't think it's bad to have less frequent master versions, it just needs to be clear that PW is VERY actively developed. Maybe I'm not the right person to ask, though, because I'm always on dev ? But in terms of marketing I think alone such a schedule could be worth gold: https://ubuntu.com/about/release-cycle This alone says a lot: They have a plan They care about their product and their customers When choosing a recent version (24.04) I'll likely be fine for the next 10+ years until 2036 They still support 14.04 which is more than 10 years old, which says a lot I as a customer know what to expect A lot of that is true for PW as well, just nobody knows. In some parts we are not there yet (I think part of that has already been mentioned as versioning chaos or similar). So maybe instead of semantic versioning we could introduce PW 24.04 LTS and PW 24.10, 25.04, 25.10, PW 26.04 LTS... I think having such a release cycle could help in many ways, like working on clear roadmaps, prioritising issues or features and it could also help developers in what to tackle and what to just wait for until it is built into the core or a pro module. Also, having a 10 year LTS would be an incredible strong marketing signal! And PW - as we all know, but many don't - has always been like this, which is outstanding. --- I have to leave unfortunately --- So what if we used the PW developer directory for this instead? I think this would be a win-win again. First of all we showcase our developers instead of skyscrapers ? We show that PW is used by many developers around the world and when done correctly this could also be such a thing that I meant when saying "help devs to make money". For example if that profile looked really good and showcased the skills of that developer, he/she could use that profile to show his/her skills and credibility to customers and hopefully sell more, make more money, contribute more to PW, etc. Every PW developer should feel like a hero, not a stranger using something that nobody else uses (again please don't take me word by word). We could maybe show the forum post and like count, show badges, show site of the week awards, etc. This could serve as a kind of gamification on one hand but could serve a very serious aspect on the other hand: Help the dev grow as a dev, grow as a business, grow as a person. It could show statements of other developers, like "what others say about me". So if a potential client doesn't know a developer the developer could share his PW profile and it might help in getting the job. Thank you very much. Glad if something was helpful! Now I really need to run. Marketing experts, the stage is yours ?

@nurkka It works for me at least: $wire->addHookAfter('Pages::saved(toggle_checked=1, status<trash)', function($e) { $page = $e->arguments(0); $e->warning("Saved page $page->path"); }, [ 'priority' => 200 ]); Check if your checkbox field is configured to have a non-default value?

Hi @Edward Ver don't worry, we are here to help you navigate PW! Here's an example for the menu you asked for: <?php // Get the homepage $home = pages()->get('/'); // Get the children of the homepage $children = $home->children(); ?> <nav class="menu"> <ul> <!-- Loop through each child of the homepage --> <?php foreach($children as $child): ?> <li> <a href="<?= $child->url ?>" class="menu_link"><?= $child->title ?></a> <!-- Check if the child has sub-children --> <?php if($child->hasChildren()): ?> <ul class="sub-menu mega-menu"> <!-- Loop through each sub-child --> <?php foreach($child->children() as $subchild): ?> <li class="menu-item-has-children"> <a href="<?= $subchild->url ?>"><?= $subchild->title ?></a> </li> <?php endforeach; ?> </ul> <?php endif; ?> </li> <?php endforeach; ?> </ul> </nav> The code wasn't tested but it should work.

RockAdminTweaks v1.9.3: Some bugs where fixed thx to @adrian

Nevermind, I think I just found it - an empty email address for one user :)

ProcessWire do not have to strictly follow SemVer, there are alternatives, for example: https://github.com/romversioning/romver Or better yet, we could come up with our own, tailored to both ProcessWire and its modules. The issue is that currently there is not much transparency, except for those who keep an eye on Ryan's weekly messages and his longer blog posts from time to time. I think versioning could be improved.

Actually having a demo per (first party) site profile would be a good showcase of how these can be good starting points while showing how versatile PW can be, e.g. with the (great) invoice profile.

Hey @ryan thank you very much for the invitation to write a blog post. I'll probably ping you about that when my client projects that I'm working on are done! Regarding selling modules: I want to add that it can be very complicated to sell stuff online in the EU due to tax regulations. In very short as soon as you hit 10.000€ revenue you need to charge tax in the country of the buyer, which can be 7% CH, 19% DE, 20% AT etc... There are companies that offer the service to sell stuff for you, so you only have one customer instead of hundreds. But they charge for it, of course. So if you ask me it would be ideal if PW had a shop for commercial modules where all you have to do is add a github link to a private github repo and PW does the rest. Which is invoicing, taxes, generating license keys, offering download links etc. I know it's a huge task to do, but if I'm just sharing my point of view from selling modules. It would also be great if the customers were able to update modules with one click, just like they can do with regular modules. In case of commercial modules the'd need to have a valid license key in their settings, of course. And of course, that should only be done on development environments. I'd be more than happy to pay a reasonable share for that and support the project with my work. ------------------------ But what I actually wanted to say: @ryan could you please make it more obvious how great PW is and how actively it is developed? I think @teppo does a great job with his weekly newsletter and that also deserves a lot more attention! I just checked the website and the github repo again. I know we've "lost" people just because they looked at the github repo and saw the last commit on the main branch was over a year ago and they thought the project is dead. We all know better, but newcomers don't and the amount of work put into PW is unbelievable and people should instantly see this! I also checked the download page on the website: These two buttons probably don't mean anything to a newcomer. And the sentence below is really hiding itself. What about something like this? The breaking change thing might get a footnote that we are talking about breaking changes to the API here. English is not my first language so there might be better wordings, but you hopefully get the idea. Or maybe something like this: I think "we" already have an absolutely great product and we can be very happy to be able to use it. @ryan I hope you are very proud ? But I think this is not obvious to someone evaluating ProcessWire and maybe we could do more in that context. I don't know if growing the userbase of PW is a goal of @ryan at all or should be. But at least for selling modules it would be a benefit. Also when looking for a job it's a lot easier to find an employment as a WordPress dev compared to a PW dev, I guess. An interesting retrospective: I remembered we had a discussion about this topic some time ago. Turns out "some time ago" was 2017 ? https://processwire.com/talk/topic/17348-is-pw-becoming-more-popular/ It's an interesting read and shows that the same still applies 7 years later. wow. Ok so I googled a bit and found that the current website of processwire.com seems to be from 2019: https://processwire.com/blog/posts/pw-3.0.124-and-new-site/#new-website-launched And while I can remember that a lot has improved it's still not a great website at first sight, to be honest. @ryan please don't get me wrong, I know it's a lot of work and it's a great website and I know it has a lot of great stuff under the hood (like multiple instances talking to each other via API and bootstrapping, etc). Or take the blog post: That's great, but no website visitor will ever realise that! All a first time visitor will see is an more or less default UIkit theme which looks outdated to be honest. Compare that to some agencies from the showcase section (eg https://typneun.de/) and you'll notice a difference ? Maybe one of them would be happy to sponsor a facelift for processwire.com ? At least @heldercervantes showed his interest in that in 2017. Ok, so I explored a bit more... And compared... What do the folks at Nette do? From the Design imho not a lot better if at all, but I love the catchy statement at the top and they instantly show some big brands that sponsor the project which instantly builds trust. I'm not a marketing or communication specialist, but this is some basics I realise. I'm quite sure we have experts that find a lot more room for improvement ? I'd also love to see sponsorship packages for processwire where agencies can support the project and also SHOW the support. Something like this maybe: Gold sponsor Logo on frontpage 999$ / year Silver sponsor Name on frontpage 499$ / year Bronze sponsor Fund 1 hour of bug-fixing 99$ / year Maybe github issues of gold sponsors could be addressed with priority or such. I don't know. Don't get me wrong again. I like that PW is not dependent on someone elses money, but it will definitely not hurt to add the opportunity for PW users to give something back without asking for any return (which is different to buying pro modules). I know that many buy pro modules just to support ryan, which is nice but again is not obvious and does not build trust for anybody viewing the pw.com frontpage. Ok so I jumped back to pw.com ... For the record, here is a current screenshot: So I clicked on "demo" - I haven't been there for some years... Ok... Frontend... Ufff. 2024? Doesn't look like. And again it hides all the beauty that lies under the hood. Ok, so over to the backend demo: A lot has been said about the pw backend already, this shows that it might be a worthwhile area to work on. What it shows is a big orange warning about an .htaccess issue. This is probably not a good invitation for anybody new. Maybe it even draws people off. Instead it should show a huge warning like this: What if we dropped the skyscraper profile and instead built a new modules directory which can serve as a new showcase? Keeping a profile up to date that is not used (and probably not of any use other than showcasing pw) is maybe unnecessary work if the same thing could be done with something that creates additional value. Also I think it could be good to showcase the PW can be an absolutely great choice for modern frontend tools like TailwindCSS, AlpineJS or HTMX. I think we could really do a lot on that front just by thinking less about the product (pw is great and I think that is not going to change, whatever we do or don't do) and more about how to communicate this. What about a section where we showcase "ProcessWire as XXX Alternative in 2024" Many people are unhappy with existing CMSs. If I was unhappy with WordPress I'd probably google "wordpress alternative 2024". Many products do that and have comparison pages on their website where they show strengths and weaknesses of both tools and by that make it easier for people to understand what PW is, what it can do, where it is good at and where other tools might be better. This post has again got far too long ? But one final note: I think it would be great if PW not only was a great product but also helped people using the tool make money. What do I mean by that? IMHO ProcessWire does not sell itself. It can be hard to compete with other tools that are more popular. At the moment basically anybody doing business with PW has to "sell" processwire as the correct tool on his own. Not everybody is good at marketing though, so it would be great if that was done by experts. For example we could have professional guides why pw is the right tool for job x or y on the official website. Like @dotnetic's post for example: https://dotnetic.de/blog/processwire-the-best-cms ; Edit: Note that I don't think that this is the responsibility of PW, but I try to say that PW could make it easier for us on the marketing front and everything that helps people that are using PW make money will help the project as they will have more money to spend or more resources to contribute or have more spare time to share modules with the community. The idea is to establish a strong win-win situation. I don't know how exactly but I'd love to see processwire being a tool that, when chosen, let's the dev assured that he/she can on one hand trust the product and rely on it and on the other hand also know that there is a market for it so that he/she can make a living and that it's worth learning and exploring the system. PS: If anybody has not yet starred the pw repo and is still reading, please do it now ? https://github.com/processwire/processwire

Like others I was also attracted to PW by the simplicity and low entry barrier. @ryan I am very grateful for the work you put into PW. The development experience with building the module was great, even addictive and I learned a lot on the way. I was also going to suggest Kirby as a good example. I think a redesign of the modules page would help a lot. A buying option is maybe not needed for now, but having a category like „commercial/paid“ that is easy to find. Also a „module of the month“ or „loved by the community“ (based on likes) section and a prominent spot on the homepage to highlight some modules would be nice. I am on mobile right now and can post more thoughts on this once I have some time. Edit: Also +1 for letting superusers access this new "module explorer" from the admin. This would make installing modules even easier and give new modules more attention. (Maybe we can address the security issues, that were mentioned.)

@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.

Use the main menu to go to Modules > Configure > FieldtypeFile In the "Allowed Fieldtype modules for custom fields" field, tick the checkbox for URLLanguage. It says it may not be 100% compatible with custom fields but it seems to work fine for me.

Hi @Paul Greinke - as @teppo said, it still works as intended on the most recent PW versions and I use it in production so I should be aware of any issues that might arise in the future.

"If it works, don't touch it" ? Seriously speaking though, this module works well and does what it needs to do. So yes, if you want to restrict access by branch then it is a good option, regardless of which core version you are using.

This error also happens with PHP 8. Modify line 707 $_timestamp = ''; to $_timestamp = null; Solve the error. Gideon