wbmnfktr

I'd say so.

Content-wise... a great update, as I am not that often around here right now. The moment my latest projects are done, or at least in review, or... short before release I will drop you a message as RockPageBuilder sounds interesting. But right before that I have to try RockMigrations and RepeaterMatrix support - as those are spread around so many projects of mine. ? Besides that... there is one thing you could look into right now: Screenshot: Thunderbird 115.3.1 (Linux) Readability. It's quite hard to read due to those tight line-heights, and maybe the foreground/background contrast could be smoother. Yet, line-height is an real issue for me here. I wanted to read it, so I did. Otherwise I'd probably just ignored the mail (if it wasn't from you). Oh... and you better send a newsletter the moment your new website is ready!

That's so sad and bad at the same time. ? I will do so... I'll let you know on Saturday/Sunday (the day after tomorrow, and the day after that...!

First: define the matching /name/ for each language in your homepage Second: Go to Modules > Core > Languages Support - Page Names > Settings and define the behaviour This way the homepage will redirect to your specified default language /name/ if set. It won't redirect from /nl/ or /es/ back to the default one. In case you want to switch to another language as the default one - take a look here: Change homepage's default language

I have to play with it after all these years. Kinda feels like home. Textile was awesome back then.

Just another way to migrate a full install... either via exporting the site profile or while using Duplicator. Maybe you should try that instead. Those manual migrations... I did this for a very long time, yet I always missed something and had to look for the issue for quite some time.

Wasn't that the goal? I'm confused right now. Or maybe worked too little with frontend editing.

Does pasting it with Option + Cmd + Shift + V (Mac) / Ctrl + Shift + V (Windows) helps here?

The big yellow one? Oh yeah!

I loved Textpattern so much!

So... I use Devicon for quite a few things across projects and today I looked up ProcessWire... without success. Yes, I was suprised in some kind. See here: https://devicon.dev/ It's possible to request an icon to be added - see here: https://github.com/devicons/devicon/wiki/Requesting-an-Icon (Issues: https://github.com/devicons/devicon/issues/new/choose) Who is able to offer, provide, and/or upload the official files with the correct colors and settings? The whole topic isn't super critical for me, but it would be another way to show ProcessWire is serious.

No judgement in regards to WordPress, just an interesting article. https://make.wordpress.org/core/2023/09/19/analyzing-the-core-web-vitals-performance-impact-of-wordpress-6-3-in-the-field/

Actually found the time to use a VPN to inspect that site (ProtonVPN, and TunnelBear VPN work great) now, and... I already have a complaint to file. While the site overall seems perfectly fine, the header slider is super bad in my opinion. Those topics seem quite important to possible website visitors, maybe even the only reason to look that site up, and those topics are somewhat hidden, while they could be a major navigational point/entry on the homepage or maybe even every page. I'm not sure if this is the case but they sound quite important to me, and shouldn't be hidden in an element that doesn't even indicate it's a multi-topic/multi-element slider. On the other hand it does seem to be super straight forward to get the things done. I'm not sure what's exactly happening at each and every part of that site but compared to our german sites... few steps ahead. At least compared my village (yes, only ~280 people around here) we still can't do things online. Besides complaining online forms don't work. Jokes aside. I am not a designer and therefore really enjoy a functional website that does what it should. Therefore great work in most parts. At least for what I can tell.

I don't want to hijack this topic too much, yet I have to ask. Is unpoly worth the ~50kb? Even combined are AlpineJS and HTMX less than that. And there would still be a place for BarbaJS. I use AlpineJS in bigger projects that have quite some heavy lifting in terms of JS-needs and are more than just a simple website. HTMX looks pretty fantastic, yet I didn't build more than a few simple proof-of-concept projects with it for now. Which is sad. Smaller projects get the VanillaJS-treatment and JS is down to less than 5kb. unpoly looks super interesting but the ~50kb are such a bummer. That's more than the average page size without images.

That's why Softaculous announced a new version in their installer. Until this moment I thought they'd support the DEV versions now and was totally thrilled... but ok. I'm totally for it. That signals ProcessWire is alive and well (see the Softaculous post above) and people can see it. To be honest here: we all should push way more details about your and the overall work on and the features of ProcessWire to the outside world. But that's another topic for another day. Have a great weekend, @ryan!

Wow... that's fascinating in some way as I just made my move back to good old ProcessWire with some nice additional extras. Like TailwindCSS and AlpineJS - HTMX is on the list - but that's it. So, yeah... still some Node.js and build scripts involved but that's fine for me. I even moved some small sideprojects from 11ty and Astro back to ProcessWire just because it's way more solid, real, or something like that. Can't describe it. Weird I enjoy ProcessWire right now way more than 12 months ago just by using totally different tools for a few months.

I have had the very exact thoughts about this for quite some time. What are your reasons here, beside super heavy JS-frontends (React, Preact, Nuxt, Next,...)?

I played around and worked a lot with Astro in the last few months, and one thing I really liked was working with <Components />. Right now I try to move my experience from it towards my PW/Twig/Latte setup. Some parts work pretty well, while some things don't work out as expected. Splitting parts isn't that easy in PW, when using PW and Tailwind. Due to the missing build-step. But ok. I can live with it. When using plain CSS, this could be a totally different thing. Yet the CSS and JS isn't scoped. Boooh! I didn't use plain CSS for about 18 months now - which is wild, as I was a plain-CSS-advocate since always. But I am working on it again, which feels super awkward on its own right now, as PW is totally different compared to Astro or the tools I used in the last months. I could imagine using <Components /> in one way or another using Twig/Latte and some ProCache-magic... I could minimize CSS way more, yet I don't know if all that is really necessary. For what I can tell right now... each release with PW and JS/CSS is way bigger than in Astro, as PW has no real page-based build-step. That's fine for me, as most of my projects are super minimal right from the start and get 4x 100 in Google Pagespeed. To be really honest... I am at a point right now in which I really don't care about the last 100-500ms in a pagespeed tool anymore when I at leat get the 94 scores for each step. Addional note: Right now I work on a 11ty/Astro setup that loads all data, pages, and structure from PW in JSON-format. Loading all data (from https://www.restaurants-neumuenster.de/) takes about 1-2 seconds in total while building all pages, data entries, and everything else takes another 3-5 seconds. It works, yet I don't like the result somehow. There are things I really don't like and have to fix in JS/Nunjucks/Liquid or some other parts of the setup. Right now: I focus really on optimized PW Twig/Latte workflows and for minimals sites using JSON using 11ty/Astro as frontend layer.

So much fun stuff to play with...

So... Randy just announced a new VS Code extension to manage DDEV instances. https://marketplace.visualstudio.com/items?itemName=biati.ddev-manager

Please check that you have all the basic HTML tags, including closing tags. Most of the time this kind of issue appears when there are missing </body> or </html> tags. ProCache looks for some pointers in your pages to find the start and end of a page to know which parts it needs to handle in which way. So make sure all basic HTML tags from opening to closing tags exist in your template. html head body If that doesn't help and as you can't share the site itself, maybe you could copy the source code of one of those pages, clean it up, and make it available for us to take a look.

Nice presentation here. As always. I was kind of suprised to see so little feedback or knowledge about DDEV, MAMP, and Laragon. What were they using? Real servers in a local network? Either way... The interview was a great surprise. He seems to be a great guy with lots of knowledge in every space someone could imagine.

Ok. Now this makes kind of sense to me. It's not about the composer packages in ProcessWire I deal with once in a while in a project, but with those I (never will) develop for later use. This seems to be quite a lot of work for, what I would call it, a simple task like that. But ok, I don't know anything about developing composer packages - that has to be said. Thanks for that detailed answer and background on this. At least I can relax now and know I didn't break a few projects because I used composer packages in a wrong way or something.

Woah... (positive and surprised emphasis here) The graph I posted above made it super easy for me to understand differences in loading JS while the one you mentioned... did the absolute opposite. It did almost nothing for me on first look to understand anything. I have to read, have to compare, this, and that... which isn't that of a problem but for a quick first look while trying to understand. NOPE. Sure, the one from your example explains a lot more (which is great), talks about differences, and you learn way more yet ... just looking at it doesn't work for me, what the other one does. Sometimes I just need a good visual hint that explains a more or less complex situation, which mine did (for me at least). That was the reason I posted it here. So we are quite different in consuming such information, and that's super interesting.

@elabx what's the reason behind the setup you describe here? I probably missed a lot or just don't understand it what's in previous parts of this discussion. You mentioned this: So... as far as I can understand this - combined with the rest - it's something more or less outside of the usual ProcessWire realm aka developing/working on a composer package. Am I right with this? I am just wondering if I missed something in regards of handling composer packages in ProcessWire and DDEV while working on a project.