Ivan Gretsky

Do you have such an experience, @clsource? Can you elaborate on this?

Look for Padloper.

Welcome back, @blad! You know how to make an appearance - with a brand new amazing module)) There is a similar module, but it uses other file manager library (which is more php than js in contrast to elFinder). How do you see elFinder in comparison to it?

Please post all .gitignore contents so we can guess better.

Recently Bitrix (a popular commercial CMS here in Russia, known worldwide for its Bitrix24 CRM/PM/... solution) introduced similar functionality they called Site Constructor. This thing allows to build pages or parts of the pages from pre-defined blocks which can be static or dynamic. Site developer can style, modify or add their own blocks. They recommend this for landing pages for now, but are aiming to move all content management to those blocks. So there is some trend. I actually do use (almost) the same approach in PW. Most of my pages have content-page template with content_blocks Repeater Matrix field holding most of the content in repeater items. What is missing in my solution is: the easy ability to restrict the order, allowed types of those items (though possible with this module); the ability to easily move/duplicate content blocks from project to project (still think Repeater Matrix should be PageTable Matrix); the ability to easily preview the page built (like with this solution) in admin / edit it inline on the frontend. I see this way of building content very flexible, but still somehow unfinished. We have all the parts in PW to build a full-blown page bulder that will not allow too much for ones that do not need it, but will make it easy to build something really complex and interesting without programming. But those parts are not yet combined in a polished solution. I would certainly like to have it in PW (as a PageTable-like PageBuilder FieldType/Inputfield combo, probably).

Can't reproduce here: Addin' id attribute does not ass any redness either.

Just came here to say that this stuff rocks, @Robin S and @adrian! And looks so awesome in the new admin theme. I know it's nothing really special (for a person spoiled by using PW for a long time), just an import with a UI... But it feels like magic and even cheating)) The new way to add actions to Admin Actions module - a super feature - just a byproduct of this...??!! ?

Yep! Here it is! I linked to the very beginning of the blog where all the tasty bits are (all the newer pages are filled with ProcessWire Weekly issues, which are still available on a dedicated site). If you want to read something [dated, but still very] interesting about ProcesWire nuts and bolts, this is the place for you!

Today I needed to get back to PW page rendering diagram that once was on this site. And found the site totally gone) There was a couple of inspiring articles there like the one I was looking for. Are they totally gone too @teppo? ?

I guess testing in different environments is the major benefit exactly for module development (not so much for sites where you control the env).

I prefer laradock for its popularity and support. And run and monitor everything from command line (you should too since you're on Linux anyway). For VS Code language server I use locally installed php from standard repository like @fbg13 suggested. P.S. Docker based solutions make it really easy to switch php/mysql/anything really versions in seconds and let you easilly try things you never expected you would other ways, so do give it one more try)))

I have been using Mint for 2 years already on my home desktop and would certainly recommend it to anyone switching from Windows. It has a lot of proprietary drivers included and is based on Ubuntu, which makes looking for answers easy. P.S. I use Cinnamon edition.

Maybe setting correct locale in config will do?

There is a specific type of modules in PW called Text Formatters for doing just that. They parse text field contents before they get output and can change things based on regular expressions. Just make a new text formatter module based on something simple like this and adjust it to your needs. You probably could change the initial behaviour somehow too if this solution does not work out.

Very interesting topic. I surely can relate to the thing that the new CKEditor 5 seems weird for those used to work mostly with html and DOM (like myself). But I can see that it is very much in line with content editing principles @ryan initially put in ProcessWire. By default we can't put too much raw html and especially js in CKEditor fields. This stuff all gets striped out if you do not take time to configure otherwise (and this configuration is not that easy if not just simply turning everything off). So it might be CKEditor 5 is the best choice for content editing as defined by PW by default. And it can be configured even easier (by those who know how to). The main problem I can see is that there may be lack of developer's experience to get it all right for PW, as most of us here seem not to be easy with modern js development workflow.

Thanks for your work on docs, @ryan! Actually your way of presenting and explaining things is as an important feature of ProcessWire as its beloved API. I remember being "hooked" after watching that gentle introductory video, way before I understood anything (could not find it to link here, is it gone?) Nowadays forum newcomers do not get much direct response from you (except for pro boards - and that is another reason to buy Pro modules ?), so probably even do not know about your way of turning answers to simple questions to profound mini-tutorials, often with some philosophical background. And that makes this documentation updated by you even more meaningful (Luckily those forum gurus that handle most of the never-ending questions are still inspired and hold the spirit of wise goodwill that make this place so great to be at). And those connections between established documentation and the constantly updating blog you wrote about are not only the new way to obtain more knowledge, but also a way to show the power of ProcessWire Page field in action on a site that should be an outstanding example of the system. The only thing i wish would happen but not yet happening is a community collaboration on creating, updating, linking the contents of the site, as well as designing and building it. You did say that the latter is about to happen, we do not discuss the former too much. So I suggest we think about the means by which the community can help you better in maintaining the docs and updating them gradually, so they are always up to date. These times most collaborative documentation is written under some kind of source control systems like git and afterwards presented with static site generators. I doubt this is a good way to go for a CMS project like PW (we should be eating our own dog food). But maybe we could use a mechanism of keeping contents in github and importing it to PW docs site when it is upgraded? Like the one use in ProcessWire Recipies website? That way we could help. And that is probably one of the best way to make happen the docs translation you talked about in the last post. Do you think we should explore this, or maybe you have something more profound already planned?

Browsing this new Pundits' site a came across this little blog. Although it was spotted before by @diogo, I thought it might be a good idea to link it here, as it has a couple of PW cases described and seems to be made with PW itself.

I am sure it is something useful not only in my case, but for Tracy usage in general. I'll be glad to at least test it if not switch to it for that dev/prod PW project if it will be implemented. I am pretty sure I never sent emails on init events.

Going back to the original question, here are a couple of ways to get rid of too much pages. You could use URL segments instead of a page hierarchy to route requests to your REST class (hope I am using the right words)))) You could install some 3rd party router (maybe even laravel's own) via composer, include it the root api template and use it to route requests to your REST class. You could use GraphQL instead of REST.

Yep, that's probably it.

One more offtop question here, @adrian. Is it possible to set Tracy mail interceptor option programmatically as part of environment config?

Will this method work everywhere, @adrian ? I mean sending emails from hooks and scripts bootstraping PW initiated via cron? I really can't allow to accidentally send a few letters))

Here it is, @adrian. Not in the modules directory, unsupported, and does not work without some minor modifications with recent WireMail versions, but serves me well for quite a while. Thanks, @LostKobrakai!

Thanks, @horst. That was about what I was thinking. But my desire was to use predefined WireMail instance as a lot of code already relies on it. As I can guess from your answer there is no way to be sure which of the installed WireMail modules will be used in $mail API variable... Or is there? I am asking again thinking about the other use case I am keeping in mind. I am using your wonderful WireMailSmtp for production, but switch to @LostKobrakai's WireMail Testing in dev. So I wish I could have both installed and use one of them for $mail depending on some $env variable. Is there a way to do it?

Good day! I need to use 2 different modules which extend WireMail in the same script (WireMailSmtp and WireMail Mailgun). How do I do it?