Leaderboard

For a production site, I wouldn't use PHP 8 yet. It hasn't been enough time to find issues with ProcessWire, as well as for module authors to fix new issues. Is your site up-to-date? Current PW master version, all modules up-to-date and no abandoned modules in use? In this case, PHP 7.4 is very stable, works well with current ProcessWire versions and will be supported for another two years. We've been using it for a while now, so I can say that at least the core and our commonly used modules (ProFields, FormBuilder, ListerPro, LoginRegisterPro, ProCache, Tracy Debugger and all of my modules ?) work well with PHP 7.4. Through I would be vary if your site uses some abandoned or older modules, especially 7.2 and 7.4 introduced some backwards incompatible syntax changes that often cause issues with older code ... On a development site, go ahead and try PHP 8, and report any problems so they can be fixed. At work I'll install PHP 8 on our development server as soon as it's available in Plesk, and give our ProcessWire base installation a try ? Looking forward to union types and match expressions in particular ...

I am using 7.4 on all live sites and 8 on my local dev setup so I can get my modules updated and help to report any PW core issues so Ryan can get these taken care of ASAP - I know he is typically slow to upgrade so needs us to report. I'll probably start using 8 in production in a couple / few months.

I ran PHP 7.4 for a while, and ProcessWire ran fine. I had to downgrade to PHP 7.1 because of some issues in Matomo though. And they are both on the same host for me.

I upgraded to PHP 7.4 for several projects. The only errors that occured were "array and string offset access syntax with curly braces is deprecated" and I changed it in the according 3rd party (or self-written) modules. Personally I would wait until ProcessWire and modules are known to be compatible with PHP 8. Same as Moritz said. Take little steps instead of one large one.

I'm not quite ready to move any existing sites to 8, but I will be developing all new sites on 8. I haven't seen any PW core showstoppers yet and I am happy modifying any 3rd party modules if the need arises (along with a PR of the fix).

PHP 7.4 here as well. So far I can't remember having any major issues going from 7.1 to 7.2 and then 7.4. Most sites I run are relatively up to date, though, and generally speaking I don't use that many third party modules either. To be honest if there's any reason to worry I'd recommend 7.4, or perhaps even 7.3 (it's still supported for a while and would give some extra time to prepare for a bigger jump.) Probably going to set up a new server on weekend and move some sites there. Might as well go with PHP 8 and see how that goes ?

Currently I am developing a new very small and simple ProcessWire Website with PHP 8 (and I try also enabled JIT) - planned go live Jan/Feb 2021. But for some older bigger Project with many modules and code which is on 7.4 I'll wait some month to upgrade since I had some troubles with php-redis and imagemagick with php8, which I use in this project

@jploch - what about simply using: if($("#tracy-debug").css('display') == 'block') { That will let you know if Tracy is enabled and not hidden.

Announcing the current status, planned release, roadmap and preview of Padloper 2. Status Feature freeze. Full multilingual support. Only PHP 7.2+ supported. Support for ProcessWire 3.0 only. Backend support for modern browsers only (that support JavaScript ES6 modules). Current Work Finish work on admin/backend. Work on installer and uninstaller (including configurable availability of some features). Work on UI/UX improvements. Start work on documentation with special focus on technical documentation. Continue work on Padloper API and data/model component. Roadmap Please note that these ARE NOT hard and fast targets. The roadmap may have to be adjusted to accommodate technical and non-technical constraints. Q1 2021 Inbuilt support for (latest) PayPal (full rewrite, no external modules required). Additional work on Padloper API. Invite a limited number of early alpha testers (fully-priced product). Soft and closed release of Padloper 2. Q2 2021 Start work on relaunch of Padloper website. Inbuilt support for Stripe (no external modules required). Future Plans Support for more Payment Gateways. Support for order, customers, etc imports and exports. Support for AdminThemeReno and AdminThemeDefault. Separate fully-featured frontend shop module. Consider support for multiple currencies. FAQ 1. Have you abandoned this project? No. 2. When will Padloper 2 be released? First early alpha release is scheduled for Q1 2021. This target may change depending on circumstances! Access will be by invite only for this first release. 3. What is the pricing model of Padloper 2? Three licences: Single Site, Developer and Agency licences (12 months’ updates and VIP support). 4. How much will Padloper 2 Cost? No price has been set yet. It will cost more than Padloper 1. 5. Can we upgrade from Padloper 1? No. 6. Will existing users of Padloper 1 get a discount for Padloper 2? No, this will not be possible. Apologies for the earlier announcement. It was unrealistic and unworkable. 7. Can we pay for Padloper 2 in advance? No. 8. Does Padloper 2 render markup/templates in the frontend? No. Access to all data you need to build your shop’s frontend is via the Padloper API. 9. Can we keep sending you ‘Are we there yet’ messages? No, please. Preview Here is a video preview of the current state of the backend/admin of Padloper 2. Please note the following: This is early alpha. There are bugs! It even includes WIP/notes!! FOUC, misaligned things, etc. The video shows the near-raw implementation of Vuetify UI. The UI/UX improvements work is yet to start. What you see here is the development version. Some of the incomplete features may not be available in the early releases. Most of the features you see will be optional to install.

Hi everybody, This is the php support matrix as of today: https://www.php.net/supported-versions.php @adrian has posted some findings regarding PHP8 here: I know someone who is running a ProcessWire installation on a server on PHP7.1 ?? Now I'm asking for this person: What would you recommend to do? Upgrade to PHP7.4 or PHP8 ? I'm a little afraid that PHP8 will bring in some issues and it might be a little too early to jump on that train now. Maybe the transition would be a lot smoother when upgrading to 7.4 now and jumping on 8 around mid-2022 (in 1,5 years). What do you think? Does anybody already have findings to share?

I am curious why you suggested this - I can't think of a reason not to apply it frontend as well?

The answer is right there in the documentation you linked to ?. It's a hidden folder...maybe that's why you couldn't find it?

?. Please see my post above yours. If your purchase date is more than 12 months, then the link has expired. Please confirm that and let me know. I can send you the relevant file to update via email. For anything involving order numbers etc, please either send me an email or a PM. Thanks.

@cjx2240 This depends on the selector you use to grab those pages. In the example, a $post->get is used, meaning it will be retrieved, by-passing restrictions. Are you using similar code? Please see documentation: https://processwire.com/docs/selectors/#access_control ps: I am not sure if ->child is also get-like.

Yes, I don't use the wiki but do not be afraid by those old dated thread - check- they will mostly work, I mean, I installed yesterday a module made in 2013 still working without any modifications on the last dev version. Isn't crazy ? ? - https://www.pwtuts.com/ - https://processwire.dev/ - https://cse.google.com/cse?cx=014789015761400632609:fxrf0rj4wr4 and as always, linking this old thread with old videos which still work with the latest processwire version :

Just an update in case anyone is looking for this, setting arbitrary 3XX response codes is now possible! As of ProcessWire 3.0.166, $session->redirect now accepts an integer as the second argument, which may be any HTTP response code in the 3XX-range. The blog post above doesn't really mention this, but you can see the change in this commit. Thanks @ryan!

That's also a nice solution and both of them could make the thing to work - I still think that the class (applied only to admin side) could be better for future use case in other modules.

WireArray::not() takes a selector argument, not a PageArray. So you could do... if (count($resultsToRemove)) $results = $results->not("id=$resultsToRemove"); ...but wouldn't it be better not to have to remove any results? It's not clear to me why you are doing the unusual thing of searching repeater pages directly instead of the usual thing of searching pages that contain the repeater, e.g. repeater_field_name.subfield_name%=$searchQuery

@VeiJari - you already have the option in your code above: 'namesFirstRow' => true, That will add the field names to the first row. If you want labels instead, then that would be a new option I would need to add. However, I did find a couple of bugs when exporting via the API which I have fixed, so please update to the latest version. I didn't do anything other than upgrade the Table module (and also the PW core) like I mentioned above.

Hard to give a comparison because I've not used the other services but we switched to Cloudways about 18 months ago and they've worked well for us ( much faster than the previous hosting company we used). You get to pick server providers with no need to separate accounts with them so all the billing is in the same place. The control panel does pretty much everything we need to and you can let clients have access to their server if you trust them. We've not had to contact support for anything serious but when we have spoken to them they were responsive and seem to know what they're doing. I suspect most of my Christmas holiday is going to be spent shifting sites from our old provider over to them...

If one day you want to play with dedicated server, you can try to get one from kimsufi, they start at less than 5€ ? but you need to stay a long night refreshing the browser or code a bot to get the server, there are hard concurrence on this at this price. The last thing I made for example it's a server to host a live support chat service (https://github.com/LiveHelperChat) ?

Looks like the OR selector you were trying to use is now working in the latest version v20 that Ryan posted in the PF download thread. Note that this is actually "0.2.0" - I have never understood why he is inconsistent with those version numbers like that ? There are also changes to the PW core around this issue, so you should probably update to the very latest dev commit, although I actually found that what you were trying to do worked before I did that update.

@FireWire - just a reminder to remove the bd($content) call in Fluency.module.php Also, just want to agree with @xportde's request for a dedicated permission. I have already changed it locally to add a "fluency" permission. In my use case I actually needed to give the guest user this permission so that I could do translations via a cron called script. Thanks again for your work on this - I am now using it in production.

Hi everyone, I have released a few PHP 8 fixes over the last week or so, but today's was the biggest with an update to the Adminer core. Unfortunately the automatic login feature of Adminer seems to have been broken for quite some time now, which is why I haven't upgraded it in a while, but now with the need to support PHP 8, I didn't really have much choice. I have managed to implement a hacky way to make the automatic login still work but I'd appreciate feedback on whether you are having any problems with this please. I have of course contacted the Adminer developer about the issue (via the forum because there is no Github issues option ? ) but it's been mentioned by others as well, so not sure what's going on. Anyway, hopefully my hacky way will be seamless enough. PS - not sure what others think, but the context aware Adminer panel is one of the features I use most in Tracy.

I don't have time to dig into this further today, but wanted to let everyone know that with PHP8 I am having some fatal errors. It was kinda OK until I tried to turn on JIT (based on https://stitcher.io/blog/php-8-jit-setup), but after that, the admin wouldn't load - sometimes Tracy would manage to tell me that it was a CSRF exception. I tried disabling JIT, but that wasn't enough. In the end, I had to disable opcache - in my case, that required commenting out the line: zend_extension=/usr/local/opt/php/lib/php/20200930/opcache.so in my /usr/local/etc/php/8.0/conf.d/ext-opcache.ini file. Note that this on my Mac with LAMP stack installed via homebrew. The browser console was showing the following error: ERR_INCOMPLETE_CHUNKED_ENCODING which others have reported a connection to opcache: https://stackoverflow.com/questions/29894154/chrome-neterr-incomplete-chunked-encoding-error Need to read and learn more, but would also appreciate it if someone else has any insights.