Leaderboard

I don't know when I last found a tool for my daily work that had such a huge impact as Latte. The last one was ProcessWire I guess (which had an even greater impact of course, but still). Latte uses PHP syntax so you don't have to learn a new language! It plays extremely well with the PW API and it makes my markup files so much cleaner and easier to read and maintain I can't tell you. From time to time I stumble over situations where I'm once more impressed by latte, so this thread is intended to collect small latte snippets to show how one can use it. If you want use Latte for your ProcessWire projects you can either install it via composer or you wait some more days until I release RockFrontend - a frontend module that can render latte files and comes with several other nice frontend helpers ? ----- Breadcrumbs the Latte+PW way: <ul> <li n:foreach="$page->parents()->add($page) as $item"> <a href="{$item->url}" n:tag-if="$item->id != $page->id"> {$item->title} </a> </li> </ul> The cool thing here is that the last item (the page we are currently viewing) is NOT linked. The <a> tag is only rendered for all other items. Still the label of the link is rendered, because we are using n:tag-if and not n:if ----- Output an image, but only if it exists: <img n:if="{$page->yourimage}" src="{$page->yourimage->maxSize(400,300)->url}" alt="..."> Note that the ->maxSize() call will NOT throw an error even if you didn't upload an image! This is one of my favourite features of latte: Write the markup once and then add simple instructions directly within that tag. No more if/else/foreach chaos ?

I just wanted to mention that I hope that our new editor will still be a rich text editor and not a page builder (like the mentioned "article" editor) - imho we should not mix those two! I've done a lot of work and research in that regard over the last two years or so and I'm now very happy with my repeater based content builder. When I started I also looked at editor.js as the interface looked neat. But I couldn't even manage to build a single custom content element with it. It's an editor for JS artisans and not for PHP devs like me (us?). A repeater based content builder has the huge benefit that we can simply use all the existing fields that PW provides. If at some point someone created a new field that would most likely just work within a repeater. Having a new editor interface with a totally new storage concept would mean we'd need to build all those block's for the editor and we could not use them outside of it. What about Multi-Language? The example above shows a nice page builder, but I wonder how multi-language would work with such a field? In a repeater-based setup we can just install LanguageSupport and make those fields translatable. PS: Using a matrix based approach makes CKEditor fields usually super simple! Like this one where only bold text and links are allowed:

This is why I always prefer the inline mode for CKEditor: very little is done until needed, which speeds things up nicely, yet setting up a new RTE field (when it is needed) takes maybe a few hundred milliseconds (assuming scripts and/or styles need to be loaded, otherwise it's nearly instantaneous). No matter how you do it, adding elements to DOM tends to slow things down. The more you add, slower things get. That is why Ajax loading is great for things that are needed rarely, while things that are needed most of the time can and should be loaded right away ?

I like repeaters for structuring data. For building a layout, not so much. I've seen the demo's on this forum of people using repeaters in creative ways to build a layout, but it never looks very intuitive to me. I've grown to dislike this approach so I've been looking at other content management systems for inspiration. Bolt CMS uses Article Editor, which is a nice (paid) javascript solution that's basically an advanced wysiwyg editor with support for grids and other nice features. I decided to integrate this into Processwire as an inputfield. Here's a demo: I created a few plugins for Article Editor that take care of uploaded images, inserting links and Hanna code support for adding dynamic bits to the editor. And the field also works in repeaters. You can pass your CSS to the editor so that the editor preview should look identical to the real page. I am using Bootstrap. A bonus of building a page this way is that the whole layout is stored in a single field so there should be fewer requests to the database compared to repeaters. Please note that since Article Editor is not free, you need a license to use it. I've been working on this module on and off for a while. There are refinements to be made, like perhaps loading the Hanna code previews dynamically (they are currently inserted into the editor after saving the page). Not sure if it would be good enough to release publicly but I thought I'd share it anyway because I'd like to hear if you think this is a nice approach :)

Just a little rant: Please don't turn our textarea/RTF-fields into something like Gutenberg or similar. As a module, ok. But please... not as the default option. I'm not that deep into all the details about those RTF-Editor tools/scripts but what's so bad about staying with CKEditor 4.x for a while as it's stable and mature enough. Never had any issues with it.

I'll mention Quill: https://quilljs.com/

Article looks great, but their licensing model is indeed problematic. Folks at Bolt likely got a custom license (or perhaps paid OEM license) to use it, but on what terms is hard to say — I couldn't find specifics about their licensing terms. Only thing they do say is that it's available for use "in Bolt itself", which is a bit vague. It's up to Ryan whether he finds this interesting enough to contact Imperavi and query about license ? Either way, I wouldn't count CKEditor 5 out of the race quite yet. To me personally it looks UI/UX wise like a solid upgrade over CKEditor 4. I do remember that it seemed potentially "too different", and there were some relatively basic features (which I can't for the life of me remember anymore) from v4 that the devs originally said would be very difficult or nearly impossible to implement in v5, but that was a long time ago so perhaps things have changed. First of all, CKEditor 4 being EOL'd in 2023 is a huge reason to move on. There's no guarantee of updates after the EOL date, which includes potential security updates. ProcessWire is relatively safe since most of the time CKEditor is used by trusted users, but there are cases where that isn't necessarily true. And even if it was, there could still be vulnerabilities that third parties can abuse. In my opinion it's painfully obvious that we must drop CKEditor 4 support from the core at some point in the future. If some prefer to keep using EOL'd software (which I would personally recommend against), there's always the possibility of stripping it from the core and converting into a separate, possibly community-supported module. For me personally CKEditor 5 seems like a logical next step, but admittedly I've not used it enough to know if it's really going to be feasible, let alone how much work it will require. It's a good idea to check out what else there is, but CKEditor has quite a few things going for it as well: plenty of features, solid UI/UX, longevity of the project, active community, being open source with no costs or limiting licensing rules, etc. As for ease of use, I absolutely agree that this is vital. And in this regard CKEditor 5 feels like a big step up — if anything it feels less confusing and more streamlined than earlier versions. I would not expect my/our clients to have any trouble with it. Give it a try and see for yourself, and do keep in mind that CKEditor 5 is configurable: features you don't need can be disabled ? Just my two cents. 100%.

Another example of creating fields/templates during module install: https://github.com/apeisa/Discussions/blob/master/Discussions.module#L280. That code is 10+ years old and a bit verbose, but that's exactly why it's (in my opinion) a good example. No abstraction layers, no potentially confusing shortcuts, etc. ?

The questions you are asking need a lot of experience and/or testing. It always depends on the specific use case or environment. In general plain DB tables are better for performance, but have the drawback that you can't directly edit them via GUI. Also querying might be a little more complicated than what we get from PW pages and PW api. PW pages on the other hand have the benefit of having a GUI built in and making it easy to manipulate data via API, use hooks, use PW fields (eg for storing images) etc.; Basically all the PW magic. The drawback is that they have a bigger footprint. The need more memory, they might not be as efficient as direct DB queries, etc.. That's one of the reasons why I built RockMigrations. You can do all that using the PW api and you'll find several examples for that. For example the blog module does it like this: https://github.com/kongondo/Blog/blob/a13af302af9e6ce1bcbbe623a36b8efc1a033763/BlogInstallWizard.php#L352 As you can see those things can quickly get complex... RockMigrations abstracts that logic and can be used to help you built modules that create fields, templates, pages etc... <?php $rm->migrate([ 'fields' => [ 'field1' => ..., // create field1 'field2' => ..., // create field2 ], 'templates' => [ 'blog' => [ // define fields of blog template 'fields' => [ 'title', 'field1', 'field2', ], ], ], ]);

Besides being able to format docs easily and without too much confusion, the editor should be as "lightweight" as possible, JavaScript-wise. I mean that PW should be able to load a lot of editors into – for example – repeaters without ajax loading. Ajax loading should be a last resort option, let's say when more than 50 / 100 (perhaps?) editors must be loaded by a page.

I personally enjoy Twig as it's similar to Nunjucks / Liquid which is my goto choice in 11ty. Yet it somehow doesn't feel right for me in ProcessWire for whatever reason and therefore Twig never made it into any project so far. Maybe some day. Had this recently in some kind with TailwindCSS and AlpineJS. Both made work way faster for me. Not only in prototypes and playgrounds.

That template engine is great, in my beginnings with Processwire I was testing with this excellent module developed by @tpr it's very complete, with many additions and filters to extend it. But I finally ended up using Markup Regions when it came out around the same time. I wasn't that ready yet for that "advanced" PHP. I'll keep an eye on your module, maybe I'll try again with Latte ?

@kongondo Thanks a lot ! I'm gonna look at that !

@kongondo Thanks a lot !!

Thanks Bernhard!!! Never heard about that - I will dive into it ?

https://processwire.com/blog/posts/pw-3.0.173/ ?

A custom 404 page is way easier to achieve than this way. So first of all undo all changes in .htaccess and your Apache conf. Here is your solution: place your custom template in /site/templates/ go to Setup > Templates and add your new custom404.php edit your 404 page under Pages and go to the Settings tab change the template to custom404.php That should do the trick already.

This has attractions. But it would require PW to update the file path every time the page was moved or renamed - there would be other complications too - e.g. including an image in a RTE field in another page would mean that the html would need to be updated when the host page is moved/renamed. It might be possible to test out the idea using hooks, but my guess is that it would cause more problems than it solves. The method I use in DbMigrate is to do all the referencing in the generation of the migration using the path/name rather than the id and then using that to get the corrrect id for the files. For RTE fields, an id map is maintained $idMapArray[$page->meta('origId')] = $page->id; so that the html can be changed. This only needs to be done for a migration, not every time a page gets moved. So I think, on balance, my vote is to keep the id-based naming.

Then the user is your own module. All the points in my post above still apply – your module has to make some assumptions about the structure of the JSON data. Even if the data is only consumed internally, passing unstructred data around can cause unexpected errors at any point. So it's still better to parse the data into a representation that makes guarantees a specific data structure, and raise errors during parsing (as opposed to a random error anywhere in your module's lifecycle that's hard to track down). Also, will your module not allow customization through, for example, custom page builder elements or hooks? As soon as that's the case, developers using your module will have to use your data, so it should provide a uniform interface to accessing that data. Basically, any ProcessWire class representing some sort of collection, so you can check out those. For example, check out Pagefiles, FieldsArray and PageArray which all extend WireArray. See how they make use of all the utility methods WireArray provides and override just the methods they need to customize to adapt the WireArray to a specific type of data? For example, check out FieldsArray::isValidKey only allows Field objects to be added to it, so adding anything else will immediately throw an error. You can use this to map your pagebuilder items to a specific class and then have a class like PageBuilderItems extending WireArray that only accepts this class as items. This will go a long way towards having a uniform data structure. Again, don't mix up storage and representation. For storage, I would prefer the second example you posted, with items being an array instead of a map and the ID being just a regular property. Simply because arrays are more convenient to create, parse and map (in JS especially, but also in PHP). Though again, it doesn't matter as soon as you parse the data. The representation your module (or others, see above) uses to access the data can provide utility methods, like accessing an item by key. Regarding the last point specifically, WireArray can help you with this. The documentation is kind of handwaivy about how WireArrays handle item keys – WireArray::add doesn't take the key as an argument, but WireArray::get allows you to get an item by key, so where does the key come from? If you check the source code, turns out WireArray automatically infers a key based on the item – see WireArray::getItemKey. Your custom class can extend this to use the ID property of a given item as the key. For example, FieldsArray::getItemKey does exactly this. This allows you to use page IDs to access items without having to store your data specifically as a map. On top of that, you can use all the other utility methods WireArray provides to access elements in the any way you like.

This is interesting - it might be the MySQL version, but it might also be the MySQL ONLY_FULL_GROUP_BY setting. ProcessWire requires that is removed, but it only gets removed for 5.7.0+ https://github.com/processwire/processwire/blob/3fc9f69da75e1bc4a3f0842f12a57bd6a1b65099/wire/config.php#L897 If you add this to your config.php it might just work: $config->dbSqlModes = array( "5.0" => "remove:STRICT_TRANS_TABLES,ONLY_FULL_GROUP_BY" ); That said, I would definitely get an upgrade to MySQL because there could be other issues with that version as well.

That's not what I meant. In the Processwire admin panel, you can choose the default value for Integer fields. How can I have the same option for Checkbox fields? For checkbox fields, there is no "Default value" option under the Input tab.