wbmnfktr

It's not that wrong but maybe not the best option in this case here. I'd honestly go a totally different route and... create a template catalog_image or something create and add all necessary fields to that template create another template catalog_category create and add all necessary fields to that as well From there I would create all category pages and add those images under each one/where necessary or wanted. That way you can always move one image to another category, sort them way easier, disable, or clone one with ease. Oh... and it's probably way easier to maintain.

A bit weird and probably nothing to listen to while programming - still awesome.

Mau P @ Academy - Los Angeles 2023

Absolutely. Even though I didn't know that page was so... outdated while being up to date. Arguments for my thoughts and feelings. ? I really think the cut must be bigger - see my last post. But YES.

My absolute favourite tool for developing still is: LARAGON Since I left Windows a few years ago... I still miss it. It's so easy to use, super fast setup/installation, new sites are only one click away. AWESOME! Installing DDEV on Linux is quite a big task, reboots included. After the 3rd or 4th time it get's easier but still quite a bit of work. AND it's big. It takes quite a bit of space on your disk. A few gig at least. I remember my first DDEV setup and I swore to myself: NEVER EVER AGAIN! But then I tried my old setup with installing Apache, MySQL, PHP, and all the other stuff... it was quite humiliating and I installed DDEV again. Yet, never got it up and running on any Arch-based setup, which is fine, as I'm running Debian now. What I really enjoy is chaining commands (using aliases). Something like: ddev start && ddev launch && code . && exit from the terminal, wrapped in a FZF script or local .sh file... Nice! Which brings me to the benefits of DDEV... you can create your very own workflow with DDEV using aliases. A new PW instance or maybe even the other CMS some people are talking about... you can do quite a lot, still the docs are sometimes a bit hard to read and maybe too verbose (too much fluff in this case). My personal most loved features is that you can share your config to setup an identical environment with ease. .ddev/config.yaml for the win! Looking for and grabbing those setup prompts for DDEV to get the setup you need is just pure Gold! Some of you may remember I wasn't a fan of DDEV in the past. ?

Ok... just thought about it again, maybe I was thinking about a ProcessWire 4.x release. That would be a massive one. Even bigger than the 3.x release.

To be abolute honest here... right now working with ProcessWire (Dev) on a recent hosting setup using my loved modules, feels a bit awkward. Besides one of my main hosters, all use PHP 8.1 as the default now - old instances not included, they still run 5.4+. I don't want to force anyone doing things they don't want to do right now, because it's not really/absolutely necessary. I'm totally fine with this. Latest PW Stable, PHP 7.4... total peace and harmony. My thought, see above, doesn't name a date or even a date range. Yet I somehow have the feeling that ProcessWire should somehow set a date for a minimal PHP 8.x version so everyone, especially module devs, have a roadmap/timeline for their modules. Even Core modules have issues with PW Dev on PHP 8.1 so I know that this isn't a thing we could or would see in the next 3-6 months. Still somehow developing with the latest and greatest PW/PHP seems a bit wonky (sometimes). To make it absolute clear here: Even though it sounds like I am complaining (which is fair, and true), it's more that I am worried. I have had 2 encounters now were people asked me why certain errors/warnings show up. They used a PHP 8.1 setup AND the latest PW DEV with some of our awesome modules as they were curious and wanted to try it, after I pushed them towards it. I did miss to say: Don't use PHP 8.1, which is a hype right now. Sorry! This is more a feeling, than a fact.

I wish I could help in one way or another but for now I just can say... it works... as expected. PW 3.0.220 - PHP 8.1 - DDEV What's your setup looking like: - Which PHP version? - Which environment? - DDEV, XAMP, MAMP, Laragon? Did you clear the compiled files and made a refresh after that? /adminurl/module/# (at the bottom) CLEAR COMPILED FILES

[See this post as a PUBLIC DRAFT for an upcoming post / aka thought dump] It's just a thought in my (confused) head right now... but shouldn't we, ProcessWire, the Community, and the ProcessWire Module Devs somehow focus/target a master release/version with PHP 8.1 as minimal version in the near future? Not only for ProcessWire itself but all modules. I'm not talking about ProcessWire 4.x but maybe 3.1.x or 3.2.x or something? Just to have a clear cut in some way. Almost everyone I talk to is looking for and talking about PHP 8.1. Right now there are so many fast moving parts in ProcessWire (CKEditor/TinyMCE, JS Updates, Core Modules split and moving to the database, and what not) itself and in terms of PHP 8.1 - either it works or it's somehow having issues, while everyone seems already working with it.

What exactly is your client looking for and where? In the backend or when the value is displayed on the website?

This doesn't sound good at all. Check access rights on folders and files please. Have a look here: https://processwire.com/docs/security/file-permissions/

Found this quite some time ago: https://upptime.js.org/ Might be a better fit or at least an option.

I really enjoyed this post. Thanks @FireWire It almost feels like home. I almost have seen or experienced all of these issues and scenarios in one way or another. The never ending story of WP... of some kind. Yet... I have to admit that there are a lot of super experienced WP DEVs out there that know a lot about doing there stuff we all can learn from. They really challenge WordPress and not their knowledge. (Shoutout to MonkeyDev/Patrick!) Whenever I or WE (as in Muskaat) have to deal with a WP site, we make it totally clear to just fix that very issue and don't even bother or feel being responsible for any other existing or upcoming issue in that very site/project. ** Without that clear statement, "clients" wouldn't even think about paying us. But with that very clear statement, noone ever questioned us. Especially due to the fact that most of them had a very solid offer for one of our PW Setups/Projects, but decided otherwise. - Yet again... their decision. We are just the FIXERs for their decisions. Most of the time at least. We have seen very good WP projects that were stunning and almost perfect in execution. Yet... at some point there always was an issue. Most of the time, the WP DEV abandoned the project. In most cases we found another WP DEV to fix it but sometimes... we had to go another route. A total rebuild with PW, as we don't do WP/or most other CMS/Frameworks. In the last 3-4 years most of our offers were denied and answered with something like this: We knew we were too expensive with our offers - compared to similar agencies and solo-devs. We had to challenge those responses and learned from it over a lot of months and this was our answer most of the time: Sure, that's fine... and yes... they have to be. [BIG PAUSE] Don't worry they will do whatever they can for you and your project. You have our number. Let us know whenever we can help you out.** It paid out at the end. We could move most of the projects over to us and ProcessWire and went from there. We took full ownership of those projects and at least trippled everything from search impressions to clicks. But that's another story. 3 out 4 projects are now long-term partnerships.

Just installed the previous version to get it up and running in my projects - finally. So... this is a very welcomed update or at least a nice surprise to work with. It's weird that I read through the whole docs today and made my notes just to see this update coming in. Be prepared to answer my stupid questions the next days. ?

That's true. And weird enough... I still enjoy using TailwindCSS. I never really used them as they are (for me) something like Bootstrap or UIKIT, or maybe better to say like a theme of some kind. It's a nice to have when you want to scaffold out some prototypes and just need something that looks like the feature you need at the end. And I sometimes look up how they create their markup for components or implement some TailwindCSS features. Would I use them in a client project? Probably not. Maybe cherrypicking parts but that's it. As I am not the biggest fan of JavaScript I most ofted go for the easiest route: using my collection of Vanilla JS snippets for all kinds of things, like toggles, off-canvas navigation, modals and these basic needs. When it comes to carousels I really enjoyed OwlCarousel in the past, as it had all I ever needed and could easily be enhanced in all different ways. Nowadays I'd probobaly go with either GlideJS or SplideJS. Both are robust, lightweigt and flexible. When we come to more custom interfaces or projects I tend to use AlpineJS. Similar to TailwindCSS you can just start writing and are almost there. It can get a bit tricky at first when using $store/$persist but it's worth it.

Do you have a backup of your config.php file prior to any changes or maybe something in Git? Somehow this sounds like a messed up $config->userAuthSalt or $config->tableSalt.

Are we talking about the page with ID 2 in which you changed the name/URL? It might throw you out of the backend but accessing the new name/url should end in the regular ProcessWire backend as usual. Just tried it and all links are working. Maybe clearing all compiled files or deleting local cookies might help in your case.

Wouldn't it be possible to use Github Actions for this? Just a theoretical thought - as I already made my peace with NPM workflows in my local setup. In theory you could create a workflow that does what PurgeCSS/TailwindCSS workflows would do. So there wouldn't be the need of build-tools on your side/in your workflow.

A small step to world domination! Love the idea. ? So, just updated the file, tested again, added a {bracket} value. No issues. Everything works as expected!

So... I updated to the version you linked in your post. No errors while updating. New module settings page looks great and works as expected so far. I added query paramters just to test them: And got this: Only updated relative links are affected - as far as I can see right now.

Ok, I missed this detail somehow. These additional options are awesome for internal linking - at least in a solid setup.

Are we talking about this? https://support.plex.tv/articles/sonic-analysis-music/ I might want this. Or at least might want to try this. Does PlexPass Sonic only uses local media or is it possible to somehow put Spotify, Deezer, YouTube into it as well?

Another follow-up video: Is anyone here using ProcessWire with React, Vue, Svelte or any other JS framework?

It actually does... just tested it. But you can - as always - actually miss it. The first time ProcessWire notices this, it's a large notification... from then on it's somewhere hidden. The good thing: most of the time this isn't really an issue. Well... yeah, this community is probably one of the best you can find. But to be honest and fair here, not all questions are that easy to solve. Some take a bit more time.

Why don't you put all the posts directly under /campus/ instead? That would result in page/post urls you are looking for. Or do only appear some of those posts under /campus/ once in a while and only there? That would be possible with a URL hook as shown by Ryan in the example. Minor changes necessary of course. Just in case you really want to have some posts under /blog/ AND /campus/ this would result in duplicate content and you would have to fix this with canonical tags. Some more questions just to understand this better: Why do you want to mix different content types (posts, news, ...)? I can get that but why would it then be necessary to change the URLs?