Jonathan Lahijani

Hi Ryan, Would it be possible to create a more streamlined way for your 1st party commercial modules to be downloaded? I have licenses for most of them and grabbing them all one-by-one through the respective forum threads is less than ideal. Too much friction. Ideally, if they could be upgraded via ProcessWireUpgrades module (although I think I understand your hesitation doing it that way), or if there were some sort central control panel on processwire.com/talk/ (or just processwire.com), that would be a nice upgrade.

I remember using Textpattern way back in 2005 or 2006. I'm old (by web developer standards).

My use of Node was as follows (well it was based on Laravel Mix): downloading packages (package.json / node_modules); for example, getting UIkit, jQuery and whatever else a project required compiling SCSS or Tailwind creating a dist folder with that CSS, other compiled JS and images cache busting As for downloading packages, I have my own ProcessWire module that contains unminified and minified versions of the packages I commonly use or that I deem to be worthy enough to be in the module. I built a very simple way to update those packages and include them in my project as well as well. UIkit is a special case in that it's both SCSS and JS files. If I want to include HTMX for example, I just do this: setting('htmx-enabled', true); and everything gets inserted as it should. The potential drawback of this approach is that because I use this module across many different projects, all projects automatically get upgraded to the latest version of a package which could potentially break things, but that's rare and not a big issue for me. For compiling SCSS, I would have stuck with ProCache (SCSSPHP) but it's completely outdated and that's just not going to change. Therefore I use DartSass. You can download the executables here: https://github.com/sass/dart-sass/releases I've hacked ProCache (because it doesn't have the necessary hooks) so that instead of using SCSSPHP, it uses DartSass. Ryan has expressed the ability for ProCache to be more friendly to using outside compilers so hopefully a future version of ProCache doesn't have to be hacked directly. As for Tailwind, during dev I use Tailwind Play CDN. During production, similar to DartSass, I use TailwindCSS CLI and I hacked ProCache to make it work with it as well: https://tailwindcss.com/blog/standalone-cli https://github.com/tailwindlabs/tailwindcss/releases/tag/v3.3.3 Both DartSass and TailwindCSS CLI have minifiers built-in, so therefore I avoid using ProCache's CSS minifier which has been a a little buggy (although I think it's now fixed?). Technically speaking, TailwindCSS CLI is Node.js under the hood, but it's wrapped up into one executable which feels clean. For what would typically be a "dist" folder, I just avoid that. ProCache Buster handles that in its own way. Yea these is how I think about it as well. HTMX is less opinionated and I like it that way. However HTMX is not the "JS sprinkles" (it's more for HTML over the wire requests) so that's where Alpine.JS comes in.

That's pretty much the main reason. It would require me to use ProcessWire in a different way and I don't buy into that approach, especially with HTML Over The Wire (for example, htmx) giving me all the benefits of heavy JS-frontends without having to use them. Server-side rendering all the way. I've completely eliminated Node from my workflow and it feels great.

I've heard of Astro and a bunch of other JS heavy frontend frameworks where ProcessWire has to become an API for it to work. Hard pass for me for so many reasons. This article is exactly what I was looking for. Thank you for sharing it! It seems nesting is available on all the latest browsers, but I'd worry about people on old versions of Safari due to being on old versions of macOS (Macs seems to last a while), so yea I agree with using a build process for now if nesting is critical to the way you write CSS, which it is for me as well. Also, doing breakpoints in SCSS in much more intuitive than vanilla CSS.

@ryan Can ProCache be refactored in such a way that SCSSPHP and the other compilers are optional extensions, along with the ability to define our own compilers (ie, DartSass and TailwindCSS CLI)? You mentioned something along those lines in a conversation we had in the ProCache forum and I think this would be a step in the right direction given how fast things in frontend web development move.

Given that CSS has made huge strides in recent years combined with my desire to remove build processes (Sass, Tailwind), I'm thinking about going back to writing vanilla CSS, at least for some projects. My question is, what CSS organization methodology makes the most sense for vanilla CSS? I was never a fan of BEM personally and haven't had to think deeply about CSS methodologies for the past 10 years because I just followed the style of whatever CSS framework I was using.

Also keep in mind that ChatGPT is not deterministic, meaning you may get different answers for the same prompt.

ChatGPT has blown my mind countless times from a programming point of view. It's ridiculously helpful and has given me superpowers (ie, less reliance on poor Google results, which in turn helps with learning faster). It's also very helpful in providing a starting point on topics I have low experience in (for example, doing some advanced things with ImageMagick). My prompt was literally copy/paste of my original post. Pretend ChatGPT is a human that knows basically everything about everything. I have a bunch of other code in ready() which was causing errors given the context. But I should investigate that further (I was losing patience debugging for 2 hours). Will try what Ryan mentioned, but for now I refactored my hooks into their own method.

It's nice to see a ProcessWire site that's close to home!

I asked ChatGPT and it gave me what I needed to know: Therefore, I've moved the relevant hooks into a method outside of ready() and am attaching the hooks explicitly now in my script.

I have a module that I created which I am installing and then running a method on via the command line (although this issue still occurs when running in the script in my browser as well). My script looks like this (I've heavily simplified it here to demonstrate the issue precisely): <?php namespace ProcessWire; include(dirname(__FILE__).'/../index.php'); // bootstrap processwire wire('modules')->install('MyModule'); wire('modules')->get('MyModule')->setupDemo(); MyModule's ready() method contains various hooks, many of which do things on page save. MyModule's setupDemo() method does a bunch of stuff like creating pages and fields. The problem is, when doing those two things back-to-back as shown above, the ready() method doesn't get executed for some reason and therefore the hooks do not get applied! As a result, the various things that rely on hooks in setupDemo() do not execute. If I were to split the two method calls into two different scripts and ran them one after another, this issue does not occur. What am I doing wrong? I've tried wire('modules')->refresh(); between the two calls and several other things but no luck. Note: if I call the ready() method explicitly, it causes problems as well.

I had my own similar moment today. I was using the API to install a Fieldtype module, such as FieldtypeToggle. It was not working and after an hour of debugging, I found out I had capitalized the T in Fieldtype (FieldTypeToggle -- bad!) which ProcessWire doesn't play nicely with.

The problem I had was with the way I was using the head-support extension. I was using the "merge" behavior instead of the "append" behavior. Merging would destroy all Tracy injected code that it placed in <head>, but appending preserves it. Appending leaves a bit of extra HTML behind after HTMX does its merge, but it doesn't affect how a page gets rendered or lead to incorrect results.

An update on this as I now know what the problem is... If using TracyDebugger with HTMX's head-support extension, TracyDebugger's bar will become "unstyled" when doing an htmx-style request. This happens because the CSS that TracyDebugger uses to style the bar gets stripped-out with that extension (since it's in the <head> and the two don't play nicely with each other). I will follow up with a solution if I'm able to find one.