szabesz

...meaning one solution is to utilize the template files (originally meant to be the view) as controllers and provide the view through a 3rd-party module or a similar custom solution that one implements. While that is a working solution for sure, it highlights the fact that MVC for the frontend is somewhat overlooked by ProcessWire, not guiding newcomers into recommended patterns and/or best practices. I think even beginners in PHP should be pointed in a direction that encourages learning best practices and design patterns that will help them become good developers, instead of recommending the "direct output" because that will be enough for their first few small projects.

And where is the separation of the View and the Controller when the example is this: https://github.com/processwire/site-invoices/blob/main/templates/home.php ? How about implementing a faceted navigation like that in a template file? We have the Model for the frontend in the form of the Page class, which is fine. We also have the View for the frontend in the form of the template file, which is also fine. What I am missing is the "official support" for the Controller. If the other two components are already in place, I believe it is reasonable to request the third one so that we do not have to invent our own if we prefer not to.

BTW, BookStack should be considered as the next generation for ProcessWire's documentation system, I think.

Regarding page content creation by "site editors" in the admin, since TinyMCE's future regarding its open-source state is questionable, Dan Brown at BookStack started to implement a replacement based on lexical: Building a custom editor would also allow ProcessWire to cater to its own needs, like a live preview feature described as: It would be nice to be able to implement sort of block editor-like features in the RTE (and share them with the community). More complex block editors have their use cases and clients for sure, but for most projects, being able to do some sort of simple block editing would be enough, just like Ryan's example here: https://processwire.com/blog/posts/using-tinymce-6-in-processwire/#example-of-using-extra-css-styles. But, instead of very limited techniques like that, a custom RTE could provide a more robust solution without being a full-blown frontend block editor like RockPageBuilder and PageGRID. Such a custom RTE would automatically be supported by Ryan's PageAutosave module and its Live Preview feature.

For real? This is the first I've heard of any chaos. If my wording was too harsh, I apologize for that. What I meant was that the fact that integers and strings can be used for module version numbers causes unnecessary issues on its own, for example: https://processwire.com/talk/topic/13389-adminonsteroids/page/39/ Quote: issue was: Any one else having trouble with this module not detecting updates with Ryan's ProcessWireUpgrade module? Some of my sites are stuck at AOS version 1.6.71 and it but it also reports 1.6.7.2. As you can see in the picture, there is another version available but it doesn't give me an option to download/update it. reply was: Sorry, that's my fault, I've mixed the string vs numeric versioning and that's why the chaos (adrian reminded me). Next time I'll double check :) comment was: Also, next time for string versions, I think you should leave off the trailing period :) Also, if one reads the whole thread of @netcarver's ModuleReleaseNotes Module, then there is a good view there to see how many variables he had to tackle: https://processwire.com/talk/topic/17767-module-release-notes/ I think sticking to semantic versioning would solve most of these issues and would also support this: Since if there are no strict versioning requirements, then it is hard to imagine a robust and extensible module manager in the first place, no to mention Composer support.

@Ray Thanks for taking the time to write your explanations and examples posted here. Currently, I am more interested in "multi-site" than "multi-instance", but supporting multi-instance can also be essential for sure. By "multi-site", I mean that the project I am working on requires multiple frontends, managed and served by a single instance of ProcessWire, providing a "unified admin" in that manner. As I need to further develop this site this year, I will take your advice and utilize delegation the way you explained. Thanks!

I second this.

I'd like to highlight this because it only requires willingness and nothing more, but it would streamline upgrading efforts significantly. Enforcing it on 3rd party modules would also be welcome. See: https://semver.org/ The current versioning chaos is a drawback for sure.

I do not think anyone suggested having "more" initialization methods. Instead, it would be nice to see fewer of them while still being able to initialize everything necessary. Most importantly, the documentation could be extended to show real-life examples of how to use Custom Page classes, including implementing some form of abstracted page request handling (both get and post) without having to use if/else trees at the top of template files. Regarding adding hooks, I use a static method, which should not incur any overhead. I explain it in this post of mine: Quote: /** * ... page specific hooks. This method is called from site/init.php from my custom loop * that runs for each frontend template based page. * if (in_array($templateName, config()->noneFrontendTemplates)) { * if ($templateName === "user") call_user_func_array("{$namespace}{$className}::initiate", []); // UserPage needs special treatment. * continue; * } * if (class_exists($namespace . $className)) call_user_func_array("{$namespace}{$className}::initiate", []); // Page classes register hooks in their initiate() method this way. */ public static function initiate() { parent::initiate(); wire()->addHookBefore("Pages::saveReady(template=product)", function ($event) { ... more hooks go here .... Having the code of hooks in the same file as the custom page class is a productivity booster for me. After all, in those hooks, the object we deal with is (mostly) a page object of that type. I would be happy to put that code in some other equally well-organized "spot" but putting hundreds of hooks directly into init.php and similar files is a big mess in my opinion.

I recommend uninstalling it as it has more problems than features. See : https://processwire.com/talk/topic/23457-functionality-clash-with-system-notifications/#comment-215415

https://hamy.xyz/labs/2024-01_htmx-vs-alpine Quote: "Low-js tools like HTMX and AlpineJS are the future of the web. They allow us to build modern web apps without the bloat of popular SPA frameworks." What perplexity.ai says: https://www.perplexity.ai/search/explain-the-pros-and-cons-of-l-IrCeVWXSTAWsWJEv_GuNIA Let's think forward...

I use a mixture of calls to run various initializing code, depending on what to initialize, e.g., copied from a Product page's custom class: /* * Called when the page is requested on the frontend. * Called from _init.php via include_once(config()->paths->templates . 'path/to/this/_init_once.php'); * so that it only runs once per request: * page()->requested(); */ public function requested() { $this->request_ws = "\ProcessWire\RqtProduct"; parent::requested(); } /* * When initialization of object properties is required right from the beginning. */ function __construct(Template $tpl = null) { parent::__construct($tpl); $this->factsAy = new Arrayy([]); } public function ___loaded() { parent::___loaded(); // Either building a structured array of all product data and caching it in a variable or reading that from memory. if (empty($this->facts)) { $this->encodeFacts(); } else { $this->factsAy = Arrayy::createFromJson($this->facts); } } /** * Product page specific hooks. This method is called from site/init.php from my custom loop * that runs for each frontend template based page. * if (in_array($templateName, config()->noneFrontendTemplates)) { * if ($templateName === "user") call_user_func_array("{$namespace}{$className}::initiate", []); // UserPage needs special treatment. * continue; * } * if (class_exists($namespace . $className)) call_user_func_array("{$namespace}{$className}::initiate", []); // Page classes register hooks in their initiate() method this way. */ public static function initiate() { parent::initiate(); wire()->addHookBefore("Pages::saveReady(template=product)", function ($event) { ... more hooks go here ....

I'd love to see an "officially supported and recommended (and even documented) way" of initializing custom page class objects, discussed and requested by us over the years: https://github.com/processwire/processwire-requests/issues/456 https://processwire.com/talk/topic/30138-page-classes-diving-into-one-of-processwires-best-features/?do=findComment&comment=242737 https://processwire.com/talk/topic/25342-custom-classes-for-page-objects-the-discussion/

How to initialize a "custom page" object has also been discussed here before: https://processwire.com/talk/topic/25342-custom-classes-for-page-objects-the-discussion/ and is also discussed in this request at Github: https://github.com/processwire/processwire-requests/issues/456 I'd love to see an "officially supported and recommended way" of doing this.

Sure, I also do that ? Thanks a 1000000 for sharing one of your modules again!