Leaderboard

I am with you @EyeDentify when you praise PW's simplicity and easiness to start to get around. But PW is also great being a powerful framework. Ryan always managed to balance things perfectly. New cool things like custom page classes never disturbed ones that didn't need them. So I am sure we can easily move forward making PW more suitable for larger projects, multi dev on the same project, more best practice compliance without sacrificing simplicity for the newbies.

These things are so easy to do with RockMigrations: <?php // site/migrate.php $defaults = [ 'type' => 'image', 'maxFiles' => 1, 'descriptionRows' => 1, 'extensions' => 'jpg jpeg gif png svg', 'maxSize' => 3, // max 3 megapixels 'icon' => 'picture-o', 'gridMode' => 'grid', // grid, left, list ]; $rm->createField('your_image_field1', $defaults); $rm->createField('your_image_field2', $defaults); $rm->createField('your_image_field3', $defaults); You can then set custom labels for your fields or you can even set custom properties either in migrate.php overriding the defaults or via GUI as template context override. PS: If the fields already exist you CAN use ->setFieldData() instead, but ->createField() will work as well. PPS: If you need to change a setting just change the setting in the defaults, save the file and refresh your web broser!

If you want to support the development of my PAGEGRID module you can find it now on Kickstarter. You can donate here. Thanks for your support!

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.

Well... processwire.recipes uses Astro as of right now, therefore not a great example but... I can offer processwire.pw as a demo platform and resource. Yet I'm open to move processwire.recipes over to ProcessWire and the community. That's why I re-booted it. It's for the community - not me. Btw - I was finally able to get the old domain / @marcus: As I mentioned Astro here... they have an awesome way to communicate their progress and they move pretty fast. Their versioning and communication, community talk and support on social media is on point. Maybe those points should be added to the ProcessWire 20XX agenda as well. more community work* more visibility in social media* more activity in social media* * yes, that's most of the time on us and not on @ryan more communication and posts on processwire.com/blog every weekly forum post should be a blog post, and the blog should be the leading source (my opinion) - right now it's in the forum, but... a new thread in the forum with a link to the blog post would work for me and would be even better for everyone. As mentioned before: it's about marketing, therefore the blog should be the leading source. (Change my mind!) blog posts should be posted on: X/Twitter, Facebook, Reddit, Discord ... whereever we have an official home or community - and even in non-official homes. final solutions from the forums which involve PHP/API code should/could be posted to processwire.recipes (ping me to add that recipe if you like!) for ProcessWire, modules, hooks, hacks, ready.php, whatever it's easy to add a recipe Thoughts about Demos and Profiles each and every profile should be super close to the user, the user's needs and therefore a longliving and understable profile and concept. Examples should be timeless, therefore no need to update them once in a while: Skyscrapers ? American Diner Restaurant Classic Movies Collection Grand Mom's Recipes Antique Shop Inventory Billboard Charts History these examples alone would support everything we all ever faced and built - I guess. (Apps not included, but as starters) all these examples would build a solid foundation for all kinds of websites and projects we face nowadays (still apps and custom things not included) I repeat myself here but I can offer processwire.pw as a demo platform for that, all we need is long-term Hosting SSL CI/CD deployment and/or someone that maintains those installations

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 :).

@cpx3 You store the products in the session or a cookie, you don't need the session_id to do that.

Me too. You can solve this (from a technical point of view at least) by using language-alternate fields. Combine that with @bernhard's great suggestion to sync settings between your language fields and you should be all set. The only thing you're not getting from that is the cool tabs system LanguageTabs provides. I am always extensively tagging both templates and fields. With the tags, you can even have some of them be collapsed by default. This retains all the overview I need.

Sorry, I told you I was just guessing 😅 It should work using the updated code above. Apparently "owner" needs to be prefixed by the name of the repeater field. This time I have tested it.

Dev ProcessWire could just have a second firstname, Rolling. What about a(n) appointment, booking, scheduling (, calendar) system as a new site profile? Edit: Perhaps integrated as a module(s).

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.

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.

@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

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.

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.

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

@kongondo Thanks for your efforts on this. I personally think you should have started a GoFundMe to help you. The end result of your efforts will give PW a credible option to turn to instead of defaulting to Shopify.

The collaboration between dotnetic and Fugamo highlights the importance of a well-designed, efficient website for attracting and retaining customers. Fugamo, a provider of custom clothing for schools, clubs, and organizations, faced significant challenges with their old website. Slow load times, outdated design, and cumbersome content management were major issues that hindered customer engagement and conversions. The Challenge Fugamo's primary goal was to present their product offerings effectively, but their old website's sluggish performance and unattractive design made it difficult for potential customers to explore and make inquiries. Additionally, the absence of a wishlist feature complicated the user experience, leading to a lower conversion rate. The content management system (CMS) in place was inflexible, making it hard for Fugamo to update and create new content efficiently. The Solution Design Overhaul: We prioritized a visually appealing design to engage Fugamo's target audience — students, schools, and clubs. The new design incorporates vibrant colors, dynamic graphics, and interactive elements like an animated header. This not only enhances user experience but also strengthens Fugamo's brand identity and emotional connection with visitors, increasing the likelihood of customer loyalty. Centralized Content Management: A key improvement was the integration of a centralized interface, streamlining the management of both the website and the online shop. This ensures that new products can be added quickly and efficiently, keeping the website up-to-date without redundant manual updates across multiple platforms. Mobile Optimization: We implemented a responsive design ensuring the website performs well on all devices. This approach guarantees a seamless user experience regardless of the device used, addressing the needs of a mobile-savvy audience. Wishlist Feature: To enhance user interaction, a wishlist feature was introduced. This allows users to mark products of interest and include them in their inquiries through the contact form, simplifying the process and encouraging more customer engagement. Flexible Pagebuilder: We incorporated a flexible pagebuilder tool (RockPageBuilder), enabling Fugamo to easily create and update content. This tool simplifies the management process, allowing for quick adaptations and additions, crucial for maintaining an up-to-date and engaging website. Live Search Integration: A live search function was added, providing instant results as users type their queries. This feature significantly improves user experience by making navigation and product discovery faster and more intuitive, which can increase user satisfaction and the likelihood of conversions. Techniques and Technologies Used ProcessWire CMS: We utilized ProcessWire, our favorite CMS known for its flexibility and power. The existing e-commerce system is also based on ProcessWire, making it an ideal choice for seamless integration. Key Modules: Several ProcessWire modules were employed to enhance functionality: RockPageBuilder: For easy content creation and management. RockFrontend: Supports modern frontend development. RockMigrations: Facilitates field and template creation and data synchronization. FrontendForms: Simplifies form creation, management, and validation. SEOMaestro: Provides tools for creating sitemaps and managing Open Graph data. HTMX and AlpineJS: For drawers, navigation and live search PageimageSource: Optimizes image management and display. Latte Template Engine: Offers a powerful and secure template system. Outcomes and Impact The redesign and optimization efforts resulted in a significant improvement in website speed and user experience. Enhanced design elements and faster load times led to longer user sessions and reduced bounce rates. The introduction of the wishlist feature and improved content management increased the number of inquiries and conversions, helping Fugamo attract more schools, clubs, and students. Conclusion The Fugamo website revamp underscores the critical role of a modern, user-friendly website in business success. By addressing performance issues, implementing a captivating design, and enhancing content management, dotnetic helped Fugamo boost their online presence and customer engagement. This case study exemplifies the necessity of ongoing digital innovation to meet user needs and drive growth in the competitive online marketplace. For more details, visit the Fugamo Case Study (written in german).

Thanks @kongondo! That's bloomin' marvellous ?? Just a thought... Sorry.... Haha. Would it be possible to add another property called 'bankAccountName' as sometimes it will ask for the business account name when people go to pay? What say you?

@DV-JF Fixed.

I've been playing with CloudFlare's cache everything feature to serve a site that's hardly ever updated from the edge. It works amazingly well on non-PW sites, speed is so fast it seems you're serving the site locally. But I'm having the same issue as @chcs with that PW site, all assets are fully cached but the page. You can easily check this using Dr Flare's extension on Chrome. Anyone knows why the response header is set to no-cache for HTML pages served by ProcessWire, and how we can bypass this?