Leaderboard
Popular Content
Showing content with the highest reputation on 11/09/2024 in all areas
-
This week on the dev branch, we have a new $page->preload() method that enables you to preload multiple fields in one query (in this GitHub commit). This is kind of like what the autojoin option does (when configured with a field), or what the $pages->findJoin() method does, but with one big difference. Those options happen as part of the page loading process. Whereas $page->preload() can be applied to a page that has already loaded. Here’s one example where you might find this useful. Say you have a page living at /products/product/ and it has a hundred fields. At the top of your template file that renders the page, you could have a $page->preload(‘field1’, ‘field2’, ‘field3’); to preload all those fields before outputting them. This enables you to load field1, field2 and field3 in 1 query rather than 3. On your first call to $page->field1 it won’t trigger a load from the database and instead will return the value that has already been preloaded. You can also call $page->preload(); without any arguments, and it will preload ALL the supported fields for the page. In reality, ProcessWire is already pretty quick with loading fields, so you probably won’t benefit from preloading until the scale is quite large. While developing this, I was testing by iterating 500 pages and accessing 50 different fields from each. Without preload this took 12 seconds. With preload it took 6 seconds. So for this particular case, preloading cut the time in half. I’m not a query counter, as very often lots of simple DB queries are faster than a single big query, but I’ll mention that it also reduced the quantity of database queries by more than a factor of 10. For this large scale case, that meant more than 20000 queries down to well under 2000. Like with autojoin, there are some limitations with preloading. It supports primarily Fieldtypes that use the core loading mechanism. Some Fieldtypes (especially non-core) override this, and preload() skips over those fields. It also skips over most FieldtypeMulti (multi-row fields), but FieldtypePage is supported when used with Page fields that carry one value. Multi-value can be enabled for testing with an option you’ll find in the function $options, but like autojoin, is limited by MySQL’s group_concat limit. By default that limit is 1024, which supports 140-170 page reference values in a given page field. That's quite a lot, but I don't want to assume folks won't go over that, so it's disabled by default. I’m guessing that most won’t need the preload() function, but a few might really benefit from it, especially at larger scale. So I think it’s a worthwhile addition to the core, and another method that answers a need that may arise as an installation grows, further supporting ProcessWire’s ability to scale up as needs do. Though consider it experimental and "work in progress" at the moment, as we’ll need to do more testing to make sure it is fully stable in a broader range of situations, and further improvements are likely. Special thanks to @tuomassalo at Avoine who came up with the idea for preload() and helped me to get started developing it. Last week I told you how Pete, Jan and I met up in Holland. I also wanted to mention, a couple weeks ago, right before I left for Amsterdam, Oliver from @update AG (update.ch) in Zürich, Switzerland sent me a DM saying that he was in my neighborhood, so we got together for coffee near my house. They’ve been using ProcessWire at Update AG almost as long as PW has been open source, so it was good to meet another long time ProcessWire user, and a nice coincidence that he was in the neighborhood. It’s always great to meet ProcessWire users in person and I hope to meet more of you in the future as well. Thank you for reading and have a great weekend!14 points
-
Is preload() already available in the DEV branch? I'm asking because the version is still 3.0.242. What would be the best way to really test the performance boost here? Need to try this in a recent project. Maybe we should create some kind of meetups in the US and maybe even in the EU next year. That would be fun.4 points
-
Big thumbs up for that idea. If the timing is right, I might even make it to both, since I'm planning to head across the pond and hike the John Muir Trail next summer. Love the preload method. I've got a shop solution built on PW with about 120k orders and 150k order positions by now, all as pages. Performance is becoming a bit of an issue in the backend with long range price change statistics and detailed Excel exports, and this seems like a perfect use case.2 points
-
Usage: echo rockmoney() ->parse("1,4") ->minus(0.4) ->format(); // 1,00€ Why? The short answer is, because 0.1 + 0.2 is not 0.3 in computer world: Download & Docs: baumrock.com/RockMoney1 point
-
TinyMCE itself supports this via the style_formats setting, where you would define a "class" value rather than a "classes" value, e.g. style_formats: [ { title: 'Table row 1', selector: 'tr', class: 'tablerow1' } ] But PW's implementation of TinyMCE doesn't provide a way to directly control this setting and instead parses the contents of the "Custom style formats CSS" config textarea into the style_formats setting. Situations like this are why I think PW should provide a hookable method allowing the array of data that becomes the TinyMCE settings to be modified at runtime, as mentioned in this issue: https://github.com/processwire/processwire-issues/issues/19811 point
-
I hate to break it to you, but... you are now 😉 Seriously though, thanks for sharing this module!1 point
-
Well, you get all kind of weird rounding issues if you do that. Of course you could round() all results, but that is tedious and I'm not sure if that's 100% bulletproof:1 point
-
$role->branch_parent is what you're looking for rather than admin_restrict_branch. But otherwise your example code should work.1 point
-
Following the advice of some PW-forum members @gebeer @dotnetic @bernhard @sebibu, I would like to share my first Processwire module with all members. QuickSave: My first attempt at developing a PW module to quickly save a page. What can the module QuickSave do: Quickly save a page edit in the admin and return to the last activity. Adds an extra save button AND shortcuts CMD+s and CTRL+s. QuickSave includes an additional plugin for TinyMCE. The plugin for TinyMCE must be assigned and activated specifically for these textarea fields. (Keyboard input shortcut does not yet work in an iFrame - RTE/iFrame, CKE, etc.) PW-QuickSave-1024-v16.mp4 Installation: To install the module, it simply needs to be copied into the Processwire module directory and then activated in the Processwire admin. Optional: Anyone who uses TinyMCE can activate the keyboard input shortcuts via the configuration as a plugin for TinyMCE. Afterwards it has to be activated for the field (e.g. body). This is the path for the configuration in TinyMCE: /site/modules/QuickSave/tinymce/quicksavetinymce.js QuickSave-TinyMCE-inst.mp4 I have been using the module only as a save button version for some time in a long Processwire page with a strong content and a four-fold nested repeater matrix and it works. The keyboard shortcuts were added because of a request. I was only able to test these on the Mac and hope they also work with Windows browsers. Due to another request, the short notification after saving was added. I hope you like the module and that it helps the moderators to keep a better eye on the areas they are currently working on. Especially with long pages and, for example, a table with many rows, it is very helpful for me not to lose the row when saving. (see the video) Note: The module does not intervene in the Processwire saving process, only the original saving button function is triggered. Please note that the keyborad shortcodes do not work in iframes or CKEditor. UPDATE: New version 0.1.7 added on April 13, 2024. A new combined version without jQuery has been created. Thanks to @dotnetic and all others ?. It is now more optimized and further optimizations are planned. Module 0.1.7 Download: QuickSave.zip Feedback on whether the keyboard shortcuts ctrl+s work under MS Windows would be great... ? Thanks and Greetings Chris1 point
-
Hi, if you want to hide/protect your entire ProcessWire page from unwanted visitors (and bots), you could add the following lines to the end of your .htaccess file in your PW web root to force basic auth protection. In addition I commented out some lines in the default .htaccess file to force HTTPS and non-www like https://domain.com. # 9A. To redirect HTTP requests to HTTPS, uncomment the lines below (also see note above): # ----------------------------------------------------------------------------------------------- # Comment out the two lines below to force HTTPS requests. RewriteCond %{HTTPS} !=on RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301] # 13C. Redirect www.domain.com to domain.com (do not combine with 13A or 13B): # ----------------------------------------------------------------------------------------------- # Comment out the two line below to rewrite URL to non-www. RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC] RewriteRule ^ %{ENV:PROTO}://%1%{REQUEST_URI} [R=301,L] ################################################################################################# # END PROCESSWIRE HTACCESS DIRECTIVES ################################################################################################# ################################################################################################# # Basic auth protection to hide site from unwanted guests, search engines and bots. # To not ask credentials twice, we allow non HTTPS and WWW first. After ProcessWire redirected # request to non-www HTTPS, we prompt for credential for the basic auth once. ################################################################################################# # Detect LOCALHOST env or WWW subdomain. SetEnvIf HOST ^localhost LOCALHOST SetEnvIf HOST ^www\. WWW # Basic authentification AuthType Basic AuthName "Restricted area" AuthUserFile /kunden/path_to_your_webroot/.htusers # Deny access to all, except for LOCALHOST, WWW, HTTP or valid-user. Order Deny,Allow Deny from all Satisfy any Allow from env=LOCALHOST Allow from env=WWW Allow from env=!HTTPS require valid-user You can create the password hash for the .htusers file (username:hashed_password) with the PHP commands below. Don't forget to adapt the path in AuthUserFile to match your .htusers file in your .htaccess file too. <?php // Create a password hash for Basic Auth. $user = "your-username"; $plain = 'your-password'; $hash = password_hash($plain, PASSWORD_BCRYPT); // Output required .htusers data on screen. echo '<h2>Data for .htusers file in PW webroot</h2>'; echo '<p><strong>PATH</strong>: ' . __DIR__ . DIRECTORY_SEPARATOR . '.htusers</p>'; echo '<p><strong>username:hash</strong>: ' . "$user:$hash"; Have fun. cwsoft1 point