wbmnfktr

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?

At first it did sound like a namespace issue but the module has a namespace so I threw it in a demo instance: No issues so far. Installed without errors, output is minified. ProcessWire 3.0.210, PHP: 7.4, 8.0, 8.1 @ZAP Can you please check that there is no other copy of that module in place. Maybe with a different folder name or something.

I really enjoy your insights and view on this. Especially with the shown example. ? Exactly that. I really enjoyed that video. Even though I really didn't care about his background in first place. The video title was all I needed to watch it.

I don't know if this was discussed already before... so in case you need to check if PrivacyWire is enabled to show/hide things, like a custom cookie-settings button or link. This is how you check if PrivacyWire is enabled: // needs $config->useFunctionsAPI = true; $privacyWireModule = modules()->get('PrivacyWire'); // check if PrivacyWire is active $privacyWireIsActive = $privacyWireModule->is_Active; // down in your template if($privacyWireIsActive) { // do whatever you need }

It's actually about PHP/Laravel as a backend/middle-man solution instead of all these JS/node.js solutions around and the benefits it brings. The main focus, at least in 2 of the 3 videos, is still somewhat how it works with JS-frontends but still a nice change compared to most other topics in that sphere. You might want to watch or at least skip through some of the videos, the last one is fairly short, to get an impression. It's super interesting, not because of the JS stuff, but because of what Laravel offers and what some see as easy setup and solution compared to what they build as a final product (portfolios, blogs, and such more minimal projects).

Just something I stumbled across and noticed the last few days/weeks. More and more Devs (mostly from the JS-sphere) are talking about PHP, and not only about the latest JS framework trends. There is a downside as they are talking about Laravel most of the time, yet it's something I didn't expect.

@ryan That's correct. Those messages appeared right after I upgraded to 3.0.219, coming from 3.0.217. At least that was what I thought yesterday. I just gave it another try starting with a fresh database backup from production, and everything went perfectly fine without any issues going from 3.0.217 to 3.0.219. I really can't remember I ever tried the 3.0.218 in that setup and moved back/down to the 3.0.217 again. That wouldn't make any sense at all. I made a big downgrade to 3.0.165 a while back for testing purposes but that shouldn't result in issues here. This is how it looked this time: I will keep an eye on this as I want to upgrade some more local setups to the latest dev version. And those definitely never ever saw a 3.0.2xx version before.

Just dropped the latest/3.0.219 into a local dev instance and was greeted with this: Besides my gastro modules nothing makes sense here (for me) and I can't find the source of this issue. Unfortunatelly moving back to another version of ProcessWire didn't solve the issue. I had to import an older version of the database as well.