szabesz

Welcome to the Forum! In addition to what @Krlos wrote above, it is always a good idea to install a clean ProcessWire instance on the server you need to migrate to before actually doing the migration. This way, you can take note of any possible issues or requirements that arise during the installation process. You can save the clean instance's config file or simply save all the files and the database for further reference. Next, you can remove the installed instance by deleting all files and clearing the database, and then proceed to migrate the site you need.

Currently, I am using the paid version of Bito.ai in PHPStorm for chatting and Supermaven free for "coding completion." They work well side by side. Bito's GUI and the generated results are quite impressive (as they include clear explanations of what was suggested and why, as well as the assumptions made by the AI engine (also known as LLM)). Even Bito's web account features are nice and informative. Bito indexes the whole codebase and one only needs to tell it to use that, but in my prompts I always tell the engine what classes and what methods to deal with (if appropriate, of course). Since it looks up the whole codebase, sometimes it might creatively pick classes/methods form other off topic places but in that case it is usually enough to guide it to back to topic. The only strange thing about Bito is the subscription scheme: a monthly subscription starts at the beginning of the month. Since I subscribed a week ago, I only had to pay for the remaining days of August, which was fine for me, as I did not have to pay for a full month just to test it. @dotnetic Sourcegraph Cody looks cheap, so thanks for the tip! I will test that as well.

Great news, thank you @ryan! For FormBuilder, it will be a nice improvement. Even though it is a nice improvement for template fields and repeaters as well, I think I will still use @Robin S's visual aid: https://processwire.com/modules/template-field-widths/ Which is even faster to work with, as it provides a wireframe look, reducing the need to guess what the final layout will look like.

BookStack: MIT-licensed, easy-to-use, yet feature-rich documentation system with built-in diagrams.net integration. I use it to document everything. https://www.bookstackapp.com/ Kodi TV: Completely free home theater app running from our QNAP NAS. We only watch our own collection; online services are a big no-way in this area... https://kodi.tv/

I have no idea. Some forum members have started Discord channels over the years, but those channels have never been actively used, so I just quit. Also, keeping Discord (or any other app like that) open all the time is a big time killer that prevents me from focusing on work or anything else, for that matter. The forum's "Live Topics" feature can turn the discussion of an "event" into a separate forum topic (or optionally into separate topics), preserving what was discussed. Chat rooms and similar discussion board solutions cannot be searched nor bookmarked properly and cannot be indexed by search engines either. Maybe I am old school, but a classic forum like this is the best for discussions that provide information to be kept for later reference.

I think "Live Topics" would be nice to have: https://invisioncommunity.com/news/invision-community/introducing-live-topics-r1276/ For example, we could organize monthly "virtual meetups" where each event has a predefined main topic, announced well before the event so that those who have something important to say can prepare in advance. Each event could end with informal conversations about any other topics in mind (where the forum rules should still apply, of course).

I would certainly be interested in that. After all, the developers of TinyMCE need to make a living from it as well, so a well-balanced win-win situation would be welcome.

FYI: @tpr's modules can/should be considered abandoned.

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.

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

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