Leaderboard

I'd like to hear what software you self-host and that act as an alternative for a cloud-based offering. It doesn't have to be FOSS, commercial is OK too. Some of my go-to ones, beyond ProcessWire and LAMP, are: Uptime Kuma: an uptime monitor (recently discovered this and it's earned a spot on my 'tools' server) https://github.com/louislam/uptime-kuma Postal: open-source mail delivery platform (recently discovered this as well; acts as an alternative to Mailgun, Sendgrid). https://docs.postalserver.io/ Invoice Ninja: I already have my own custom project/bookkeeping/invoices system that I built and maintain with PW, but I'd probably use this if I didn't go that route https://www.invoiceninja.org/ RocketShipIt: self hosted shipping API (has a cloud option as well; commercial but very good pricing; alternative to EasyPost and similar services) https://www.rocketship.it/

Gitea. I’m using it on Windows and it’s literally a a single executable that you swap for updates. Run it as a service with a Sqlite file next to it, done. Straight bussin, as I believe they say. https://about.gitea.com Also, I made my own little Pocket/ReadItLater thing using ProcessWire when Pocket started to get incredibly annoying a couple of years ago. It’s not presemtable, but I use it every day, lol.

New off-topic: The moment you remember you can easily disable mandatory fields in FormBuilder with just a few double-clicks and can finally stop entering data into 20+ fields. ??

This (GUI for querying results by field name) is now available. The "field" filter is disabled by default, but can be enabled via module config screen. Stored data may contain removed fields, so free form input is required, but a simple datalist HTML element seemed to work nicely for providing suggestions based on currently existing fields:

@BarryP What is a "loss map"? Are you talking about this "Home" image without src value? Processwire templates are inside the directory site/templates. You probably have a home.php, that is the starting point for the home page display.

Ok great, thx ? RPB blocks inherit permissions from the page where the field lives on. Would be great to mark this as [solved], thx ?

Hi @bernhard, Thanks for the reminder. I'd forgotten about this, but you prompted me to take another look. Since my original post I've added RPB to a couple of other sites, and the trash icon shows up just fine for non-superusers. So it made me think this was a problem just with that one specific site. The site in question has a lot of templates and a much more granular set of permissions for the non-superuser (editor) role. I had the "page-delete" permission checked for that role, and then had certain templates where this was revoked, one of which was the home template: And when I unchecked that checkbox for the editor role, suddenly the trash icon appeared on all the RPB blocks. I guess I don't need that revoke, since I don't think you can delete the home page regardless. Anyway, that seemed to be the problem, and it's now working, so I'm happy ?. Wondering if this behaviour is because the RPB blocks are children of the home page, and whether that has a bearing on the issue. Regards, Ian.

DDEV + PHP8.1/2/3: No warnings.

So... at this point you, @BrendonKoz, and others should post all details about their setups to find the issue. Those warnings might not have an impact, BUT they are a very bad look when trying/installing ProcessWire for the very first time. For my current DEV-setups: latest DDEV (Host: Ubuntu 23.10, not virtual) PHP 8.2 MariaDB 10.4 Apache FPM InnoDB, utf8mb4 Latest successful ProcessWire version: 3.0.241 For my current PROD-setups: PHP 7-4 to 8.2 MySQL v. ??? on webgo, and whatever on Hostinger Apache - not sure how it runs there (webgo, Hostinger) InnoDB, utf8mb4 and a lot of MyISAM with utf8 and utf8mb4 ProcessWire from 3.0.165 to 3.0.241

Yes, this happens to me with every fresh install when using PHP 8.0+, at least since version 210. There seems to be no culprits and I am just ignoring this as it is only the installer which produces these. I got used to it ??

Nothing like. Not even similar in the last couple of months. Even when installing it into an Nginx environment. And the worst part... not even a clue where to look. Is there more in the logs of either PW or Apache or Docker? Just installed a 3.0.241 (fresh download) a couple of minutes ago without issues (PHP 8.2, MariaDB 10.4 via DDEV).

You could always add your own stylesheet in /site/init.php like this: $this->addHookAfter('ProcessController::execute', function (HookEvent $event) { $this->config->styles->append("/site/templates/css/adminstyles.css"); });

I'm not a PHP expert, I use this language since a few years but only intensively since last year. And I just found the spaceship operator <=>. A few days before I implemented an ArrayUtils::floatCompare() because I found bugs in my code where I compared floats like int, because usort callback function return value is an int and I was returning "$float1 - $float2"... followed by the implicit cast to int... not perfect sorting. ? I know I've already read about this 'spaceship.' I remember the name, but probably it wasn't the right time to fully understand its meaning. ^^ Did you know this operator? EDIT : thanks to the moderator who pinned this topic, I owe you a beer! ?

Just a follow up here for those who haven't found the Github issue: https://github.com/processwire/processwire-issues/issues/1952 It looks like the next version of Apache (2.4.63) will include a fix (https://github.com/apache/httpd/commit/a1a93beb58b81f1de2b713ae5f96c41ed5952a74) that should hopefully prevent this from being an issue for PW.

This seems to work because PW contains this “abnormal request” fallback, where it looks at $_SERVER['REQUEST_URI'] directly if the ”it“ query parameter is missing: https://github.com/processwire/processwire/blob/e508cfa2a74971490d6045bd5eb6f2a198d37037/wire/core/PagesRequest.php#L537 It involves some additional processing, removing the query string and PW’s subdirectory.

@adrian you probably saw already that there's a flag you can add to the rewrite rule in htaccess to allow the encoded question mark: https://httpd.apache.org/docs/current/rewrite/flags.html#flag_unsafe_allow_3f But who wants to reopen a fixed security hole? It seems like this Apache change will affect a lot of websites as the built-in URL encoding functions in JS and PHP don't make any special exception for the question mark character, and it's surely not that rare to pass an encoded URL as a GET parameter. So it seems like the options are to specifically replace the encoded question mark with ? after getting the return value from a URL encoding function, or to use a completely different encoding like Base64 if all or part of a URL needs to be used in a GET parameter. Edit: I've created a topic in the ProDevTools support forum to draw Ryan's attention to this discussion. Oh, you already PMd him so that probably wasn't necessary.

Turns out I can reproduce a forbidden error by simply loading a URL like http://pwtest.test/about/?id=%3f It seems like you need to view a page that isn't the root url (hence the about child page) and that you have %3f in there. On some servers http://pwtest.test/about/%3f this also returns a 403 but on others I need the %3f to be part of a URL parameter. This Drupal ticket reports the same issue and references the same apache change that Robin noted: https://www.drupal.org/project/drupal/issues/3460799 If I make a similar change to PW's htaccess rule (as was changed in Drupal), ie: change: RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] to: RewriteRule ^(.*)$ index.php [L,QSA] or: RewriteRule ^ index.php [L,QSA] then everything works again. I expected that would break PW's page routing and/or admin, but initially it looks to be OK which honestly seems weird. So other than the issue with UserActivity, we'll all need to be careful if we ever url_encode anything with a question mark (%3F) in it unless @ryan thinks an htaccess change like (or similar) that would be ok. Perhaps it will need some reworking of some of the $GET['it'] related code in PagesRequest.php to handle all scenarios? Also, I just discovered that the server with what I thought was an old version of apache, was actually not old - I almost exclusively run Debian servers, but the "old one" I mentioned is Ubuntu and someone else is managing it now and they did update to 2.4.41 which in Ubuntu world includes that %3f fix: https://launchpad.net/ubuntu/+source/apache2/2.4.41-4ubuntu3.19

Thought this might be interesting for the UIkit/Tailwind users, maybe best of both worlds?? https://www.franken-ui.dev/docs/introduction