Leaderboard

This week I've done some work on the core $cache API (WireCache) to make it able to support other cache storage options. To do that, I had to move all the storage code out of the WireCache class and into a separate class that implements the new WireCacheInterface. So it was kind of a major refactor. Now the WireCache class is independent of storage method, which will make it more flexible in the long term. The first class that implements the new interface is the new WireCacheDatabase. This contains the cache database-storage code that was previously in the WireCache class. But the plan is to also add a WireCacheFilesystem (in progress), and make it possible for others to develop WireCache modules, perhaps for Redis, Memcache, etc. I've been wanting to do this because in some cases I've noticed significantly better read performance from file-based caches. (Though admittedly, at the expense of write performance.) But it made me think it would just be better to have more cache storage options, and also be nice to take advantage of even better cache options available in different environments, like in the AWS environment we run this site on. One of the issues with changing the cache used by the system is that the $modules API (Modules class) depends on WireCache for quite a few things. And the modules basically can't load without the relevant caches being available. At present, $cache has to load before $modules, which makes the whole idea of WireCache-modules a bit of a chicken-or-egg first situation. So I've been working to decouple $modules from WireCache, or at least make it able to function if its cache isn't available on occasion. I made some good progress there, but found that there was a little bit of a performance hit in doing so, so I reverted those changes and put them behind a toggle in the Modules class to experiment with further. But while doing that, I found some other ways to improve the performance of the modules loader. So you'll find the dev branch boots a little faster this week. Maybe not noticeably so (since PW already boots fast), but measurably so. I'm always looking for opportunities to improve performance — even small performance improvements amount to large savings over time. While on the topic of caches, I've also added an experimental $pages->loader()->findCache($selector) method which works exactly like $pages->find($selector) method, except that it caches the page IDs that were found for a period of time that you specify in the 2nd argument (default is 60 seconds). I imagine this method would be useful for complicated or slow page finding operations that don't need to restart from scratch on every request. This is an alternative to markup caching for greater control. But since it caches the result of the find operation (page IDs), and not the actual pages, it has a different set of benefits (and drawbacks) relative to markup caches. I'm still experimenting with this method to get more feedback and make sure it's worthwhile, so far it appears to be. This will likely become accessible at $pages->findCache() once out of the experimental stage. That's all for this week. Thanks for reading and have a great weekend!

Bummer about the Selectize issue. I think it might be the cause of this too: https://github.com/processwire/processwire-issues/issues/1736 A hook to substitute a textarea for the toolbar config without editing the core: $wire->addHookAfter('InputfieldTinyMCE::getConfigInputfields', function(HookEvent $event) { /** @var InputfieldWrapper $wrapper */ $wrapper = $event->return; $toolbar = $wrapper->getChildByName('toolbar'); $replacement = $event->wire()->modules->get('InputfieldTextarea'); $replacement->rows = 3; $settings = [ 'name', 'label', 'description', 'icon', 'textFormat', 'themeOffset', 'notes', 'value', ]; foreach($settings as $setting) $replacement->$setting = $toolbar->$setting; $wrapper->insertBefore($replacement, $toolbar); $wrapper->remove($toolbar); });

Is the admin in english or translated to another language? Just wondering if it could be an issue with the translation, e.g. a translated version doesn't have %s in it. The line itself looks fine to me.

That's (very) unfortunately not possible because the input field used there, InputfieldTextTags, uses jQuery's selectize addon, which doesn't allow duplicates. A bug requesting that capability has been opened ten years ago. It might help to upvote this bug, then @ryan could adapt InputfieldTextTags (or rework, most likely, since it uses tag values as keys, which also eliminates duplicate values). There's, however, already code inside InputfieldTinyMCEConfigs.php for a textarea instead of a text tags input (with all the downsides of not validating the names entered) for the toolbar config. Just uncomment the code here and comment out the field definition after that.

For years I have used MySQL (on Ubuntu) with ProcessWire. Lately, the database has become incredibly slow. Everything: ProcessWire, dumping & restoring databases, etc. I believe this started happening when I have upgraded from Ubuntu 18 LTS to Ubuntu 20 LTS, which also upgrades MySQL to version 8 (from 5.x). I have tried to remove and purge MySQL and then reinstall it from scratch, just in case it depended from some old setting, but nothing changed. Still horribly slow. The surprise was when I tried replacing MySQL (8) with MariaDB (10.3) – since PW supports both – and then I restored the ProcessWire databases. Result: operations are more or less twenty times faster. Now, I understand that MariaDB is generally considered a bit faster than MySQL, but twenty times seems a bit excessive. Anyone has any idea on what could be happening here? Thanks

@teppoThanks, you nailed it! ?

Interesting topic. I was in a very similar situation watching MySQL's performance degrade on a well established LEMP app located on an Ubuntu 14.04 Droplet. On that server, I installed an instance of Percona's MySQL (maybe v5.7*) and bang! Everything was fine and remains that way 3 years later. Total mystery...

Thx @adrian and sorry for not providing the line numbers! The problem is on line 1330 and this fixes it for me: protected function getPHPUser($full = true) { if(function_exists('posix_geteuid') and function_exists('posix_getpwuid')) { $pwu_data = posix_getpwuid(posix_geteuid()); if($pwu_data) $username = $pwu_data['name']; } added "and function_exists ..."

Hey @bernhard - the calls to that are already wrapped in a function_exists() so I am surprised that isn't enough - this is the first report I've had of an undefined function error. https://github.com/adrianbj/TracyDebugger/blob/0d88866516be43156c945b45c6cd77c664d79204/panels/DiagnosticsPanel.php#L1201 Can you figure out why that check is failing for you?

Hey @adrian my server does not allow that function (and maybe others needed by the diagnostics panel). If you find time, would it be possible to wrap all those checks around try/catch ?

This is a particularly good one. Very well designed ????

Just noticed this one, published a few days ago: https://www.ionos.com/digitalguide/hosting/cms/processwire/ Cheers

It's been a while currently trying to rewrite my website in processwire

This is just a warning that the memory limit is to low. The site should run fine. A client of mine has the same warning with his shared hosting and doesn‘t want to upgrade. Just check your image fields that images are resized during upload through the browser. I usually resize images to 2000px width or height, and 64Mb memory will be enough. No need to go through the installer again!

Hi @Laksone, welcome to the PW forums ? I think you're right that this is a bug - good find. Could you please open an issue in the GitHub issues repo so that Ryan becomes aware of it? Thanks!

Like ProcessWire page reference fields. Yes. Media pages are not nested. They reference 'categories' (folders) which themselves can be nested. To the user, they look like 'folders' in everyday computing (sort of). Conceptually, they are virtual folders. Technically, they are like page reference fields. This means that a media item can belong to more than one category. This is achieved simply by it referencing multiple 'category pages' (like page reference fields). So, technically, we don't nest media items. Instead, we nest the categories and the media items follow that, virtually. Categories are nestable pages. For instance, in the demo, People is a top level category (folder) page. It has two (ProcessWire) page children, Men and Women. If we wanted to, we could further sub-divide this, e.g. Men > Sports Men > Martial Arts > Etc... These are all 'category' pages. It is not shown in the video but from the screenshot below, you can see the category 'Fruits' is deeply nested. Deep Nesting Back to the demo, for example, the images (media items) you see when viewing 'Men' have the category 'Men'. Definitely. This is because as explained above, we don't nest the media items themselves. Their paths are fixed. For instance, to move some media from the category 'Berries' into 'Apples', behind the scenes, we will just change its category (reference) to 'Apples' (or 'Green', to be more specific). The media itself doesn't move. I am still working on the 'move' from the UX point of view but it will most likely be via both drag and drop and using menu (context) options.

When you enable device mode in the dev tools the user agent will change and therefore the fingerprint will change. I solve this when developing locally with the following in config.php: if(in_array($_SERVER['REMOTE_ADDR'], ['127.0.0.1', '::1'])) { $config->sessionFingerprint = false; } If you're working on a remote site and don't want to change the fingerprint settings then you can use an incognito window when viewing the front-end in device mode.

Just wanted to share the simplest language switcher possible if you only have two languages: <a href="<?= $page->localUrl($languages->findOther()->first()) ?>">DE/EN</a> ??