wbmnfktr

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.

He has different formats, but yes... "reaction" videos are special. Still I really enjoyed this one (and the original video).

Markup regions are a super interesting concept but I never really used them. It always felt a bit weird. So can't say that much about that concept in everyday use. I prefer using Direct Output. There is absolutely nothing wrong with it. I'd go so far and say it's the perfect way to start playing with ProcessWire. All you really need are some echo and foreach statements to start. That's the code I needed to start exploring the base concepts of ProcessWire. echo $page->yourTextField; foreach($page->yourRepeaterField as $repeaterItem) { echo $repeaterItem; } You will see results pretty fast and will see how some field types differ or behave in one situation or another. Create a few demo projects, break them, try to fix them, install them again and start over. The moment you know how templating / output strategies work in ProcessWire look into something like TWIG or LATTE. To use these you should know a bit more about how ProcessWire, fields, templates, output strategies, etc. work. Start here: https://processwire.com/docs/tutorials/ Even though this video is quite old and the backend looks outdated 99% of this is still true and works in the same way:

The people around might enjoy and maybe even love ProcessWire. As it is free, as in beer and in freedom. At least outside the ProModules and some other third-party modules. Yet, with that background, you probably could make bonus points in one way or another. The ProcessWire docs are probably one of the best, the API is easy to understand even for beginners, and the community is unmatched, absolutely awesome! Probably one of the best around. Another great option for you with ProcessWire could be: ProcessWire is probably the best CMS to run a data-driven website. But back to your questions, and a very warm welcome. Most clients who used and knew about WordPress just knew the name and were told it was awesome. Almost all were annoyed by those upgrades each and every day and that things broke once in a while that resulted in another invoice to fix those issues. So... no, most of my or our clients looked for something that caused less stress and minor headaches. We market our websites as helpers, that do most of the jobs and take care of some parts of the site and even remind editors to do their job. But that's another story. Those who wanted to keep WordPress didn't become clients and were directed to other agencies that knew WordPress. That easy. Some plugins, aka modules, from WordPress would be nice-to-have, yet we have absolutely everything around in one way or another. ProcessWire can do things just with its core capabilities that WordPress needs at least one, two, or even more plugins for. For example: ACF, CustomPostType, Caching. It's all there—maybe no batteries included, but you could just add those/whatever you need, especially in terms of ACF and CustomPostTypes. Caching is a bit more tricky, yet even for beginners, it is quite easy to handle (just like me, years ago, in 2016 or so without almost no knowledge about PHP or ProcessWire). I'd go this far and say ProcessWire is a great way to start a PHP-Dev journey. RockFrontend has an easy built-in page reload on file changes. It's probably my most-needed feature ever. Besides that, I use Rockfrontend or TemplateEngineFactory to enable TWIG support (others enjoy LATTE more, but ok). While it seems that almost 95% of us here use TracyDebugger, I am not using it for the following reasons: I am not a programmer or developer. I do way more frontend, concepts, and SEO so I enjoy things that make my life easier, like LazyCron, ProCache*, FormBuilder*, ProFields*, and some additional 3rd-party modules to fix and boost SEO, like SEOMaestro, or automate things, with LazyCron, Hooks in ready.php, and maybe even some small custom modules. The real kicker is probably: Custom Modules and/or Custom Page Classes My preferred CMS before ProcessWire was Textpattern which was totally different, yet minimal and easy to use. It took me about a week to feel home in ProcessWire, built my first client project the same year, and never left ProcessWire - since 2014/2015. I built almost everything from simple landing pages to full-fledged projects. See those Site of the Week entries here: https://weekly.pw/issue/221/ https://weekly.pw/issue/371/ https://weekly.pw/issue/374/

I use AlpineJS all the time in ProcessWire. See the package.json here. In terms of AlpineJS it's almost a one-time-build unless you place all logic in an external file. That takes minimal more effort to make it work. This is how I use it: package.json "scripts": { "watch": "npm-run-all --parallel watch:*", "build": "npm-run-all build:*", "watch:alpinejs": "npx esbuild site/templates/src/alpinejs.js --bundle --target=es2018 --watch --outfile=site/templates/js/alpine.dist.js", "build:alpinejs": "npx esbuild site/templates/src/alpinejs.js --bundle --target=es2018 --minify --outfile=site/templates/js/alpine.dist.js", "watch:appjs": "npx esbuild site/templates/src/app.js --target=es2018 --watch --outfile=site/templates/js/app.js", "build:appjs": "npx esbuild site/templates/src/app.js --target=es2018 --minify --outfile=site/templates/js/app.js" }, src/alpinejs.js import Alpine from "alpinejs"; // import mask from "@alpinejs/mask"; // import intersect from "@alpinejs/intersect"; import persist from "@alpinejs/persist"; // import focus from "@alpinejs/focus"; // import collapse from "@alpinejs/collapse"; // import morph from "@alpinejs/morph"; // Alpine.plugin(mask); // Alpine.plugin(intersect); Alpine.plugin(persist); // Alpine.plugin(focus); // Alpine.plugin(collapse); // Alpine.plugin(morph); window.Alpine = Alpine; Alpine.start(); src/app.js document.addEventListener("alpine:init", () => { Alpine.store("myStore", { list: Alpine.$persist({ listDaysDefault: 1, revision: 0.1, startDate: "", endDate: "", items: [], }).as("localStorageMyStore"), // disable scroll on body scrollLocked: false, toggleScrollLocked() { // if either or overlay or category menu is active if (this.showOverlayMenu || this.showCategoryMenu) { // console.log("true"); this.scrollLocked = true; } else { // console.log("false"); this.scrollLocked = false; } }, // Getter, Setter, Functions // https://alpinejs.dev/directives/data#methods // funFunction() { // return value; // }, }); }); // we check for updates on local storage and reload all browser showing this website // enable when necessary // window.addEventListener("storage", () => { // location.reload(); // }); _main.php <script defer src="/site/templates/js/alpine.dist.js?=<?php echo time(); ?>"></script> <script src="/site/templates/js/app.js?=<?php echo time(); ?>"></script> Let me know where it breaks your boilerplate setup.

JavaScript Tag Loading Visualized by Wes Bos See here for more/discussion:

I didn't work on pure PW projects lately but I think that RockFrontend could be The Tool-Belt for PW Frontend Devs one day. Features like the ones @Stefanowitsch mentioned are the reason I use and like it. Almost ZERO-setup just by installing the module. Auto Refresh (THAT'S THE FEATURE I LOVE!) Compiling CSS from whatever Minifying files ... Yet there is so much other stuff I need nowadays that just don't work without additional steps. Like TailwindCSS or AlpineJS. I need Node.js/NPM, some scripts, and an additional workflow that runs parallel to ProcessWire/Rockfrontend all the time. I can't give you a straight answer to your question but maybe explore the frontend-world without UIKIT, look into something like Astro (JS) and Laravel (PHP) to see how and what's working there. Right now I'm deep into Astro and I love it - even though there is way too much JS involved for my likings. Building frontends is almost fun again. Pulling in data is quite easy. Yet... it's not for all kinds of websites or projects, at least not for me. I still know when to switch to a full PW setup.

Is it enabled in your config.php? Just asking. $config->usePageClasses = true;

Never release on fridays! ?

Never used it but for some reason I believe this could be the reason.

That would actually be the start in the page array. To get a specific page, based on a selector with start and limit, you might want to look at this: https://processwire.com/api/ref/wire-input/page-num/ This way you can actually go straight to the specific page, like 3 of 7.

Do you mind sharing your special use case and solution. Just in case as this is quite a common question - at least once in a while.

@Pete got this message a while back: Where would I find this? I can't see it in this thread or in edit view.

Yet again I stumbled across a great series of videos. This time from PlanetScale - mostly about MySQL and of course PlanetScale itself. Yet I think this could be interesting to some of you. https://www.youtube.com/@PlanetScale/videos NOT AFFILIATED WITH THEM OF COURSE! (Did I already post this somewhere else here? I have that feeling right now.)

When everything is up and running again, as it was before, you could initialize a Git repo on your server. Every change in every file would be totally transparent from that moment. At least in theory.

Give us a screenshot and list those files, please, so we can check AND please download the whole directory and archive it in case someone wants to look into it further.

You see this? That's fine! It's part of ProcessWire since version 3.0.152 - see here: https://processwire.com/blog/posts/pw-3.0.152/#new-ability-to-specify-custom-page-classes It tries to extend the Page class.

Had a similar issue a while back because I used this: 'Content-Type': 'application/json', Just switched the content type and it started working: 'Content-Type': 'application/x-www-form-urlencoded',

The developer map says so. https://directory.processwire.com/map/

I don't know if "Woah... impressive!" or "WOW!" is the right answer to this.