wbmnfktr

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

No. Not right now. Everything works but that part is missing.

More than a year ago I said I would try TailwindCSS... now it finally happened and... and the result is disastrous! Well... disastrous for my opinion back then and my thoughts about it until a few weeks back. I am quite surprised and happy with the result, to be honest. I did a rebuild of an ongoing side-project, with a full rebuild of the whole site structure all the way through to any breakpoints (CSS only, HTML was kept except additional classes). Yet some parts are still outside of TailwindCSS as those are really custom and are way better placed in an additional CSS file. Even though you can customize TailwindCSS to almost all of your needs but I didn't want to bother with it for now. The change in file size is quite dramatic... or even super awesome. However you want to see it. I went from... 59kb (the whole project) down to 17kb (structure - based on TailwindCSS CLI generated .css file) PLUS 5kb custom CSS for colors, custom properties PLUS 10kb custom CSS for icons, backgrounds, and fonts PLUS unknown size of additional kb within HTML due to those TailwindCSS classes Ignore those other files as those are helpers or part of other instances within that setup. Which is in total: 32kb for the full project, all pages, all icons, all fonts. Yet... the whole setup isn't ready for production right now as my setup only really works with 11ty as a middle-man for now and not within my PW workflows... but that's another story. There are probably even more things I could optimise in terms of fonts, icons and custom classes for colors. But for now... WOW... I always was against those utility frameworks and didn't like them at all. I am and always was a VanillaCSS Purist... didn't ever really like Bootstrap, UIKIT or anything like that, but TailwindCSS could and might have changed my mind. From now on... I might have to think and work different for some or another reason. Right now my test was built on a project I really knew in and out with all its details. Let's see how it works out in a real and new project. Results based on: TailwindCSS 3.1.2 (latest - as of now, 2022-06-14. all file sizes unzipped, without plugins like Typography)

My latest and most recent experience with JS was AlpineJS. Never heard of Yoast JS so far and asking Google doesn't help that much for now.

This would be awesome!

Excellent!

Well... yes. It does exactly that. If I understand your statement correct. Changing things in the backend and viewing all those changes happening in realtime in the frontend. That works perfectly fine. At least for content. I use this in a side project and each and every editor is super happy. In terms of code changes (templates)... it wouldn't do the trick.

The backend really looks amazing! Really a nice job. Yet... I somehow experienced a quite slow experience on-site. And I doublechecked. Somehow the site underperforms in terms of PW. For whatever reason. web.dev/measure and ScreamingFrog result in a ... not so great experience but I can't point my finger on it. Some routes seem unnecessary for me but those are some-what understandable. Is the hosting in one way or another maybe not that perfect?

So... maybe ask them what they would like to use or recommend in first place and go from there. Depending on the setup you could also look into environment variables which sit in places far away from any web root. Another thing could be a mail account which is only used for that website. Or you use something like Mailgun, Mailjet or similar which is a 3rd party service and therefore all details sit on yet another server. I personally use Mailjet which is configured in a way that only my website can send mails through that account, still everything via SMTP. So... even if someone can get a copy of my credentials they still would need access to the server or the Mailjet account to do anything with it.

Something like this?