Jonathan Lahijani

Incorrect! You must demonstrate to employers you understand React because everyone is using it (aka Resume Driven Development). Here's what ChatGPT recommends to write in resume-speak (it took a few refinements to get this): "Acquired advanced proficiency in React.js through extensive development experience with WordPress Gutenberg."

My eyes. I think String Theory will be easier to comprehend. Seriously though, imagine in 4-5 years as the team behind that creation withers away (as they find new jobs) and the domain knowledge leaves the company, with new team members taking over and having to maintain and build upon THAT. It's going to get worse before it gets... worser? WordPress is bad for your mental health.

I've been using ProcessWire for a long long time and over the years my techniques and go-to approaches have been constantly refined. A lot of this knowledge is codified in my internal heavily opinionated starter module that sets up everything up the way I like. Even with that, there are other tips, techniques, and modules that I may use occasionally on client sites and because of that, I may not remember them months or years later. I do have a document that I've been better at updating recently with this information, but in addition to that, I think to really remember a piece of knowledge it's best to actively use it even if not necessary. The best place I've found to do this is on my personal website. I treat my personal website as a semi-testing ground, a reminder of techniques and the generally the first place I will use something that maybe gets used on my other client websites. Even if I don't really need some specific module, need that odd hook, or require a specific setting, I will deliberately use it on my personal website because I have total control over it, it's live (meaning I have both a development and production version which allows me to test my deploy and sync scripts) and if something breaks temporarily it's not a big deal. For example, I'm doing the following on my personal site: various hooks that modify the admin; adding custom markup fields in the page editor for certain templates using dotenv (maybe eventually use this everywhere, but only here for now to codify the latest approach on this) using rockshell with some custom commands that I don't really need have a random snippet for tracydebugger in /site/templates/TracyDebugger/snippets/ created all the other special status files in /site/ (boot.php, download.php, failed.php, render.php) blocking the vendor folder in .htaccess have a random rewrite rule in .htaccess using ProcessRedirects with a random rewrite rule disabling sessions purposely have a dash in the name of my database (did you know Microsoft purposely put a space in the "Program Files" directory so that developers properly handle paths with spaces in it?) using Page Edit Lock Fields on my home and about page (yea, locking the page from myself!) experimenting with the AdminBar module and hooks, even though I won't use this module (I have my own admin bar that loads via ajax) overriding styles in the ProcessWire's admin bar (making the font small, smaller spacing, full width container) have a humans.txt file separately, using Matomo even though I don't really care about analytics for this site my deploy script deploys some extra random directories even though I don't need them have a separate user account that's been assigned the AdminThemeBootstrap theme I am working on using a honeypot field on my formbuilder-based contact form (I use this everywhere) I have a note (which is basically the above list) that I add to so it's easy to remember what I did, why and references to it (forum post, github, blog post, etc.). --- Separately, I have another completely blank ProcessWire installation with nothing extra done to it (except TracyDebugger). I use this to test and experiment various things (sometimes unrelated issues) when I don't want any hooks or installed modules potentially modifying anything. I'll also install modules here that I'm not so sure about. If I suspect I hit a bug with ProcessWire in a separate installation, I'll experiment here as well. Once I'm done fully experimenting and the issue has been resolved, I'll make a note in a log of what I did then undo my changes bringing it back to a clean slate.

@FireWire Pssh. All these issues you speak of are the "old" WordPress from the late 2000s and early 2010s. You are not using the fantastically re-envisioned NEW WordPress which totally solves all these problems by bringing in React to build Gutenberg out of the carcass of classic WP. It is NOT a s***-show. Here, just read this new glowing review: https://dbushell.com/2024/05/07/modern-wordpress-themes-yikes/ HN Discussion: https://news.ycombinator.com/item?id=40296534

I was dusting off my Awesome ProcessWire repo and updating it with more relevant information. One thing that bothered me is that the various links I have in there to forum posts may have changed, but this forum software correctly forwards it to whatever the latest URL is. While the forum doesn't expose an actual canonical URL for a post, I found this little hack to make it as minimal as possible. Let's say you have this URL: https://processwire.com/talk/topic/29951-weekly-update-%E2%80%93-26-april-2024-%E2%80%93-profields-table-v29/ That bothers my "OCD" and if the post title were to be changed, the URL would change accordingly, but I figured out you can chop off everything after the post ID and following dash and add an extra dash if you want a canonical-like, minimalized URL. It would look like this: https://processwire.com/talk/topic/29951-- (two dashes required)

Would it be possible to edit the 'name' field of a page as well?

This is awesome. I use PageTable with a slight hack to accomplish what's shown here, but that will go away now. Also there's a typo with the word "ediable" in the module settings.

With every PW website, I usually create a folder in the root (let's call it "something") where I store various scripts that do random things (most of these scripts act on ProcessWire directly so I bootstrap it). I execute them either by visiting the url in my browser or using the terminal. There's a bit of security through obscurity with this approach that feels wrong. Using something like RockShell is probably the more formal way to do it, but sometimes it may not be the right choice for short-lived scripts or scripts that don't act on PW directly, or if the script is written in Bash. Also I haven't started using RockShell regularly yet although that's the plan (I'll have to convert a lot of sites). So my question is, what is your go-to approach in terms of where to store and how to handle supporting scripts like I described?

For what it's worth, I switched from MySQL to MariaDB on my local dev server which is running Ubuntu 22.04. Importing a db dump that uses InnoDB is 7x faster in MariaDB. I tried making it faster in originally in MySQL by adjusting a bunch of settings without luck. Switching to MariaDB with its default settings is much faster based on my simple test. Edit: It seems the reason the speed is much faster has to do with MariaDB disabling binary logging by default while MySQL doesn't which is probably the more accurate explanation: https://dba.stackexchange.com/questions/327303/mysql-8-twenty-times-slower-than-mariadb-10-3

As far as I can tell, that's the way to do it. Assuming your repeater field is called 'my_repeater_field' and it contains a field called 'foo' that you want to add a make-shift markup field above, here's what you'd do: $wire->addHookAfter('InputfieldWrapper::render', function(HookEvent $event) { if(!$event->object->children->count) return; if($event->object->children[0]->name!="my_repeater_field") return; $event->return = str_replace( "<li class='Inputfield InputfieldText Inputfield_foo_repeater", " <li class='Inputfield'> <label class='InputfieldHeader'> my custom repeater markup field </label> <div class='InputfieldContent'> content goes here </div> </li> <li class='Inputfield InputfieldText Inputfield_foo_repeater", $event->return ); });

@Sebi Right now, it is possible to view the OpenAPI json by going to /admin/setup/appapi/endpoints/action-get-openapi/ I want to automate building html-based documentation with Redocly CLI based on that JSON data, however because how it is currently programmed, I can't use a script to cleanly grab that JSON nor is there a method that easily gets it in that format given how the code is structured (using the executeEndpoints method doesn't get the JSON in the same way and it relies on urlSegments). Is it possible to refactor the code / create a new method that would allow getting the OpenAPI JSON directly?

Just curious, does anyone know the approach @ryan uses to minify module JavaScript files? For example, how is he minifying this: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.js to this: https://github.com/processwire/processwire/blob/dev/wire/modules/AdminTheme/AdminThemeUikit/scripts/main.min.js Ideally I want to use a CLI-based tool (Linux-based), but I want to avoid using a Node-based solution (such as https://github.com/terser/terser).

If you truly want to make an admin theme from scratch like I'm doing, it's best to just take AdminThemeUikit, since that is the "official" and most supported theme and rip out UIkit and start replacing it with your own approach and just hack away at it. Keep in mind that ProcessWire makes heavy use of jQuery UI and a few other libraries so you'll have to play nicely with them unless you want to replace them too, but that takes it to another level. With Bootstrap, it's straight-forward enough given the similarities with UIkit, although this is turning out to be more work than I anticipated. But that was the point since I want it to force me into looking at how everything is interconnected. One idea for an admin theme is to do it with pure, modern CSS and as little JS as possible and as accessible as possible (good reason why here).

@Mustafa-Online I made nice update today on this module after not having touched it in several weeks. It's now basically complete but before I release it I still need to clean up some old code that's left over, make it work more nicely with SelectizeAll and provide similar overriding capabilities that the UIkit theme has. This module includes Bootstrap Icons and it substitutes Font Awesome icons accordingly (I went through each one and found the equivalents!). It also uses the Bootstrap navbar and dropdowns. A side-effect of this is ajax-loaded dropdown content won't work in the first release. I may backtrack on using Bootstrap dropdowns depending on if that becomes difficult. Anyway, it's looking good overall. If anyone is wondering why use this as opposed to UIkit, it may be beneficial if you are doing a lot of custom admin stuff and want to use pre-made Bootstrap styled components since the Bootstrap ecosystem is much much larger than UIkit. Also, it feels a little more fresh, although my actual reason for creating this was to for a way for me to get a deeper understanding of how admin themes work.

@ryan @Pete Can we get this fixed? Or if you'd like, I can help maintain this site.

I wanted to start a conversation about other systems out there that are "ProcessWire-like", meaning they also go all in on everything being a custom field, similar database architecture and other things that make ProcessWire seem unique. What makes ProcessWire unique to you that you just haven't seen elsewhere and how deep does ProcessWire go with certain decisions or features that other systems don't from your experience? One very recent system in the JS world that's similar (at least on the surface, I've never worked with it) is Payload CMS: https://payloadcms.com/

If I'm understanding this correctly, this would mean all of ProcessWire would have to be open-source, meaning the commercial modules, correct? Related.

Thanks for releasing this Ryan. Although I've been using ProcessWire daily for over a decade at this point, it's nice to compare my version of "The ProcessWire Way" with that of the creator himself and learn any tips and tricks along the way. This is probably going to be very helpful for beginners. When I was researching Tailwind a while ago, the creator (Adam Wathan) spoke about how he made many demo videos of himself replicating websites with his CSS framework so developers could get an idea of how the creator of the tool himself would approach using it. I feel like these site profiles provide a similar and more realistic learning experience in addition to ProcessWire's great documentation.

For those who want to block the vendor folder using ProcessWire's main htaccess file, here's a snippet: https://github.com/processwire/processwire-requests/issues/191#issuecomment-1969214984

With Geffen Playhouse for example, which was launched in 2019 right before custom fields for files/images was introduced, we needed custom fields for images. At the time, the best approach was to use the RepeaterImages module, which uses repeaters and all the functionality that comes with it. This includes the ability enable/disable a repeater item. In a recent update, I wanted to remove that dependency and switch to just a normal images field with custom fields, but the client still wanted enable/disable capability on images, hence my approach to it described in this post. I think about it just like repeaters. There are times when you want a piece of data to exist but not be visible. Without being able to disable an image, you would have to delete it (or do some other weird hack like perhaps add an image tag), which is less than ideal. With enable/disable capability, it brings it more in line with how multi-item fields, like repeaters, work.

As of today, this is now a native feature on the dev branch: https://github.com/processwire/processwire-requests/issues/520#issuecomment-1961794624

Lets say you have an multi-image field named 'images' and you want to be able to mark one or more images as disabled as well as make it visually appear as disabled in the admin. Currently, ProcessWire does not support this natively (requested here), however we can still easily achieve this with using custom fields for files/images, introduced in PW 3.0.142, as well as a hook to achieve the visual effect. Follow these steps (modify as needed): create a checkbox field called 'disabled' create a template called 'field-images' which will ProcessWire will detect as a custom template for the 'images' field add the 'disabled' field to that template add the following code to /site/templates/admin.php $wire->addHookAfter('InputfieldImage::renderItem', function(HookEvent $event) { if($event->object->name!='images') return; if(!$event->arguments('pagefile')->disabled) return; $event->return = "<div style='opacity:.2'>{$event->return}</div>"; }); Of course, if you don't want to display disabled images on your frontend, make sure to update your selector on your 'images' field, like so: // before (will still select disabled images) foreach($page->images as $image) { ... } // after (will ignore disabled images) foreach($page->images->find("disabled=0") as $image) { ... }

As of today on the dev branch, this is now possible with a new hookable method InputfieldPage::renderPageLabel() https://github.com/processwire/processwire-requests/issues/460

Hey there fellow Angeleno, Let's assume you have a bunch of 'video' pages with a 'file' field where the single video gets uploaded and another field called 'file_transcoded' that contains the transcoded/sized-down version. You could create an external script that bootstraps into ProcessWire, loops through each page where 'file_transcoded' doesn't exist (meaning it hasn't been acted upon yet), run ffmpeg on it, take the transcoded file and add it to file_transcoded ($page->file_transcoded->add($transcoded_file)), save and repeat for all the other non transcoded pages. That external script could be run using a cronjob. I believe you can do a background process or queue however I don't have experience with that in the context of ProcessWire yet although it's been discussed. The approach I mentioned keeps all the files in the natural /site/assets/files/(page-id)/ directory. I think the main point here is that where the original video files precisely exist is irrelevant as long as you use the $pages API which will take care of that for you.

Because I don't write JS often, hold my nose when I do, and since it's usually for little tweaks or UI adjustments, my knowledge of the syntax and weirdness of the language overall doesn't seem to stick (how do I add a class to a div again in vanilla JS?). Google is not so great because oftentimes the information is outdated on Stack Overflow results and requires a lot of sifting. However ChatGPT is phenomenal with JavaScript (and jQuery) if you want develop AND learn at the same time. Seriously a game changer for me. Unfortunately it's not so great for AutoHotkey, or at least it seems to keep giving me v1 code as opposed to v2 despite telling it to give me v2, but that's OK because it still provides some guidance which I supplement with AHKs documentation.