wbmnfktr

That's true. The added description and details help a lot. When I looked into this thread there wasn't that much happening. A short intro and a link... which didn't help that much.

Checkout for what? Checkout with which providers? Checkout with which framework? What is your module doing? Don't get me wrong but... a bit more details would be nice. Maybe adding your README here would be a great start. Is this based on Shopify, Snipcart, Foxy or plain ProcessWire? I'd like to play with your module. Easy one-click-solutions are always nice, but... details and some kind of introduction would be really nice. Update: Details were added.

When you search for getSubmitActions you will find some thread talking about adding and removing buttons. At some places you can see how titles/labels of those buttons were set. As a starting point: Maybe that helps? https://processwire.com/talk/search/?&q=getSubmitActions&quick=1&search_and_or=or&sortby=relevancy

Woah... there are a lot of moving parts here. First of all: It always takes way longer than anyone expected it would take. I have seen super simple and minimal projects taking weeks instead of days. Yet I've seen quite large and complex projects that took only a few weeks instead of months. In average the PHP/PW part is most of the time the smallest part within a project that's just dealing with content at least in my projects. It can be tricky when you have to deal with lots of data from different sources, especially when you do more than just displaying that data. Most time and energy in my projects go into: Planning out the whole project Designing each and every bit Content audit, creation, and optimisation Frontendwork HTML, CSS, JS Right after that ProcessWire comes into play with these parts: Templates and fields Site structure, setting up basic pages Modules and global settings Backend logic, data automation, cron/lazycron jobs, automated maintenance On average I'd say it's a 70/30 ratio between those two. To get you some numbers here: We talk about at least a few weeks and maybe even months in total with all kinds of related things like meetings, phone calls, organizing, setting up Google and other tools, like tracking tools, newsletter, etc. To make things clear and a bit more transparent, we talk about projects and websites like these: https://www.restaurant-blechnapf.de/ https://www.klippo-nms.de/ https://www.musikschule-neumuenster.de/ In comparison to the above there are projects I built in my spare time without a lot of planning or almost anything - which took a few hours or maybe two days in total. Like these: https://www.jet-fire.de/ https://www.voss-friseure.de/ The main difference is that the first 3 projects are totally custom and fully optimized, multiple user accounts, access rights, automation and maintenance and design-wise on a totally different level. While the last two use UIKIT or Bootstrap, just display simple content and aren't that well optimized to be honest. Last but not least there are projects like this: https://www.restaurants-neumuenster.de/ It started with a simple splash page, a simlpe form and a bit of content and went online within a few hours. Yet as of today there are several hundred hours of work in it. Quite a bit design (had a few relaunches in the past) but way more in terms of data processing, automation, newsletters and lot's of nice things. TL;DR From about 2 days to a couple of months.

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 }