Leaderboard

Hi friends! And thanks for ProcessWire! Maybe I'm a bit late to the party, but I'd also like to bring some ideas here. Processwire is a great CMS having many brilliant ideas inside. But there's always some space for further improvements. JAMStack paradigm It's about static html pages which have some javascript-driven parts interacting with some APIs and changing their look and feel depending on what users do and which data API provides. Sometimes there's just a single static html page which behaves as a multipage web application, sometimes there are just small dynamic chunks. This approach has many advantages: There's no need to generate pages each time they are requested from server. They can be generated just once. Returning static pages drastically reduces the server loading. Static pages are safe by nature. There's nothing to hack there. And even if someone hacks into the server, there will be only some static html files there. APIs return pure data, no html at all. The most typical API data format is JSON which is pretty compact and human readable already, and there are others (bson etc.) which are even more compact. Processwire vs JAMStack The current ProcessWire is pretty far from JAMStack paradigm: By default, PW is about generating pages on each server request. And, being fair, lots of such pages could be static (generated only once). If someone will take a closer look to how the actual PW admin works, he/she will find that there are ajax-driven things there. But in these cases PW generally returns the chunks of html markup, not pure data. There's no native PW tools providing an easy way to build an API over PW. There are some 3rd part modules, and it's not a rocket science to build a PW-based API from scratch, but no native support out of the box. Processwire as "headless CMS" Headless CMS is a CMS which can only return data, not html. This approach is an important part of JAMStack approach, and there's plenty of such CMSs on the market. PW can be a perfect headless CMS, but it's not by default. You need to build an API on the top of PW to make it "headless". I did this in some of my projects, and I'm quite happy with the result. But, come on, give me a reason why this functionality doesn't deserve to be in the PW core? ) Processwire as "static site generator" (SSG) SSGs are another important part of JAMStack world. They are tools allowing You to make static html files based on the data and the templates You have. Contrary to headless CMSs, SSGs are generally the tools used locally, and the result (static pages) is later uploaded to server. It's quite interesting that PW can be a server-based SSG! I also did this, and I was quite satisfied again. But AFAIK there's no core-level or even 3rd party tools to do this using PW. Bringing the pieces together PW can make a big step from the ol' good paradigm of server-side page rendering to the modern JAMStack. Two things are missing: Native tools for building an API on top of PW. Again, it's doable, but it's not native. A PW-compatible (maybe even PW-based) SSG which won't be a headache. Both things are not rocket science, and they potentially could bring much more attention to PW, make it interesting for younger devels. I had a lot of talk like "ahhh You're that guy from 90ties, still writing php code and making server-rendered pages? You're the past already, man!". Hope this will worth a good discussion ?

See my query here: My solution was to bulid my own module - HannaMigrate. Basically it exports or imports all Hanna codes in a database. It was built to use along with my migration module ProcessDbMigrate, but should operate without it (but not tested). It provides 2 methods exportAll() and importAll() Simple usage: Install the module. Use TracyDebugger console in the source database to: $hannaMig = $modules->get('HannaMigrate'); $hannaMig->exportAll('optional_migration_name'); where optional_migration_name is a name of a related migration, if you are using ProcessDbMigrate. Otherwise leave blank and the code will be in assets/migrations/hanna-codes/. Then use TracyDebugger console in the target database to: $hannaMig = $modules->get('HannaMigrate'); $hannaMig->importAll('optional_migration_name'); (Do this while on the Hanna Codes page, then refresh the page to see the results and any error messages). You could also use the methods in your own code. I may look to integrating it more fully in ProcessDbMigrate.

ProcessWire Improvement Suggestions I’m pleased to see ideas being gathered to improve ProcessWire, and as a loyal user and contributor since 2014, I'd like to share my list and thoughts on the matter. Over the past few years, there has been a lack of clarity on whether requests and ideas will be implemented, and if so, when. Requests and issues often remain open for years without updates. I'll address how this can be optimized. There is also no clear way to influence these decisions. Years ago, we introduced the idea that thumbs-ups in the Requests Repo should mark the importance of requests. However, there's still no way to know if any of these points will be implemented. My idea for the future is as follows: Increase Community Involvement and Establish a Fixed Release Cycle Optimize Integration of Requests It could be beneficial to review which GitHub issues have the most thumbs-ups within a set period (e.g., quarterly or biannually) and then fix or implement them. If there are too many features or if requests have the same number of thumbs-ups, a poll could be conducted in the forum to see what the community wants implemented first. Introduce New Status Labels for Requests Under consideration In Progress Completed Faster Closure of Issues When a request is integrated, it should be closed immediately rather than marked as “completed.” Often, the requester doesn’t provide feedback or forgets to close the issue (which has happened to me as well). If something doesn’t work, the issue can be reopened. Automatically Close Stale Issues There is a stale action for GitHub that automatically closes issues after a period of inactivity. The issue creator can reopen it by responding. Better Definition of ProcessWire’s Target Audience The target audience for ProcessWire is not clearly defined. This makes it difficult to determine which features are truly necessary. Developers will likely have different requirements compared to someone looking to create a website quickly and cheaply. Developers eventually hand over the website to a client, who then manages the content themselves. Non-developers struggle to know which modules exist to manage their website. The module installation process is cumbersome, which is why I developed the ModuleManager2 years ago (link). Despite user interest, it hasn’t been widely used. There was a discussion that module installation directly through ProcessWire was rejected for security reasons (though my module only uses core methods). Integrated module management, similar to systems like WordPress, Prestashop, or Shopware, would simplify module discovery, installation, and maintenance. Discovery Process The discovery process is beneficial for all users, including power users. Sometimes I can’t remember a module’s name, but with MM2, I can search for a term in the description and find the corresponding module. Security is a concern, but I believe it’s possible to implement this in a secure way. PHP 8 and Named Arguments Finally, PHP 8 and named arguments will greatly assist in module development. Easier Customization of the Admin Theme Custom Navigation It's cumbersome to change the navigation or create a completely custom one without creating a new admin theme. This has been mentioned before (insert link). This is usually only necessary when developing custom software with ProcessWire. It would be helpful to create menu items that link to modules or specific actions within those modules, or simply a URL path. Introduce a dark mode (toggle switch). A quick solution is with one line of CSS: nightowl, but an integrated dark mode would be better. Global Media Manager A global media manager is a great idea, especially for certain assets like logos or seals used across multiple pages. While it’s possible to create a page and field to source these images, it’s not user-friendly for newcomers. For instance, I have a client with 30 product pages that require seals to be updated annually. A central management point would simplify this process. I’ve implemented this for my client, but it’s challenging for those accustomed to systems like WordPress and conceptually difficult to grasp. Aligning with Conventions from Other Frameworks Environment Configuration A .env file to store database connections, httpHosts, etc., which are read by site/config.php and site/config-dev.php. The config-dev.php file should include config.php and allow properties to be modified/overridden. This is how I and others currently do it (insert reference). Automated Deployments and Module Updates Composer is a stable package manager for PHP and a convention widely used in the PHP community, making automated deployments and updates easier. Built-In SEO Built-in rudimentary SEO would be a significant plus for websites. During installation, users could choose between a website or custom software without a frontend. If they choose a website, either ProcessWire-Core-SEO or the SEOMaestro module could be selected for installation. Lack of Visibility on ProcessWire Adoption There is no clear overview of how widely ProcessWire is adopted, such as the number of installations. This lack of visibility can make it difficult to gauge the platform's popularity and growth. Absence of a Marketplace Ecosystem The absence of a marketplace ecosystem makes it uncertain for module developers like Bernhard or myself to determine whether and how much money can be made from developing modules for ProcessWire. Other systems like Kirby, Statamic, and WordPress have a store that can be accessed directly through the admin interface. These stores also include license management, making it easier for developers to monetize their work and for users to manage their purchases. Proposed Marketplace and Revenue Sharing One idea could be to introduce a marketplace for ProcessWire, where a portion of the revenue from sales is reinvested into the development of ProcessWire. However, this is not a necessity and should be a point of discussion, considering the controversies seen with Epic or the Apple Store.

Aha! Always something more to learn... I use that module a lot, but never explored individual tables. I guess it's fine where the tables are 'stand-alone' as in this case, but otherwise it might get a bit scary. No matter, the module was quite quick and fun to write and hopefully carries less risk of screwing up the database ? EDIT: Plus I can integrate it into my migrations module if I want to.

You can use Ryan's ProcessDatabaseBackups module to do this. Export: Import: Without ProcessDatabaseBackups you could use PhpMyAdmin or Adminer to do something similar. If your Hanna codes reference external files (I prefer to use files for my Hanna codes so I can edit them in my IDE) then you would need to copy those to the other site too.

Welcome on board. So... as it seems your MariaDB isn't configured as it should be. What kind of setup are you using? DDEV, Laragon, local installation, or remote? You might want to get MariaDB fixed first. As far as I can tell, this isn't ProcessWire's fault. For the future tell us a bit more about everything. Setup, ProcessWire version, PHP version, and all these nice little details. For now I can only suggest that you look that error message up and check the solutions provided there.

Hello Robin, Your module is so helpful/useful. I'm using "Show only if page is matched by custom find" and the parent (page) id. Thank you!

@ryan In the store, the text on the Login Register Pro product page says: "After 1-year, you can optionally renew your access to the support/upgrades board for a nominal fee". I noticed that the text of other modules did also change that way. Which means, the renewal fee is not specified anymore. Could you please add the renewal fee(s) again, to the product pages in the store? I am not only interested in them myself, but also my clients, which always want to know what the yearly subscribtion fees are. Thanks in advance!

I love this module.

No replies to the above and no solutions I could find, so I built my own module. See here

As a default? Big NOPE from me. The super easy way and low barrier to enter the world of ProcessWire was one of the main reasons I gave it more than a quick look, did all the tutorials, read the docs, read the forum, ... and stayed. I tried a lot of CMSs back then and because ProcessWire had this "direct output"-way of achieving a lot without needing to know much about PHP or programming in general was the biggest PLUS ever. if/else/echo/foreach is almost everything you need to know to get up and running - and this quite far. Easier than anything. Easier than the Wordpress-loop, Silverstripe's way of doing things, or Drupal and Typo3. Such a delight and super fun to learn something new, a new CMS. Sorry for interrupting this great discussion.

Hi all. Reading through the discussion about page classes, I have to add my two cents. I feel like we are mixing concepts here. We are talking about OOP concepts where the request arises to extend page classes' capabilities to better allow for separation of concerns. Many OOP concepts stem from or are just a fancy form of the MVC pattern. I strongly believe ProcessWire follows such a form too. Whereas the core handles MC and it's API provides endpoints for the V in Model-View-Controller and hooks for extending and altering the C part. So to really allow for separation of concerns, page classes aren't the right place to start off. A page is just the representation of an entity, a line in the database. Instances of said class that is. And thus Page and page classes belong to the Model part of ProcessWire. And this is exactly where my motivation to side with @ryan and his general scepticism of page class init and ready methods comes from. So it makes sense to add virtual properties or basic relationships to the page class. But the model should never contain business logic which acts outside of the lifecycle of the entity. Having made my point so far, I think Ryan's second to add a new class file to act as a controller (by using the ProcessWire's hooks) makes a lot of sense. And exactly that is why I believe, ProcessWire already offers a very good way to enforce MVC patterns and true separation of concerns. It offers a good API without forcing everyone to use the same architectural patterns so many other systems do.

@Jonathan Lahijani Preferably use require_once() or include_once(). But if you prefer autoloading, you could add this in your /site/init.php if you wanted to autoload any classes in /site/classes/ that ended with "PageHooks": $classLoader->addSuffix('PageHooks', $config->paths->classes); ProcessWire's class autoloader is more efficient than most, but if you already know a file exists and where it is, I prefer to require_once(). It's more efficient and more clear, nothing hunting for files behind the scenes. There's a reason why this file exists in ProcessWire, even though all of those classes could likely load without it. It makes the boot faster. Class autoloading is obviously necessary for many cases, especially if working with other libraries. But for a case like the one mentioned here, skip the autoloading unless you feel you need it.

Thank you for all of the feedback! Definitely want to build more e-commerce, but just not in the core. I'm intrigued by what Jonathan mentioned and want to learn more. I suspect it influence the roadmap quite a bit. Would enjoy building an asset manager but since my clients don't need it, I could only build it by self funding it. I don't have the ability to self fund it yet. Agree PW should continue to grow on the framework side in the next major version. I don't know in what ways specifically just yet (feedback welcome), but am stating my agreement. I think we've been on a good path in this regard so far and should keep going / go further. Don't agree that Page objects need more initialization methods, but let's duke it out. ? Agree we could use a new site profile, preferably a professionally designed one. Agree we'll definitely continue improving the admin theme and maybe even add another. Prefer to avoid features that blur the line between content and style or front-end and admin, though there can always be exceptions. The requests for Inputfield/InputfieldWrapper sounded good. Supporting more DB platforms is also on my wishlist, but not sure it can be done in the next year as there are some challenges there. Note: replaced original/longer post with summary/bullet points.

Thanks for this topic @ryan! Great to have a chance to look into the future and maybe even influence it a bit. I agree with @Jonathan Lahijani, but we surely need to expand on that. I can understand his point quite well. ProcessWire taught me be a (somewhat) ambitious developer, that is ready for bigger projects. And some of those grew big enough I started seeing the limitations of PW. And though I think that PW might be not the best choice for some projects (bigger web apps, as Ryan himself pointed out before), it can have its sweet spot in between regular CMS and web frameworks like Laravel. I will try to point some of the ways I see to improve PW to move further into that sweet spot. For now I can throw in this one: A better way to build custom user admin area. Reusing existing admin сomponents, but without the need to hide lots of stuff with permissions and hooks. So we could build something like /user-admin with limited functionality, but still using page edit module.

Making ProcessWire stronger for full-stack web application development, allowing it to become an unassuming alternative to Laravel and Rails but from the origins as a CMS. ProcessWire is the perfect CMS (there's no doubt in my mind about that), and it's actually already quite good for web application development (both natively and with 3rd party modules), but with some enhancements to make it more "batteries included", enhancing page classes and some tooling, ProcessWire can have its feet in both the CMS and full-stack framework buckets in a way that's perhaps unique. I can elaborate on this further as that sounds a little too generic, but I've been developing a web application with PW for over 9 months (it's a very complicated project and it's replacing an existing, in-production system which makes it even more tricky and high-stakes) and when it's done I can share some ideas. This one enhancement alone moved the needle quite a bit in making ProcessWire more web application friendly.