Leaderboard

This latest version on the dev branch includes a few additions, optimizations and fixes. I'm only in the office for a brief time today, so I'll plan to cover these in more detail hopefully in next week's blog post (along with next week's updates), but here's a preview. There's a lot of improvements to the "Overrides" tab that you see when editing a field (Setup > Fields > Edit). These are the field settings in the contexts of different templates. In 3.0.144, you now get a list of all field settings that you want to allow to be customized per-template. In previous versions, you only saw this option if you were in $config->advanced mode. It's still a YMMV setting, so appropriate disclaimers have been added to the field. But since it's been there for more than a year and there have not been any reports of issues (that I'm aware of yet), I thought it didn't need to be limited to advanced mode anymore. The table that shows you what overrides are in place is now improved as well. You can now click any override setting to open a modal window to see/edit them as needed (previously they were just non-clickable text labels). This is the same window that you get when clicking a field in the Template editor. Though unlike the Template editor, it takes you directly to the setting you clicked on and highlights it. After saving or closing the window, it updates the table for any changes you made. In addition to this, the overrides table now shows a Diff rather than separate Old and New values for modified settings, which better clarifies what was changed. (That Diff comes by way of a new method added in the WireTextTools class). Version 3.0.144 also adds a new Inputfields Javascript API. More methods are likely to be added to it, but you can see what's available in this first version in the comments for this file (inputfields.js). The purpose of this Inputfields JS API is to make it simpler to manipulate Inputfields from the JS side, as well as solve some needs that I've had in the core and modules; which presumably some other developers may have had as well. It takes a lot of stuff that previously required knowing which classes and attributes to manipulate and simplifies them to simpler methods calls from the new Inputfields JS API variable. It also abstracts away some admin-theme specific stuff so that you can use the same API to perform certain manipulations regardless of admin theme. I'm still working out some details and likely have some issues to fix and additional functions to add, so I'll save examples and more description for next week. Though the updates mentioned for the "Overrides" tab do use a little bit from this API. This version also contains a couple of fixes per GitHub issue reports, and that'll continue into next week's version as well. More updates next week. Until then, thanks for reading and have a great weekend!

I think this is the crux of it - it's mostly a communication issue. It's not surprising that people come to PW with an experience of seeing how some other open-source GitHub-hosted projects are managed and expect that it's the same for PW. Many projects encourage the user base to submit pull requests. However, PW is not one of those projects and this probably needs to be communicated more clearly somewhere. Open-source is not one thing but many things depending on the project and those who manage it. My impression is that PW is open-source in the sense of "a very smart person made this software and you can use it for free and also modify it to suit your needs". But it's not open-source in the sense of "hey everybody, let's collaborate on writing code for this software". There will be pros and cons to the different approaches to managing an open-source project, but all things considered I think most would agree that the formula Ryan is following has proven very successful to date.

A couple of hooks that I have found useful in some situations... In the admin menus the icon associated with each page is normally determined by the "icon" item in the Process module config (e.g. as set in the getModuleInfo() method). But sometimes you might want to change that icon. For example, the Lister Pro module uses the "search-plus" icon, but this is not so good when you have multiple Lister Pro instances because it makes each instance less distinct. With the hook below I can use a custom icon for the extra Lister Pro instances I have added: // Add custom icons to Lister Pro menu items $wire->addHookAfter('Page::getUnknown(page_icon)', function(HookEvent $event) { $page = $event->object; if($page->process == 'ProcessPageListerPro') { if($page->title === 'Flora species') { $event->return = 'leaf'; } elseif($page->title === 'Flora images') { $event->return = 'picture-o'; } } }); If you change an icon in the admin menus like this you can do a Modules > Refresh to clear the menu cache and see the updated icon. And for Page List you probably know that you can assign an icon to all pages that use a template in the template's "Advanced" tab. But with the hook below you can assign icons to pages more dynamically based on any properties of the page. So, for example, you could assign a warning icon to a page to alert site editors if some important field was left empty. // Add warning icon to news items without a date $wire->addHookAfter('Page::getIcon', function(HookEvent $event) { $page = $event->object; if($page->template == 'news_item' && !$page->date_1) { $event->return = 'exclamation-triangle'; } });

Check this:

I can't agree more. Of course there is a logical explanation behind the current situation - there mostly always is. But the open PR's could easily be interpret as a "stale" project. Of course this is not the case as ProcessWire is one of the most worked on CMS. By mostly one guy (not to undercut the other module contributors, lots of love there). Which on itself is pretty amazing. Therefore this is true too: ProcessWire finds itself positioned in a very difficult spot. To clients this isn't very much a problem, since I always find it to be reason of the professional to sell its tools to their client. But selling the CMS to other developers/companies is a lot more difficult. There are quite a few pain points such as the open PR's, the first impressions of the master branch (last commit: 21 dec 2018), the already dated design of the website, the lack of github stars. When I Google for ProcessWire the repository of Ryan is even on a higher position than the current repository (last commit: 7 Oct 2016). The notice on top isn't very clear. These are not important to me*, but first impressions do matter. [off-topic]We should really highlight these strong points: the really great custom field CMS, the speed of development (example: the .wepb support), the great (paid) modules, the great community, second-to-none multilingual support, the great documentation and the greatly written blogs too! Ryan has his way with words.[/off-topic] * I had to look twice myself ?

Yes, it's weird, and most probably a bug. Funny thing is that the current active language is recognized correctly (status10189 = 1), but language name and title are mixed up.

After looking to it a second time, one may come to be able to see the not so sad truth, that is: With ProcessWire we have an opensource project on a very high level in regards of code base, stability & homogenity and much much more along those lines. AND all of of this is directly related to Ryan's decision to *work through all pullrequests* himself to deeply understand, modify, and adapt the code, so that he himself is ALWAYS & IMMEDIATELY able to fix bugs resulting from those code changes. (Even after years, when maybe some people who have sent PRs have left the project again and are no longer reachable.) This has a lot of advantages! And it has, (as everything has), some cons. One of them is, that he is something like a OneManCodingArmy :-), but he is only *one* man. And I don't want him to waste his time to read through every github issue, plus every github pullrequest AND ANSWER TO EVERY ONE of them, in order to explain "why he doesn't want to do it that way, or that he doesn't have time now to do it, or that it could produce a lot of side effects, or, or, or". And one of my fantasies is that he might already be unhappy about not having the times to be carefree active here in the forums, as it was possible for him until about 4-5 years ago. It might feel ungrateful for him to read such a post. This, as a result of his disciplined behaviour, to advance the project as far and effectively as possible. Every week, or almost every day. (( @ryan Did you imagine or wish this when you turned your code into an open source project in 2010? I'm just kidding! But it may sometimes be tiring to be confronted with the same thing over and over again, when the answers have already been given many times and the internet supposedly doesn't forget anything. But when people "don't have time" to do a little research first, or try to look at it from a different angle before, but (in the worst case without any impulse control) always bring up the same things again. Pffhhhh, for my well-being that would be nothing. ? I want you to have time and energy to work in your own flow & rhythm on *your* ProcessWire. Your ProcessWire, that you gifted to us. ? )) @bernhard The truth is, (not the sad truth, not the happy truth, just the truth): it's one of two possible choices that he took 10 years ago. With all the pros and cons. In my opinion, every member of the community should respect that and never forget it. Because all that we have learned to love and appreciate about ProcessWire, all that has enabled us (even in early days, when we may not have had much code experiences) to write our own modules, is the result of that decision and I wouldn't want to miss it. The alternative would be to abandon this course and (quality) control. But all the people I've spoken to in the past, all of whom have more than 15+ or 20+ years of experience in the software business and open source sector, have consistently told me: "Be glad that it is this way. There were so many projects that started that way, but opened up and broke 1 or 2 years later." And about @netcarver question: I have contributed a lot of stuff in regard of image handling in PW. But it seems that less then 5% of it is reflected in githubs contributors list. The most things, where Ryan included my PRs as is, we have had conversations and colaborations about and on it on github or private via PM or email, until the code was accepted by him (in regard to his principles, anounced above). Aaand, it could be, that it also has something to do with the fact that he not only made the experience that I am still approachable after 6 years when it comes to issues, decisions or questions, but that I also not only understood his decision, but also respect it. Even if it has a negative effect on me in some areas. (But that's also just a fantasy of mine, with no claim to truth.) ?

A module created in response to the topic here: Page List Select Multiple Quickly Modifies PageListSelectMultiple to allow you to select multiple pages without the tree closing every time you select a page. The screencast says it all: https://github.com/Toutouwai/PageListSelectMultipleQuickly https://modules.processwire.com/modules/page-list-select-multiple-quickly/

@bernhard Thank you for creating the issue in repo.

Thx @DV-JF I've gone ahead and created an issue: https://github.com/processwire/processwire-issues/issues/1020

Now there is a new VIMEO privacy "do-not-track"-option, which should be always on in in the EU: ...?dnt=1 With this, VIMEO does not set a Cookie any more. Source (German): https://www.datenschutz-guru.de/wie-kann-ich-ein-vimeo-video-datenschutzfreundlicher-einbetten/

Just tested and I can confirm that behaviour: // ready.php bd($this->user->language, 'ready.php'); $wire->addHookAfter("Pages::saveReady", function() { bd($this->user->language, 'saveReady'); }); I have no explanation. Anyone?

I get your point @horst and what you describe is perfectly fine, but IMHO it wouldn't be a sad truth if it was communicated that way... --> "not-sad-truth" ? --> invest time for PRs --> PRs are ignored --> sad truth ? There are really small PRs that could be easily implemented within no time (eg https://github.com/processwire/processwire/pull/138/commits ). I understand, that checking all PRs can cost a lot of time, but that could be done by someone else just like @netcarver does it for the issues repo. Someone could tag simple fixes and ryan could then just work through PRs having some kind of label.

If your PR addresses an issue, rather than a feature, then one approach to the logjam would be to post your Pull Request on processwire/proceswire as normal, but then to add a new issue on processwire-issues that links to it. I can then tag your issue as "contains a fix". Hopefully this will put it on Ryan's radar. I've done one example of how this might work: https://github.com/processwire/processwire-issues/issues/1016 Similarly, if you create a PR for a feature, then there is nothing preventing it being referenced by a new issue on processwire-requests. I really wish this were more frictionless, but it's all I can think of at the moment.

Usually I'd say the best approach if you need multiple formats is storing the information in a canonial format and using different formatters, which can convert the canonical format the the various output formats you have. Kinda like e.g. datetimes are stored as unix timestamp, but that's hardly ever the output format.

Not a problem — I create (and/or manage) around 20-25 sites a year. These are tiny, 1-5 page promo sites, all with bespoke, one-off design, and are either fully static, or connecting to a single "registration" system (which is atm running aforementioned PW). 90% of these are for an event, or an event series, so they start, last a while, and end anywhere between two months and half a year. I'm the only person editing them, and most of the edits happen straight in code. ATM, they are 99% built on Eleventy - https://11ty.io, and the fully static ones are built and deployed via Netlify, and the ones which are connecting to the registration system (via tiny bits of PHP) are deployed from the Github CI/CD to our own servers. I also (actually started this year) created/manage few long-term sites, which I've build on Kirby — It's basically a spiritual brother to ProcessWire, but fully file based, so it fits my development process better - I can sync the website up and down fully with git, without any need for managing the database. As for the system itself, I'll write up a blog post about it (probably) when I finish it, so I can post it here / send it to you later, but the short of it is I'm moving it to Laravel due to builtin support of PostgreSQL, queues and testing, and the rewrite will allow me to introduce a couple of design changes to overall system, which would actually be possible with PW as well (probably…), but if I'm going for a rewrite, I might as well go full rewrite.

Thanks ... I am also of the opinion that it is great to have a good basis for further development of the profile that contains the latest additions API ... I think that this profile should be quite simple for users, given that all the latest features are described on the blog ... Anyway, it's nice that it comes in handy ...

I do it usually as follows: 1.) Create a file /site/translations.php <?php namespace ProcessWire; /** * TRANSLATABLE STRINGS * Define globally available translatable strings * * USAGE * place this file under /site/translations.php * __("My translatable string", $ferry); * The wire property $ferry refers to the textdomain of this file * */ __("My translatable string"); 2.) Define a wire derived object and place it in /site/ready.php /** * TRANSLATABLE STRINGS * Include translatable strings * @see /site/translations.php * @var $ferry */ $this->wire('ferry', '/site/translations.php', true); output in any template /** * output in template */ echo __("My translatable string", $ferry); Now you need to translate it only once, by using the string in any template. Usecase: strings like "read more" etc. For strings specific to a template you can use simply: /** * output in template */ echo __("My translatable string");

v0.1.2 released - adds compatibility with PW < 3.0.66