Jonathan Lahijani

It was a pleasure speak with you today @bernhard. For the others wondering, we mainly talked about "rabbit hole" you can go down with ecommerce and how there has to be a line drawn between what one gets with a fresh installation vs. what one must build on their own. Basically, how turn-key the solution is and how that relates to the target audience the system would be for.

I've integrated Stripe Payment Elements with my system which we can discuss @bernhard. Stripe is hugely popular in the US and it's probably the easiest to work with.

@bernhard Would love to chat about RockCommerce. I have my own internal ecommerce system that I've built with PW so I've walked this path as well and can offer some insights.

This thread is #1 on HN at the moment: https://news.ycombinator.com/item?id=41805391 Do a search for processwire on the page. Looks like an old forum member.

@bernhard RockMigrations and ProcessDbMigrate take fundamentally different approaches. RM takes the traditional web application framework approach while ProcessDbMigrate is more of a change recorder, similar to Craft CMS Project Config. There's trade-offs to each approach, but I will say it's nice to have changes to be recorded automatically, even if it's not a 100% full-proof approach (although I'm looking into that). It's basically automating what I typically do when I need to migrate a changes "by hand" on the sites I work on, which is an approach I like. I'm experimenting with the change recorder approach in a module of my own for now, but development of it is on and off for the moment. Understanding ProcessDbMigrate helped with understanding the approach, and the recording part of it is straight-forward. The "playing" of the recording gets tricky for all the reasons we all know about.

This idea is so under rated. Forums have declined in popularity as the primary communication method for software projects and general communities over the years in place of social networks and chat apps (Reddit, Discord, Twitter, Facebook). This makes me very sad because I find forums to be the optimal way to communicate while maintaining true control of the community. Discussions on Discord/Slack can't be discovered by a search engine. Twitter and similar services aren't ideal for long discussions. Reddit seems childish and their UI update is terrible. Facebook is closed and has bad discoverability. If ProcessWire didn't have this forum, it wouldn't be nearly the same. If a large software project similar to ProcessWire doesn't have a community powered by a forum like this, it's a big missing feature in my book. When I did a small Craft CMS project a few years ago, there was no equivalent to this forum, only Slack, although it did have a lot of people in it. Then if I asked a question that was answered in the past many times over, I would probably feel like an idiot.

MariaDB won't be an issue. I'm running ProcessWire on it with quite a few sites, from simple to complex, without any issues. (fun fact, Craft CMS requires MySQL or PostgreSQL; MariaDB won't work) I don't have direct experience with setting up Litespeed but that shouldn't be an issue either. I think Geffen Playhouse (a site I developed) is on Litespeed. The hosting company has abstracted that away and Litespeed is built as a drop-in replacement (?) for Apache so I wouldn't worry about that either. As @da² mentioned, if you use Windows, WSL is an excellent and seamless choice to spin up a VM to test, or DigitalOcean or Hetzner if you don't want to install a VM hypervisor on your system. Either way, you'll have to set up the server software and configure it yourself. I recommend Ubuntu 24.04 and installing everything with apt. If using VS Code, you can connect to the server and modify files as if it were a local VM site using VS Code Remote SSH.

I recently discovered Pinkary.com which I would describe as a Twitter clone, built by one of the Laravel team members with all the latest and greatest of Laravel and its ecosystem (the project is open-source). Right now it's got about 1000 members after being launched earlier this year and it's almost all web developers, which reminds me of the early Twitter days. I don't get excited about social media or microblogging much, but having a concentrated community of like-minded folks is intriguing and a place to find interesting things going on and nuggets of information, without all the noise, bots and other nonsense you'd see on Twitter/X. I think it's worth a join.

Thanks for the replies. I agree that using the page name has a bit of an "ick" factor, but the name won't change and I can lock the field regardless. I am purposely trying not to create a new specific template for each company, and although that approach is probably more clean and direct, it messes with the following extra part... I didn't mention in my example that there is also a "Company Types" field where a company can have multiple selections of the following: Provider Fulfiller Biller If the company is a "Provider", then I want the tools method (I've already programmed this but left it out in my example code to keep things simple). Although that could lead to some issues if I tried accessing that method and it's not available unless I did some extra checks, but that's not totally clean as well.

Let's say I have the following pages with these names that use the "company" template: microsoft apple google Let's say my page class has a method called 'foo'. I want the code that's run to be dependent on the page name, but I don't want to do it like this: public function foo() { if($this->name=="microsoft") { // code for microsoft } elseif($this->name=="apple") { // code for apple } elseif($this->name=="google") { // code for google } } Instead, I want each company to have their own class (but keep the pages as 'company' class -- don't touch!) with each method implemented within that class. How would you go about this? I solved this by adding a property to the Page class using property hooks which has access to the respective method (what's this technique called? is there a name for it?), but wondering if there's a better way: class MicrosoftCompanyTools { public function foo() { echo "test"; } } wire()->addHookProperty('CompanyPage::tools', function($event) { $company = $event->object; $companyClassName = "ProcessWire\\" . ucfirst(str_replace('-', '', $company->name))."CompanyTools"; if(!class_exists($companyClassName)) $event->return = false; $event->return = new $companyClassName(); }); // example call $pages->get('template=company,name=microsoft')->tools->foo();

When creating a single page select, I use "Single page Page or boolean false when none selected" value type. It's become a habit that I haven't given it much thought about until recently. I believe this was the default option in PW at some point from the beginning (?), or at least because it shows higher up than the other option, I've tended to use it more. Then when there was an update to ProcessWire a couple years that brought in field setups, if you create a field using the "Singe page: select" setup, it defaults to using the "Single page Page or empty page NullPage when none selected" value type. When I create a field this way, I change it back to "Single page Page or boolean false when none selected" however it makes me wonder if using NullPage as opposed to a boolean is a better practice. This matters because when detecting false vs. NullPage the code must be modified to work correctly. This will bug if the there is no assigned page and the return type is boolean false: // Warning: Attempt to read property "id" on false if($page->my_single_page_reference_field->id) {} Furthermore, if you're not careful with whether you do ->id vs. the value type, your true/false could be swapped. Ack! What is your preference and why? I think mine would be to get a NullPage instead of false if there is no page.

Probably, but also keep in mind the styling of the event displayed in the day box is very custom as well: https://www.geffenplayhouse.org/tickets/#cal

No need for multi-day events, so that wasn't even something I thought about. That's actually something I would imagine would make the CSS Grid approach potentially unusable if you need to span the event over multiple days, but at the same time support for spanning was one thing that made FullCalendar difficult to style for my simple needs, at least in v3. As for display order/stacking, that was another issue that I had to hack around with FullCalendar. For example, if Geffen had a day with an events schedule like this (ordered by time): Show A: 2:00pm Show B: 3:00pm Show A: 4:00pm Show B: 5:00pm They would actually want it to be displayed like this (ie, grouped by show, then time): Show A: 2:00 pm 4:00 pm Show B: 3:00 pm 5:00 pm That's not the "natural" way it would work in a pure calendar sense (which orders strictly by time), so with FullCalendar I had to basically do-away with how it normally puts in an event and inject custom HTML, which kind of defeats the purpose of using a calendar library. I believe when they switched from v3 to v4, they changed too much of how it worked internally and I didn't want to redo that work-around to be compatible with v4, so that's when I gave the whole approach a re-think (we launched in 2019 with FullCalendar, then I re-did it in HTMX in 2022).

I can give a quick reply about the Geffen calendar, but most of what there is to know about it is in that article I wrote. How the show performances (events) came to exist wasn't a concern as that was managed with a 3rd party service, obtained via an API and stored as child pages of a show. The main takeaway from that project was that we needed to simply display upcoming shows in a monthly calendar format (large and small) and when I originally developed the site, I leaned on FullCalendar. However that was total overkill and difficult to maintain because FullCalendar is more than just a way to display events in a calendar format, but an interactive component with dragging and dropping like what you'd get in a real calendaring system (Google Calendar, etc.). It's also built with complex JS which I like to avoid. I just needed an easy way to display information with simple AJAX loading between months. To solve those, CSS Grid (ie, "display:grid") and HTMX fit perfectly with some straight-forward PHP code to build it. One extra improvement that can be made to display a large and small calendar in different contexts while using the same HTML is to use container queries, but because browser support for it a couple years ago was still very low, I avoided it.

Wasn't there a module that surfaced this information in the admin? Anyone remember what it was called? I can't find it. Edit: TracyDebugger can do it.