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!

Important to note that that module is no longer being maintained in favor of its commercial follow-up: https://processwire.com/store/login-register-pro/ Note that Ryan's modules are worth their price, and they are also secure. One can save a significant amount of time and receive quality support for the price. Compared to almost all other PHP CMS/CMF options out there, ProcessWire requires the least amount of time and effort when upgrading the system and its modules. You can keep a ProcessWire site online "forever" without the fear of it not being updated. The only driving force to update a ProcessWire site that is running fine is to keep up with PHP deprecations. Other than that, there are no maintenance tasks to perform if you are okay with a particular ProcessWire site. By purchasing the most important modules from Ryan (modules most important to you), you also support the continuous development of the system. At least that's how I look at it ?

My recommendations for those who might be wondering...: I can also recommend even the free and public content of this site: https://refactoring.guru/design-patterns/php And if you have an actual task to solve, ask chat ChatGTP 4+ what it can recommend. And always ask it for more design pattern "ideas" since the random first one it recommends might not be the one that solves a particular problem best. After you have discovered the possibilities then sites like refactoring.guru and others can help with concrete implementation examples.

@ryan That sounds promising, quote: TinyMCE for Open Source We recognize that the GPL may not align with the needs of certain free and open source (FOSS) projects. In response, we are introducing the TinyMCE for Open Source program that will provide a custom license to qualified open-source projects. This custom license will permit the use of TinyMCE 7+ in open-source projects with a license that is incompatible with GPLv2+. To apply for the Tiny for Open Source Program, please fill out and submit an application "there".

I wonder what you exactly mean by that...

Just a wild guess, but did you also try it with a different PHP version? Newer or older main PHP version?

Perhaps it's not that it "does not get assigned" at all, but rather that it isn't assigned when your code expects it to be, because it hasn't been assigned yet?

I see, thanks for clarifying.

Hello Ivan, What do you mean by that? See: https://nativephp.com/docs/1/digging-deeper/databases

https://nativephp.com/docs/1/getting-started/introduction "NativePHP is not a GUI framework. We don't want to tell you how to build your app. You can choose whatever UI toolset makes you and your team feel most productive." "#What's in the box? NativePHP comes with a bunch of useful features out of the box, including: Window management Menu management File management Database support (SQLite) Native notifications" What can I build with NativePHP? Honestly, anything you want. The only limit is your imagination. Now for building Windows apps too: https://github.com/orgs/NativePHP/discussions/278

I would put it over here, on its on page: https://processwire.com/docs/start/install/ I put it on my todo list but I cannot promise anything as I hardly have free time these days.