Jonathan Lahijani

I spent a few hours this morning making an MCP module for ProcessWire similar to Laravel Boost. I'm going to call it Octopus. In just 2-3 hours with Opus 4.5, I'm already what feels like being done with 90% of it. I'm going to finish the remaining 90% (heh) as I work on various projects to actually test it. I will have to figure out the best way on how to provide ProcessWire documentation to the MCP (hence why I'm on this thread), but even without it, Opus 4.5 is insanely good in following ProcessWire conventions, even with little context! The hype is real. Let me know if you have any questions or suggestions. Screenshot attached.

@BrendonKoz The problem with that option in the screenshot is that while it ungroups the taskbar items, it keeps the "text" part of it, which I don't want because it's not necessary for me and I like to have a lot of windows open so I want to conserve horizontal space. Windows 10 used to have that option, but they removed it in Windows 11. That's why you have to use this Windhawk mod I mentioned in the readme: https://windhawk.net/mods/taskbar-grouping A registry setting alone won't fix it unfortunately. Come on Microsoft!

While my plan is to switch to Linux one day (probably Omarchy), I'm still putting that (and tiling window managers) off for a bit. Let it cook a little more. In Windows 11, I like my taskbar, but one nagging thing is that it's hard to differentiate the icons of many Code/Codium instances given that I don't group them. I use both programs actually: Code for actual coding and Codium as my Markdown note taking tool (I prefer to not use Obsidian and the million other markdown editors; Code/Codium for Markdown is fantastic since you get all the developer ergonomics) With the help of AI, I developed a program with dotnet that makes it easy to add custom icon overlays effectively differentiating the program instances. This saves a lot of headache of knowing which icon corresponds to which project with a quick glance. Feel free to use it! https://github.com/jlahijani/TaskbarIconOverlay

Totally valid. However to address this they added an option in 3.2.0 so that when updating, you don't get bleeding edge packages, but instead it's lagged by 1 month: https://github.com/basecamp/omarchy/releases/tag/v3.2.0 So that's comforting. Similarly, I use ProcessWire bleeding edge / dev branch, but if there have been changes in a particular week that I sense as more in-depth, especially those that touch selectors and database stuff, I usually wait another week or two to avoid potential subtle issues that are difficult to catch. I'd imagine I would use the same judgement with Omarchy.

I've settled on Omarchy! I spent a couple days getting used to Hyprland and tweaking it to my needs. It's a bit of a mind shift not having a taskbar/dock anymore, but I made it nice and easy to switch workspaces very quickly and do some basic window manipulations. It's nice having a Windows VM set up as well (I need Photoshop for work since I work with printing companies; CMYK support is a must). It's time to say goodbye to Windows!

@ryan I'd be interested to hear how you work on a project with multiple developers and manage keeping each developer's development instance in-sync. For example, are you using a migrations module like RockMigrations or writing migrations in a module specific to the site that adds/updates fields/templates/pages/settings when the module is updated using a version compare? Or are you doing something completely different? I'd be interested to hear how you handle this given that ProcessWire stores much of its configuration in the database.

Let's say you have a repeater field. ProcessWire renders it in the default ProcessWire way in the page editor, which is fine, however there are times where you may want to render a particular repeater field in a more streamlined way, like a table, while maintaining the ability for the user to make changes to field values of the respective repeater items. The problem with this however if that you must be very careful because if you do not represent a field of that repeater (and represent it correctly with the correct form "name"), then ProcessWire will wipe out the data because it expects it to exist when saving!!! This includes the "native" fields for a repeater item (which are "loaded", "sort" and "publish"). THOSE MUST ALSO BE REPRESENTED! For fields in your repeater that are hidden however, they do not need to be represented, so you can ignore rendering those. You have to be very careful here because you may one day decide to add a new field to a repeater and keep it as "Open", and forget this requirement and not add it to the your custom renderer. Then if you wrote data to the field in some way, and then a user went to edit a page that contains that repeater field and they save, your data will get wiped out!

With anything new that gets designed (a website, operating system, interface), there's always that initial cringe feeling because it's no longer familiar and comfortable, but after a couple weeks, that goes away. I'm developing a new site and using the new Konkat admin theme, which at first felt totally wrong, but now it feels just right (with 1-2 CSS tweaks, like to make repeaters jump out more). My brain is very picky about adjusting to new fonts... Inter in this case. I like the font a lot, but I just need to adjust to it, get used to the curves. Same thing with new versions of Windows when they change the default font. It's kind of like when Facebook went through a few major design changes at during the 5-10 mark and everyone would complain, then everyone got used to it. Anyway, great work. It's grown on me.

Tip: In Symfony Console, if you run code and an Exception or WireException occurs, ProcessWire will not be able to log it (and also send an adminEmail). There were cases where I was calling an undefined method on a page object and not knowing about it erroring. I used AI to work through this and ultimately it said I have to basically manage this myself because Symfony Console will catch things if I don't and never hit ProcessWire. Therefore, you may want to do something like this in your handle method: public function handle() { try { nonExistentFunction(); // purposely cause an error } catch (\Throwable $e) { // log the error $this->wire()->log->save('errors', $e->getMessage()); // consider adding additional code here to send an email notification using WireMail // ... // Re-throw so it still displays in console throw $e; } return self::SUCCESS; } I wonder if there's a more efficient way to do this? It took me too long to figure out what was happening in the first place so I haven't spent time optimizing the approach (if it's even possible).

(deleted)

Thinking about it further, I could probably go with a hybrid approach too. On my new Linux machine, I could set up a LAMP stack directly and run the projects that don't need the level of isolation DDEV provides (which is mostly all my projects) and only use DDEV for projects that would benefit from it (mainly this webapp I've been working on for the last couple years). The main point is that I want everything on one powerful development machine. My old Dell workstation is showing its age when running that webapp, although in production is pretty fast. Thanks for the insights and suggestions!

Oftentimes it's 3-5 projects at a time, with other projects being dormant or semi-dormant for a while. However there are times when I want to apply some setting across all of my sites, even the dormant ones. For example, a few years ago I decided to use SessionHandlerDB instead of the default, file-based session approach. I did this manually across all 50 sites (I suppose I could have scripted this). No need to boot up each development site with my current approach since it's all on a single LAMP server. But with Docker/DDEV, I'll have to spin up DDEV for each project then make the change, then shut it down. A little extra friction, but thinking about it as I write this, I don't think it's as bad as it sounds and I can probably automate it to some extent. How do you personally handle situations like that? If I get a Framework Desktop, I would get it with 128GB memory. It's very powerful.

I'm planning on using DDEV sometime in the next few months when I buy a new computer (most likely Framework Desktop) and hopefully switch to Linux (looking to use Omarchy). It's going to be painful in the beginning (I really REALLY don't want to give up XYplorer and I hope I can adjust to a tiling window manager way of doing things), but Omarchy is where it's at for web developers. Right now, my dev setup is pretty simple: I have a separate bare-metal server (an old Dell Xeon workstation) running Ubuntu 24.04 and a LAMP stack (mostly everything installed with apt). I have Samba setup so I can access files from my Windows desktop machine for convenience. I use VSCode Remote SSH extension to edit files directly on the server. This has served me well and is not complicated at all. All of my ProcessWire projects exist there. One thing I do to keep things as efficient as possible is symlink the 'wire' directory of all my projects to a single folder that contains the latest version of ProcessWire (I'm not using Composer to manage ProcessWire itself). Therefore, if I want to update all my sites to the latest version of ProcessWire, I just symlink that folder and all the other sites are automatically updated. Sure, that kind of goes against proper source code control practices and such, but I'm always a solo developer and the strict level of isolation of environments between sites is typically not needed for 99% of the sites I work on, which is kind of the point of Docker/DDEV, but I still want to use it. Updating ProcessWire in this way is very efficienct (at the 'expense' of a potential site breaking which is very very rare). So my question is, if I have 50 ProcessWire sites created with DDEV, can I still symlink the 'wire' folder of all of them the same way I described above without any issues? I'm very rusty with Docker but looking to embrace it heavily. Also, is it "crazy" to have 50 ProcessWire projects started all at once (will that take up a lot of resources)? With my current setup, I don't have to launch anything because it's all served by a single Apache, MariaDB and PHP which is very convenient. With DDEV, I have to launch each one individually.

Well it looks like they're switching to Laravel for Craft CMS v6: https://craftcms.com/blog/laravel This is very interesting and speaks to the idea of the CMS and web application framework powering it being 2 separate projects (Craft, etc.) vs. it being built around each other (ProcessWire). In my opinion, ProcessWire wouldn't be what we all love about it if it had such a huge dependency.