Leaderboard

I once asked Ryan if he plans to add language files to his Pro modules. He doesn't plan to do so. His reply was (more or less) that most people using these modules were developers, not authors (clients), and a developer surely understands English. Fact is, many of the Pro modules are not only being used by superusers, so that's kind of a weak excuse. It's a lot of work translating e.g. a Lister Pro language file. Of course, for German, I only did it once, and then copy files over. Other eco-systems have solved this way better imho... On a side-note: Ryan is maybe missing out on marketing arguments here... it would be easy for him to aggregate at least a dozen translations for his modules from existing developers / agencies who bought a license and translated everything on their own. In return, he could give away licenses or free access to the VIP support boards to those ppl who translate Pro module JSON files ( A classical win-win situation ?). For some ppl, it makes a difference if a module is already translated in x languages or just English. That's a robust sales argument right there.

I updated my forked version of AIOM+ to 4.0.0 https://github.com/matjazpotocnik/ProcessWire-AIOM-All-In-One-Minify It adds "AIOM+ template caching" :-) My tests shows noticeable improvements in render times, dropping from like 300 ms (on localhost) to 10 ms. I guess ProCache would be even faster (don't have it, can't test). If anyone wanna try this early alpha version, please read README.md (must read).

The inefficiency I noticed was that the render time (I just use Chrome console with disabled caching, monitoring the Time column) with enabled or disabled template cache was almost the same. I used just a simple template file with the echo "foo"; in it. Then I read about ProCache and learned that it delivers cached pages directly from the disk without even touching the php. I tried this approach on Windows with IIS but the URL rewrite module complained about some caching issues, so I ditched this approach (this is likely IIS issue). Then I tried with php echoing the file from the disk and it worked. I looked at the source code of some core files and discovered that cached pages are actually already there on the disk, but it takes time before PW reaches them: it has to go through the boot process, load/include all the modules/files, etc. and that process takes time. So the module creates its own AIOM+ cache files based on page URLs/names with information about the actual page cache file and its expiration. I check this AIOM+ cache file, load the content and echo it. That process takes between 5 and 10 ms on my computer, while "full" load time is between 300 and 350 ms, and with cache like 300-320 ms. I'm not sure this is a good way to go. My biggest concern is if this is safe? I assume ProCache does it similarly?

Right, this should be fixed now finally. For those that are interested, there was an issue with the forum session wiping out the ProcessWire session by the end of the script - a little puzzling because right up to the end of the script everything seems fine but when you redirect the session information is lost. To overcome that there's some background CURL stuff going on now so the two systems are separated completely during the login process. Please feel free to post/update your profiles again and sorry it took so long.

You need to iterate through all languages and set the name in all of them. After all, they might also have different titles, so you want to use the local title as well. Something like this: function customPageName(HookEvent $event) { $page = $event->arguments(0); if ($page->template->name == 'about-events-single') { $eventDate = date("dmY", $page->global_date_end); $page->of(false); foreach (wire('languages') as $lang) { $localTitle = $page->getLanguageValue($lang, 'title'); $localPageName = wire()->sanitizer->pageName($localTitle . '-' . $eventDate, true); $page->setLanguageValue($lang, 'name', $localPageName); } } } wire()->addHookAfter('Pages::saveReady', null, 'customPageName'); Quick and untested, might need some adjustments, but you get the idea ?

Process Cache Control This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions. The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu: Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides: An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README. Plans for improvements If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind: Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions! Links https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots

I wonder what is currently the best way to ship a module that defaults to english let's say with german translations? I think the translation files have to be uploaded to the relevant language page (eg german) and are then stored in /site/asstes/files/my-german-page-id/... What if I want to ship a module with translation files included? That's currently not possible, is it? I wonder if the PW core should be modified to not only look for translations in /site/assets/files/german-id/my-module-transation-file.json but also in /site/modules/my-module/translations/german/my-module.module.php.json What do you think? Am I missing anything?

This is exactly what I'm doing, but in PHP, check cache() method in AIOMcache.php. I know .htaccess rules, Ryan sent them to me 4 years ago when I was tempted to buy ProCache, but since I'm on IIS he couldn't confirm if it would work. But this is all I know about ProCache, I learned everything else from the documentation pages and I don't know if there is anything else to consider. I use zend opcache on my sites and this helps a lot, they are fast enough so I might not need ProCache or AIOM+ cache, but it's something that I always wanted to try and never had time or will to do it. Now I did it and released it in public, perhaps someone finds it useful or maybe something similar can be part of the core and we all win. Hm, then ProCache wouldn't be needed?

That sounds like a very good enhancement! It would be great to have a solution like this implemented in the core template cache, so it doesn't require any changes to a core file and is available to those not using AIOM+. An important factor is if enough information is known so early in the load process to deliver all the standard template cache features for things like multi-language, URL segments, logged-in users option and cache-disabling GET/POST vars. But a lot of that is knowable from the URL alone so I think your approach should work. If you have time, maybe you could experiment with this separate from AIOM+ and PM Ryan to see if he'd consider adding it to the core? If it works it would add another "selling point" to PW.

Hi @matjazp, I'm not currently a user of this module, but I'm interested in this feature and your comments in the readme: What was the inefficiency you noticed in the core template cache feature and how did you make the AIOM+ cache more efficient? Is there an improvement that could me made to the core template cache that would be worth communicating to @ryan?

Thanks Craig - that's because I was a muppet and used $sanitizer->pageName instead of just $sanitizer->text on a value that's being checked against a non-PW system. By this point it's habit ? Fixed now though for anyone with a space in their forum login name.

Don't you use your browser's "remember login" feature? ? I just logged in successfully. Thanks for your work on this @Pete

Just wanted to let you know that I just tried this. It failed to log in as 'Craig A Rodway', so changed my name on the forum to just 'Craig' and it worked fine ?

Apparently, that's an old question: https://processwire.com/talk/topic/15367-translating-module/ https://processwire.com/talk/topic/2583-delivering-module-translations/ Seems like nothing has changed in that regard in the last years ? I'm sure there would be workarounds, but then every module developer would have to create such a "install multi-language files" routine for himself, and that's hardly efficient (e.g. a menu in your module config screen where you could map JSON file A to PW-language C, and then the file(s) would be moved to the right folder. It would indeed be nice to have that functionality in the core.

Hmm... I think there is still an issue with sessions actually - if you get your password wrong first time you have to close the browser and re-open, either that or it's due to too many login attempts stacking up - but either way without the helpful message popping up like it used to it's impossible to tell. I'll work on this some more now, but if you open a fresh browser window and get your forum username and password correct first time it should let you login to edit your profile in the meantime.

Sorry all, I looked into it a few weeks back and some of the changes in the forum code quickly made what should have been a simple task turn into half a day of headbutting the keyboard in frustration. I'll get back to it today as it's dragged on too long now.

Yes it work ! thanks a lot

I forgot to post here that I could uninstall the module by commenting out this line (as far as I can remember): https://github.com/kongondo/FieldtypeRuntimeMarkup/blob/148626c7d3e9dc16cb9303c96b6f4c5b9ee96a75/InputfieldRuntimeMarkup.module#L68 // $this->rtmUtilities = new RuntimeMarkupUtilities();

So the key information here is that the offsets of timezones are not fixed for eternity. There are databases you can download to your OS or e.g. from groups like IANA, which hold information about which offset a certain timezone was exposed to at which period of time. And those databases are updated about a handful of times a year (but not each time for actual new rulings). A good example for actual changes is the EU, which is currently starting the process of migrating away from switching to/from DST. Generally you're mostly fine for past datetimes, but the farther you're in the future the more likely it becomes the offset you expect the timezone to have at the time could change until that time. If you convert 12.12.2030 10:00 for Europe/Berlin to 12.12.2030 9:00 UTC with the current offset of +1 in the winter and we go forward 10 years it's not clear if you get back 12.12.2030 10:00 for Europe/Berlin. The EU's efforts to remove DST might have been fruitful and Europe/Berlin is now at +2 offset all year (all year DST). So you take the db value of 12.12.2030 9:00 UTC, you add the offset for Europe/Berlin, which then is +2 and you get 12.12.2030 11:00 for Europe/Berlin. The UTC datetime was preserved, but the "wall time" wasn't – wall time being the time I see on the clock here in my office. You might be an hour late to some important appointment. You can ignore all the above if you never convert between timezones, which as far as I can see, is what processwire is doing. 12.12.2030 10:00 for Europe/Berlin will still be 12.12.2030 10:00 for Europe/Berlin when read from the db in 10 years. Essentially the wall time is preserved. This comes at the expense of absolute distance of time between two datetimes being subject to change and not being able to have absolute ordering for dates of different timezones. The latter is not a problem if the whole system just uses one timezone. This is why I said it's important to know what you care for. The absolute time passing by until a datetime or the actual time on the wall on a certain day. If you want UTC timestamps in your db, but not give up preserving the correct walltime you'll need to store more information in the db besides the utc timestamp to be able to react to changes like I described.

I need to build two online stores in the near future. @kongondo, I was wondering if you could share any updates on the progress. Or is it still too early for any kind of announcement? ?

Good thing I marked this as a beta release, because I'm still finding a lot of bugs ? I just pushed version 0.4.0. The module is now no longer autoloaded, because it's not really required anymore. This release splits the module into two seperate Modules: ProcessCacheControl and CacheControlTools. They are still installed alongside each other, and ProcessCacheControl will install CacheControlTools during install. For existing installs, you might have to reinstall the module, or install CacheControlTools manually after the upgrade. Also, the asset version management is now part of CacheControlTools, so the code has to be adjusted: // version 0.3.0 and below $CacheControlTools = $modules->get('ProcessCacheControl')->getTools(); // version 0.4.0 $CacheControlTools = $modules->get('CacheControlTools'); A bit of background for the split: I learned something new about the permission system. If a Process module defines a permission, the current user needs that permission not only to access the Process page in the admin, but also for the module to even be instantiated at all. Because of this, the asset management system didn't work for guest users. By splitting the repository into two modules, I can still have strict access control for the Process part of the module, while allowing the tools module to be instantiated even during requests from guest users. Anyway, the module is now, let's say, nearing stability. I'd like to publish a stable release soon, so let me know if you find any more bugs!

With the new .csv option for exporting translations of multiple files combined it wasn't to bad to get something working: https://github.com/processwire/processwire/pull/52