Leaderboard

I hope that you all are having a great week! This week I've been working on some updates to the User Activity module and have released version 5 in the ProDevTools board. This version focuses on adding several new requested features, including the following: New options to also detect when you (yourself) are editing the same page in 2+ windows and when you have modified a page in a different window. These are the “collide-self” and “modify-self” options in module config. The module now keeps track of what fields have changed in the page editor and stores them with the activity so that they can be shown in the activity viewer or in page edit alerts. When a page has been modified that is also open to another user it now presents them with a dialog giving the option to reload the page or keep editing. A new “lock” option has been added that blocks a user from editing a page when it is already being edited by another. This is an alternative to just warning them with a pop-up, and it literally prevents them from being able to open the page in the page editor. This can be enabled in the module config and can also be optionally disabled for superuser. A new configuration setting has been added that lets you configure the refresh time in the page list (previously it was not editable). Added feature to limit the “you've been idle for awhile…” to the page editor only. When enabled, idle is still tracked for other admin processes, but idle alerts don't appear. Improvements to ProcessUserActivity (the included activity viewer module), including: 1) visible vs. hidden states are now more obvious. 2) Changes made in page editor are now included in the activity information. 3) The ajax drop-down navigation summary has been improved to include more information. Large portions of the module have been refactored into separate classes for better maintainability and other related improvements. This week there have also been a few commits to the core, but mostly just small fixes and phpdoc improvements, so not enough to write about here, but there likely will be next week. Thanks for reading and have a great weekend!

HTTP/2 makes things more efficient, but it doesn't completely eliminate the overhead of downloading multiple files. As long as those files are the kind that "must always be loaded" (and "must always be loaded together"), I'd still say that the best practice is to merge and offer only one file to download. Cases where merging makes little sense or might even have negative effect include scripts/styles that are only needed some of the time (e.g. big JS app related to single page/template, which the visitor may never encounter), JS/CSS that is intentionally split so that it gets loaded before other content (e.g. styles for the above the fold content), bundles where some parts are regularly updated while others remain as-is for long periods of time (i.e. having to invalidate cache for entire bundle unnecessarily often), etc. If merging has to happen real-time, server resource usage / resulting delay would further diminish the benefits. So merged scripts/styles should preferably be served directly from disk, as static files. Just my two cents. Not exactly a simple topic ?

As usual, everything you touch transforms into gold.

Only if a product can have multiple vendors ? So probably not… ? Just have a Look in modules-> Core -> install (available since PW Version 3.0.184)

Check out the Options Fieldtype.

Do you mean decimal field? Float is not the right field for prices ?

Details/data like vendor, seller, brand or similar could be set as a reference (page reference field). That way your data is super clean and easy to maintain (imagine a seller changes its name and you have to change it 100s of pages compared to one page when using references. This way you can also create individual pages or list for all those data-types - like a list of all brands, sellers, whatever you could imagine. I would create templates for whatever makes sense. Products get the product template, maybe even create different templates for different product types, like books, toys, movies. It depends a bit on what's actually existing in terms of products. Same with other templates. Maybe vendor and sellers are identical with the same details, so you could re-use that template but I'd personally would create separate ones just to have it easier with selectors later on. So you can right away look for vendors and sellers just by template name. That's in the frontend I guess. That's easy. You decide which part is a link, what data is shown and so on. In terms of template... the same. You decide which template is used at what point. What you are looking for is a float decimal field. You can choose this option while creating a field. What's the difference between promo and featured? Is there a voucher available when it's a promo? Either way it might be able to just use a checkbox. But that means you have to manually update all products that aren't a promo/feature anymore. The definition of new could be a checkbox as well or you use the created and/or modified date of a product page.

v1.15.0 improves debugging even further and shows where the assets have been injected ? <!-- loading /var/www/html/site/assets/RockMatrix/matrix/QuoteSlider.less --><!-- RockFrontend.module.php:365 --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Spacer.less --><!-- RockFrontend.module.php:365 --> <!-- loading /var/www/html/site/assets/RockMatrix/matrix/Team.less --><!-- RockFrontend.module.php:365 --> <link rel='stylesheet' href='/site/templates/bundle/head.css?m=1660221858'><!-- less compiled by RockFrontend --> <link href='https://use.typekit.net/zeg8qpc.css' rel='stylesheet'><!-- _main.php:5 --> <link href='/site/modules/RockFrontend/Alfred.css?m=1660215428' rel='stylesheet'><!-- RockFrontend.module.php:152 --> <!-- DEBUG enabled! You can disable it either via $config or use $rf->scripts()->setOptions(['debug'=>false]) --> <!-- autoloading of default scripts enabled - disable using ->setOptions(['autoload'=>false]) --> <!-- rockfrontend-scripts-head --> <script src='/site/modules/RockFrontend/livereload.js?m=1660249767'></script><!-- RockFrontend.module.php:197 --> <script src='/site/templates/uikit-3.15.2/dist/js/uikit.min.js?m=1659941286' defer></script><!-- _main.php:8 --> <script src='/site/templates/uikit-3.15.2/dist/js/uikit-icons.min.js?m=1659941286' defer></script><!-- _main.php:9 --> <script src='/site/modules/RockFrontend/lib/alpine.min.js?m=1660215427' defer></script><!-- _main.php:10 --> <script src='/site/modules/RockFrontend/RockFrontend.js?m=1660215468' defer></script><!-- _main.php:11 --> <script src='/site/modules/RockFrontend/Alfred.js?m=1660250581'></script><!-- RockFrontend.module.php:151 -->

That looks like the way to go to me. There's no way you can hack the Access Roles form as shown in your image, as all the relevant methods are protected an unhookable.

Hi Carl, welcome to the PW forums! Sorry, it’s not clear to me what $award and $tt are in your code? Also, it looks like you’re getting a table row into $opday and then never do anything with it? But yeah, modifying a specific item is described in the module’s readme: $page->of(false); // turn off output formatting, if necessary $award = $page->awards->first(); $award->title = "Most Sustainable Building"; $award->date = "2014-05-01"; $page->save('awards'); (I only have an exceedingly old version, your readme may differ.) Btw, there is a dedicated support board for ProFields, if you have access (I don’t).

Hi @HMCB Currently it is not so easy to provide an default value option for number fieldtypes other than Integer, because all core number Inputfieldtypes using the same rendering function: InputfieldInteger::render(), converting any init or default value to int. So currently there is no option to define default values with decimal places. The core InputfieldFloat and / or InputfieldInteger needs an update to allow default values with decimals. In a second step number fieldtypes could include an option to define a default value. I wrote a Module as a workaround until the core issues are fixed. https://github.com/kixe/FieldtypeDecimalPlusDefault

Thanks @bernhard and @Jan Romero. I didn't think of how status works as a bit field, and I've never used the bitwise 'or' operator in a selector. The code snippet with Page::statusHidden is very useful, thank you. The part of the documentation I found confusing was in the selectors documentation where it says, "Pages with hidden or unpublished status will not appear in the results from database-querying selectors that can return multiple pages (i.e. functions that return the PageArray type). For instance $pages->find(), $page->children(), etc." However, I understand it now. Thanks @Robin S for explaining the underlying logic to why $page->children() and $page->parents() work differently with hidden pages. I can see from your linked post how this has been discussed previously. Unfortunately, in my forum searching before asking this question I didn't come across your post – so thanks for pointing me to it.

I'd say that these are more like two sides of the same coin: You've solved the file issue by directing static file requests to CDN and pointing file related requests to a single (?) master instance. This is of course a valid approach, but in this type of setup you've got at least two types of instances (read and read-write), which can make things more complicated than just replicating a single instance type based on the load, and may not work so well for sites that often require direct access to assets. This could also potentially impact fault tolerance: in case you indeed only have one write instance, that going down for any reason would be a big blow. Most cloud setups I've worked with have handled this the other way around: files offloaded to external buckets and database shared among instances. One benefit of this is that those instances are identical, there's no "master" to rely on. In most cases S3 hasn't had major impact on performance (plus there's always CDN) and I've never run into a case where database would've been an absolute bottleneck. Of course DB requests should be limited: most web requests can be served from static cache, and if advanced caching is needed, in comes Redis. The long story short is that I believe core level ability to store files somewhere other than local disk would be a splendid improvement for cloud use. It's true that you can get past this and it's not strictly necessary in order to run ProcessWire in the cloud, but it would simplify things quite a bit. That being said, I definitely get what you mean by this being the more complex part ? Also, just to be clear, I think that the database abstraction is a great addition!

@MrSnoozles @teppo This is not a limiting factor in scalability at least. First off, at least here, the file-based assets are delivered by Cloudfront CDN, so they aren't part of the website traffic in the first place (other than to feed the CDN). If you wanted scalability then you'd likely want a CDN serving your assets whether using S3 or not. But a CDN isn't a necessary part of the equation in our setup either. File systems can be replicated just like databases. That's how this site runs on a load balancer on any number of nodes. Requests that upload files are routed to node A (primary), but all other requests can hit any node that the load balancer decides to route it to. The other nodes are exact copies of the node A file system that update in real time. This is very similar to what's happening with the DB reader (read-only) and writer (read-write) connection I posted about above, where the writer would be node A and there can be any number of readers. Something like S3 doesn't enhance the scalability of any of this. Implementing S3 as a storage option for PW is still part of the plan here, but more for the convenience and usefulness than scalability. You can already use S3 as a storage option in PW if you use one of the methods of mapping directories in your file system to it. But I'm looking to support for it in PW more natively than that. It is admittedly more complex than the DB stuff mentioned above. For instance, we use PHP's PDO class that all DB requests go through, so intercepting and routing them is relatively simple. Whereas in PHP, there is no PDO-type class that the file system API is built around, and instead it is dozens of different procedural functions (which is just fine, until you need to change their behavior). In addition, calls to S3 are more expensive than a file system access, so doing something as simple as getting an image dimensions is no longer a matter of a simple php getimagesize() call. Instead, it's more like making an FTP connection somewhere, FTP'ing the file to your computer, getting the image dimensions, storing them somewhere else, then deleting the image. So meta data like image dimensions needs to be stored somewhere else. PW actually implemented this ability last year (meta data and stored image dimensions). So we've already been making small steps towards S3-type storage, but because the big picture is still pretty broad in scope to implement, it's more of a long term plan. Though maybe one of my clients will tell me they need it next week, in which case it'll become a short term plan. ?