wbmnfktr

What kind of things are you doing with ProFields Table... I used it once... just for catalogue data entries, that's all. Never really saw any real benefit using that module. Is there something I missed?

You can either use the $sanitizer->truncate() in your template file or set a character limit from within your template settings. For the second option go to: Setup > Templates > Your Template Click on the textarea field (summary) > Switch to Tab: Inputs > Set character limit

In case you want a copy paste version to use RockFrontend with RepeaterMatrix from within a .latte file: {* templateExample.latte *} {foreach $page->repeaterMatrixField as $block} {$rockfrontend->render("fields/repeaterMatrixField/" . $block->type , ["block" => $block])|noescape} {/foreach} {* blockExample.latte *} <div> <h1>{$block->headline}</h1> {$block->body} <img src="{$block->image->url}" alt="{$block->image->description}"> </div>

Oh my... yes, I meant that. And I know why I wrote float at the end. Thanks! (I will update my answer.)

Details/data like vendor, seller, brand or similar could be set as a reference (page reference field). That way your data is super clean and easy to maintain (imagine a seller changes its name and you have to change it 100s of pages compared to one page when using references. This way you can also create individual pages or list for all those data-types - like a list of all brands, sellers, whatever you could imagine. I would create templates for whatever makes sense. Products get the product template, maybe even create different templates for different product types, like books, toys, movies. It depends a bit on what's actually existing in terms of products. Same with other templates. Maybe vendor and sellers are identical with the same details, so you could re-use that template but I'd personally would create separate ones just to have it easier with selectors later on. So you can right away look for vendors and sellers just by template name. That's in the frontend I guess. That's easy. You decide which part is a link, what data is shown and so on. In terms of template... the same. You decide which template is used at what point. What you are looking for is a float decimal field. You can choose this option while creating a field. What's the difference between promo and featured? Is there a voucher available when it's a promo? Either way it might be able to just use a checkbox. But that means you have to manually update all products that aren't a promo/feature anymore. The definition of new could be a checkbox as well or you use the created and/or modified date of a product page.

I personally use ProCache for that but it would still make an awesome feature. Multiple files or one single merged file... in the wrong hands both options can result in a slow loading site. So... yes, no, maybe. It depends.

Tried it again within a fresh ProcessWire instance and the most recent version of RockFrontend from Github. Installs without any issues. Doesn't even mention RockMigration anymore. Thanks! Edit: Another thing pops up now. Opened an issue on Github for it.

So... just made room for playing with RockFrontend and stumbled into this: Not really a deal breaker (the missing requirement) yet that message looks weird and out of place.

Well... in the past I looked up ways to get Twig up and running in ProcessWire and what-else-where and had to look up so many sources, details, guides and whatever that my urge to get it up and running diminished due to each and every step. Eventually I got it up and running, played with it, yet it was never backed from an "official" or at least "experienced" source. So I never trusted my setup. If I ever had a reliable source in the PW-Community that wrote, talked, spoke about it... I might have invested more time. Yet... there was noone. For whatever reason. Sure there were guides on modules, but not in detail. Or at least not for starters or dummies like me. You on the other hand are experienced in Twig, ProcessWire and therefore would have been a "source of truth" in some kind - if I ever would have had the chance to find a guide by you, I probably had way more fun with Twig and a ProcessWire/Twig combo. I don't wanna talk you into writing such a guide on your site or moving this piece of content as it is onto your site, but... even though it might be unpolished, not that detailed as other guides on your site... it would, could, should, might, whatever... drive people into trying it in a much easier way than struggling through lots of posts, tutorials or whatever. Maybe even Twig-users could find ProcessWire as their PHP-framework in this way. Who knows? Sure there might be more details needed but you know those details and could write at least an outlined article on how to get Twig up and running in ProcessWire. (Sure I know you work fulltime in an agency, with Craft CMS, ... ) Yet... you could. You know ProcessWire way better than me, and Twig as well, so... yes... I'd like to follow your guide or tutorial to get this up and running. You don't have to convince for me anything. My curiosity is already there - like it's by most of us here. On the other hand... I understand your feelings and thoughts about "it doesn't match the existing content" but... hell... it doesn't match most of the time. Wherever you look, whatever you write. Some posts are way more detailed while others are just basics. Yet... It helps. Probably. To make it short: Your inital post already convinced more to look into Twig in ProcessWire than any other post around - as it told me it could be used in a professional way. I thought about it in the past but maybe I gave up too early. So yeah... those were my almost last two cents on this topic.

In reference to this... As the mentioned module TemplateEngineFactory. supports Twig as well.

Actually this is a really great starting-point for Twig in ProcessWire. While I still stay with plain PHP in my projects I really like the Twig syntax due to Nunjucks/Liquid in 11ty. Maybe you could update your processwire.dev with this point - as this is a thing some people really look for. Maybe even @bernhard could write a guest-post there with something about latte in plain-vanilla-pw and when it's coming RockFrontend. For myself so far I decided to look more into this after recent projects are done. Especially twig (as I know already the syntax).

That's actually a very good point. And a very nice addition to the usual updates, content and discussions here as well.

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

I'd go step by step just by adding static content aka JS, CSS paths and finally the HTML part. Just to test if it's working as expected. From there I would add the things you already tried. Maybe I can play with it and test it on my own the next days.

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.

The iframe fits very well. As if it was made for umami. They are indeed very similar. I prefer umami as I can host it super easy on either Vercel or Netlify, while using my own database. Another thing I really like is, that I can customize the script name to whatever I want - so blocking extensions won't catch it. Maybe plausible offers the same but as said before... hosting and setup was super easy. You can even get a testdrive up and running via railway.app within minutes.

Even though I never ran into this issue, I'd support something like: /assets/files/path/to/my/page/whatever-image.jpg Which could be used in one or another way, even outside of ProcessWire.

Does work with the umami share code as well. NICE!

<?php namespace ProcessWire; // in event template $galleriesForThisEvent = $pages->find("template=gallery-album, select_event_gallery=$single->id"); if(count($galleriesForThisEvent)>0) { foreach($galleriesForThisEvent as $gallery) { echo "<a href='$gallery->url'>View Gallery</a>"; } }

<?php namespace ProcessWire; // in event template $galleriesForThisEvent = $pages->find("template=gallery-album, select_event_gallery=$page->id"); if(count($galleriesForThisEvent)>0) { // show button/s }

I'd probably do so but my CSS is most of the time optimized and therefor small enough. However you decide now I could imagine someone asking for the exact opposite. So why not both options and the developer can decide in the module settings how to handle those files. There might be a small delay but nothing to worry about - I guess. How many files are needed to boot up ProcessWire? The server already reads a ton of files. But sure... things like WireCache or ProCache would be a good option here. You could throw a whole bunch of framework CSS at your testing page and add UIKIT and Bootstrap CSS and maybe some more files just to test to the extreme. However we think about solutions, problems, and/or use cases for your module... there will be a few that use it totally different and will probably challenge everything. Maybe go first with your preferred or the fastest way, add other options later based on requests and ideas from users.

There have been plenty of discussions and ideas about this very exact topic. Right now... manual field, template and page exports could be a way to go - I don't really like it but it works most of the time. RepeaterMatrix and some other fields are complicated or just can't be moved that way. You have to ship around some obstacles here and there. Maybe just give it a try. Then another viable option could be RockMigrations. It has kind of a steep learning curve but might be the swiss (or austrian in this case) army knife for migrations.

There a pros and cons for each and every possible way you can think of. I personally prefer combining and inlining my CSS to have it right away. In case the amount of CSS is way too much to inline, I only inline critical/base and page specific CSS, while loading CSS for cookie banners or the footer in a separate file. In terms of multiple separate files HTTP/2 allows parallel downloads so there shouldn't be any render blocking issues that throw off your page speed in a dramatic way. At least not with custom CSS. Bootstrap and UIKIT might be a different story. For those with ProCache there is a minify option that allows combining multiple CSS files (only files in the <head>) which is a great way to reduce some overhead. While it depends on how much CSS is generated through your module you might want to run a few tests against https://web.dev/measure/ to check for the best option. At the end of the day we talk about text files that run through Gzip or brotli and shrink way down in size. Well... In case you really want to optimize each and every page down to the bare minimum absolute perfection this would be the way to go. Combining everything into one file would be way more of an overhead. At least in my opinion.

First idea: This way you can change and modify it to your needs. See also: https://github.com/webworkerJoshua/privacywire/blob/master/PrivacyWire.module#L55