Jonathan Lahijani

Something I was thinking about today was what are the pros and cons of ProcessWire being "dependency-free" in the sense that it doesn't rely on a separate web application framework? For example, Craft CMS is built upon Yii. Drupal, if I understand the history correctly, switched from their home-grown approach from v7 to Symfony in v8. WordPress is home-grown. ProcessWire is home-grown as well, right? I would imagine the biggest pro is that ProcessWire doesn't have to "answer" to anyone, follow a separate web application framework's opinions and update schedule and things like that. Would ProcessWire be what it is today if it had such a large separate dependency? Of course, pulling off a home-grown way of doing things is a monumental task that requires great skill, but Ryan seems to have pulled it off (which is probably why we're all here). I've come to appreciate this decision but wanted to get the opinions of others here as well.

(deleted)

Hey man, I coined that term! (patent pending! j/k) I would really love to hear your Laravel/ProcessWire experience and comparison in terms of web application development. I too have been working on a very large webapp with ProcessWire over the last 6 months using ProcessWire, Alpine and HTMX (no need for Tailwind since it's completely admin side, although I did nearly completely develop AdminThemeBootstrap as an experiment during this project which I may or may not use in the future on it).

@Robin S Thanks for that detailed example. I actually did experiment with that hook before my post as well, and as your example demonstrates, you kind of have to hack it to show grandchildren in-line with their parents. Sorting then becomes weird because they are technically at different depths. This isn't the best UX. Ideally, if you expanded/opened the "Colors" child page, then it would show it's children "contained" inside of it, in a way that's somewhat similar to nested repeaters without repeaters. I was wondering if native support for the approach I described would be too much of a stretch given how PageEditChildren is currently programmed.

@ryan For PageEditChildren, would it be a stretch to have it support editing a children's children from the grandparent page as well? I typically have an /options/ page, and under it I have my page-based options... for example "Colors", "Sizes", "Order Statuses", like this: Options (template is 'options') Colors Red Green Blue Sizes Small Medium Large Order Statuses Pending Canceled Complete If I were to activate the 'options' template in PageEditChildren, I will be able to edit only the "Colors", "Sizes" and "Order Statuses" holder pages, not their children (from within the holder pages) which are the actual options themselves. Is there a way to perhaps support this? This is something I've been meaning to address more nicely in the past, but PageEditChildren would solve it with being able to edit grandchild pages.

Consider checking 404 logs and see if there's excess traffic to nonexistent pages. If so, and depending on you are handling those and if they are pages that take a lot of database power to generate, handle accordingly. Bad traffic can sometimes cause performance issues.

I wish I could write a longer reply but I'm going to be unavailable for a solid week, however check out what I wrote here (wrote it last week) which includes a lot of bullet points that you may find useful: https://github.com/jlahijani/awesome-processwire?tab=readme-ov-file#why-processwire Also welcome to the forum. You'll be in good company!

OK I answered my own question. I need to use noHooks: wire()->addHookAfter("Pages::saved(template=basic-page)", function(HookEvent $event) { $p = $event->arguments('page'); $p->title = time(); $p->save(['noHooks'=>true]); }); You beat me by 5 seconds!

I don't remember if I've dealt with this properly before, or if I just used setAndSave to avoid the issue. But it brings up a question on how to do it the right way. My overall question is how do you properly attach a Pages::saved hook and again save the same page without causing an infinite loop? Let's say I have a hook like this: // works, but must setAndSave each field; doesn't seem ideal? wire()->addHookAfter("Pages::saved(template=basic-page)", function(HookEvent $event) { $p = $event->arguments('page'); $p->setAndSave('title', time()); }); That will work fine if I save a page or multiple pages using the basic-page template. OK. But if I want to save a bunch of different fields instead of just title, what is the correct way to do it? These will cause an infinite save loop: // causes infinite save loop wire()->addHookAfter("Pages::saved(template=basic-page)", function(HookEvent $event) { $p = $event->arguments('page'); $p->title = time(); $p->some_other_field = 'foo'; $p->save(); }); // this also causes infinite save loop wire()->addHookAfter("Pages::saved(template=basic-page)", function(HookEvent $event) { $p = $event->arguments('page'); $p->title = time(); $p->some_other_field = 'foo'; $p->save(['title', 'some_other_field']); }); If I remove the hook, it will save the page, but since the hook gets removed, it will only apply to the first page: // fixes infinite loop but hook gets removed; see below wire()->addHookAfter("Pages::saved(template=basic-page)", function(HookEvent $event) { $event->removeHook(null); // remove the hook! $p = $event->arguments('page'); $p->title = time(); $p->some_other_field = 'foo'; $p->save(); }); // only the first page will run the hook since it is removed foreach($pages->find("template=basic-page") as $p) { $p->save(); }

Has there been an updated, more formal, non-MagicPage approach to this yet? Is there anything wrong with doing this so at least the hook is "closer" to the page class? <?php namespace ProcessWire; // this is /site/classes/OrderPage.php // hook above class so it's "closer" wire()->addHookAfter("Pages::saved(template=order)", function(HookEvent $event) { $order = $event->arguments('page'); // hook code }); class OrderPage extends Page { // ... } Related GitHub issue since I don't think it's linked in any of the replies above: https://github.com/processwire/processwire-requests/issues/456

@Robin S Not yet but at least for now, the files existing there serve as a visual reminder.

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.