Leaderboard

I would like to take this opportunity to thank you once again for your fantastic support yesterday and today.

We've switched most of our servers to a setup of Hetzner VPS managed via Ploi. I haven't found many differences between Cloudways, ServerPilot, Moss, Ploi, etc. if all you're doing is hosting simple Laravel or ProcessWire sites. The main advantage seems to be speed here — compared to shared hosting, the sites are between 4 to 10 times faster even when hosted on the cheapest Hetzner instance at 3$/month and with security and updates taken care by Ploi. We liked Ploi because it's great at regular backups, has lots of notification channels for automatic deploys and the admin panel is very polished.

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

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?

The PayPal gateway view is correct! If you use PayPal you won't get a credit card form on Snipcart checkout.

Just had a situation where one of Runcloud utils came in handy, I was able to block a rain of requests coming looking for WordPress stuff with their per-applicatinon Firewall/ModSecurity settings. As someone who isn't really knowledgeable on htaccess or firewall settings, it came in super handy to save face with the client.

Curly braces...around {$item->images->first()->url} <?php <a rel='tag' href='$item->url'>#$item->title <img src='{$item->images->first()->url}'></a>";

Have a look at Media Manager, by @kongondo. It has a cost, but it manages images as pages so you'll be able to add ant kind of field to an image. https://mediamanager.kongondo.com/

@fruid I'm glad the module was useful for you ? I'm not planning to update the module, since I offered an alternative that I consider superior: I think you solved the situation well for your use case. I would advise you to simply change the class and file names of your customised version to prevent any unwanted update. I don't have time to look at it at the moment, but you could also add one more optional parameter to the short tag for the size of the image, and trigger the resizing with the passed value only if it exists. If you wish to share your changes, feel free to create a fork or submit a pull request. Whatever you prefer ?

Hello, Ryan mentioned that he had updated CKEditor , see https://processwire.com/blog/posts/pw-3.0.155/#updated-ckeditor-version-to-4.14.0 I would try a hard refresh / complete cache cleaning of the browser.

Hello kongondo! Really amazing work!!! I have an ecommerce project for my own use in working progress and I really think of to not use processwire, coz there was no infos on padloper 2. Now, I know I will stay with ProcessWire and wait for the release of Padloper 2. It would be an honor to be an alpha tester! One question I have so far: I didn't see in the video for sure, if there are also virtual/downloadable products (My ecommerce project will only have virtual goods) or did I miss something? Once again: RRRRRRRREEEEEEEAAAAAALLLLLLYYYYYY AMAZING WORK!!!

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.

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 ...

@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.

Hi @uliverse Probably on the desktop you are using hard refresh or opening your page while your ChromeDev tools are opened ( where 'disable cache' is checked). Actually, it's normal behaviour when your desktop/mobile browser is caching image, documents etc. There is a submodule in the ProCache module that helps in such a situation https://processwire.com/blog/posts/pw-3.0.98-procache-buster/

Hi @pop You might missed this one topic : Then use google/this tool ? with the right keywords, you will find a ton of topics - thanks @mr-fan And do not hesitate to ask, as you can see, you will get nice answers ?

Two options: No template file for the template the children pages use (direct access to a child URL will lead to a 404). Make the children unpublished (accessing children will result in a 404 unless you are logged in and have view rights to those children). In this case, selector should have include=unpublished.

@LAPS With this new version, there are even more customizations available. Have a look into the comments in PrivacyWire.module. This example code does the same as the one from my post from last Friday, but with the new syntax of the new version: <html> <head> <!-- your head content --> <?php $privacywire = $modules->get("PrivacyWire"); // load the css files echo $procache->link([ $config->urls->template . "path/to/your/stylesheet.css", $privacywire->getPrivacyWireStyles()->url ]); // load the inline script echo $privacywire->renderPrivacyWireConfigAsInlineJs(); ?> </head> <body> <!-- your body content --> <!-- your body content --> <!-- your body content --> <?php // render the required DOM elements echo $privacywire->bodyContent; // render the JavaScript files echo $procache->script([ $config->urls->template . "path/to/your/scripts.js", $privacywire->getPrivacyWireCore()->url ]); ?> </body> </html>

Hey everyone, I did a lot of refactoring of PrivacyWire this weekend - both for the backend and frontend. The Javascript core of PrivacyWire is nearly completely rewritten in ES6. This results in much better readability and of course extensibility. For examle, as asked by @Torsten Baldes, one can now manually trigger to refresh the element detection of PrivacyWire by simple running the following function afterwards: window.PrivacyWire.refresh(); You'll find a brief overview of the updates here: https://github.com/blaueQuelle/privacywire/blob/es6/CHANGELOG.md#101b-beta Right now this update is in an separate branch at github: https://github.com/blaueQuelle/privacywire/tree/es6 I would be happy if some of you could test this version in your dev environment. If you haven't used any hooks or modifications, it should just run without any changes. I'm looking forward to your feedback! ? Best, Joshua

Hello @Ahmad ... You must add a backslash before \AIOM like: <script src="<?php echo \AIOM::JS(array('assets/js/uikit.min.js', 'assets/js/uikit-icons.min.js')); ?>"></script> In this case, the js files are in the assets / js directory ...