Leaderboard

This week on the dev branch is ProcessWire version 3.0.235. Relative to the previous version, this one contains 19 commits of fixes and feature additions (see commit log). As mentioned last week, this version adds support for custom repeater page classes. Another significant addition was the upgrade from TinyMCE 6.4.1 to 6.8.2, which covers 13 TinyMCE versions with hundreds fixes, improvements and additions (see TinyMCE changelog for all the details). I did also try to upgrade CKEditor to the latest version (which is also the final open source version of CKEditor 4), but found it was making outbound http requests to ckeditor.com, so I reverted to the previous version. Presumably that was just to preform version checks, but what's the point if it's the final version ever... previous versions didn't do that. It also seemed like it could be for some kind of tracking, so I decided to leave it out for now and revisit it later. Lastly, this dev version of ProcessWire adds an improvement to the ProcessWire installer. Now you can choose either "hostname" or "socket" as the DB connection type. Depending on what you choose, it'll provide the appropriate inputs. Previously the installer did not support a socket DB connection option. Thanks for reading and have a great weekend!

According to https://github.com/ckeditor/ckeditor4/issues/5510 it was indeed added to check if the installed version is up to date, but that's still unexpected and — in my opinion — just plain nasty. There should be absolutely no reason for CKEditor to "call home", except perhaps for those subscribing to their commercial LTS version. And if that feature was added just to push paid subscriptions to existing users once security issues are inevitably found from the free version, that doesn't make it any better. Thought about posting a question about that in the issue, but look like they've disabled commenting; doesn't seem like they're interested in open discussion. Migration to TinyMCE feels more and more like the right move ?

@ryan looks like this was added in 4.22.0 and can be disabled: https://ckeditor.com/docs/ckeditor4/latest/api/CKEDITOR_config.html#cfg-versionCheck

View at: https://okeowoaderemi.com I switched to Processwire 10 years ago and it's being my goto framework for maintaining my website and also developing for clients. Development I used the moduleTemplateEngineFactory and TemplateEngineTwig, Twig has always been my favourite templating engine, because of how easy it is, to use reusable code and have an easy way to inject content into the layout, it's almost like MasterPages in .NET (For the Oldies)

I'm proud to share another module with you. Compared to other settings-modules this module has the benefit that it creates a real page, which means: You can access it via $settings or settings() from everywhere You can upload assets like a logo or global images or files You can add/hide/change all the fields of the settings page as you like It (optionally) adds a settings-icon to the main navbar of the backend It has a redirects feature to create short-links like yourdomain.com/example Download + Docs: https://www.baumrock.com/processwire/module/rocksettings/ If you have feedback or any suggestions for improvements let me know!

I've fixed that issue and pushed it to the development branch! @bernhard Added the swap source/target languages feature you requested, along with some other updates to the translation tool! I'm packing in a lot of updates to dev so the next release will be a big one. Want to get as many fixes and stuff into it before the version change.

@TomPich: You also want to give some careful thought to managing the access to practitioner pages.

You might want to use the BatchChildEditor module for this.

Thank you @da² So the actual role of the module would just be to handle the practitioner pages in a more convenient way than standard pages (like showing each page data in a line of a table) using PW API. Sounds interesting, and not too complicated. I will dig deeper in that direction in the coming days.

Hello, I would use PW pages with a "practitioner" template. Data export won't be more complicated, you can use PW API for that. If it needs to be optimized you can use several options like $pages->findMany(), findJoin(), findRaw() or even use raw MySQL query. That way your practitioners are already editable from admin without effort. Also check custom page classes if you need to attach your own class to this practitioners pages. It depends on your actual knowledge on PW, PW has a good documentation, you can start by looking Pages and Page. First one is useful to find your practitioners pages, second one to access a single page or create a new one.

Hey @SIERRA could you please read the community rules, especially the section about "Rules for posting"? You have posted several questions over the last years and often you just disappear. It might increase your chances to get helpful answers if you try to ask in a more polite and less demanding way and at least say thank you after someone replied and tried to help in his/her spare time for free. Have a nice weekend and good luck with your project.

Hello, I'm not sure if you really need a module for that, it looks simple enough to implement: https://developers.google.com/identity/sign-in/web/sign-in Searching for an existing user or creating a new user is just a bit of code, so personally I would go without any module.

I think this is a big issue with quite an impact in many areas: https://github.com/processwire/processwire-requests/issues/176 https://github.com/processwire/processwire-issues/issues/1856#issuecomment-1878431067 We also have no events for modals, panels etc. We have a JS API for Inputfields already, so it would make sense to expand on that concept: https://processwire.com/blog/posts/pw-3.0.145/#inputfields-javascript-api I think this is one of a few cases where there are conceptual problems that Ryan should take more care about. I think these problems are not present enough in his head. Maybe someone can came up with a good writeup and maybe also propose a good solution? Sometimes that helps wonders, eg in 2020 I asked on stackoverflow about missing events in tabulator.info and the author of the library didn't seem to understand. Then in 2021 I posted the same thing in other words and he liked the idea a lot and it was instantly built into v5 and is now an integral feature of tabulator. I think it would be great to have a unified events system for the PW backend similar to https://tabulator.info/docs/5.5/events I could think of something like this: ProcessWire.on("repeaterItemAdded", function() { ... }); ProcessWire.on("panelClosed", function() { ... }); ProcessWire.openPanel(...); ProcessWire.addRepeaterItem(...); And I could imagine that Ryan likes the idea as I think code would get cleaner and easier to maintain - just like it happened with the Inputfields api some time ago...

https://github.com/processwire/processwire-issues/issues/1867 ?

.. or even taking advantage of newer html5 developments. For example, <details><summary>. I guess the fundamental issue is that this is always a moving target, so it makes sense to not try and track the latest fashion, but to move when it is clear that the way forward is established and generally accepted.

That sounds like a huge task ? Do you have any reference for that? From what I read it's "maintenance-only", so we'll not see any new features. That's a different story then I guess. But of course I agree that it would be nice to get a more modern looking/working backend. But compared to other CMSs I think it's still really not bad. And it's very well thought out for all the complexity it needs to handle. https://blog.jqueryui.com/2021/10/jquery-maintainers-update-and-transition-jquery-ui-as-part-of-overall-modernization-efforts/ But remembering when AdminThemeUikit was born I guess Ryan will come up with a genius solution once it is necessary ?

Works great so far! Thx ?

The next major upgrade to admin in general would be to support saving without reloading IMHO. This could be a SPA. But maybe unpoly or htmx would fit PW spirit better. Anyway, this seems like a gigantic task to tackle. And surely Ryan should decide if he is willing to do it now or ever.

Thanks @ryan. Thanks everything you have done. Happy new year to you and this amazing community from afar. Gideon So

Thanks, @ryan! Being here for so many years it feels like home. And everyone in the forums like relatives, even though I never seen them in person and only imagine them as their avatars living somewhere around the globe) So these "winter holidays" celebration posts are kind of like a family reunion, when everybody gathers at a holiday table after a not so easy year passed. Happy new year to everyone! Let it be a better one! С наступающим! Всего хорошего и доброго! ???

Many thanks @ryan for all your hard work and happy holidays and new year everyone!

Saying an inputfield does not support AJAX loading often just means the inputfield doesn't initialise properly when it is added via AJAX. Probably because it only initialises on dom ready: $(document).ready(function() { initialiseMyInputfield(); }); But if there is an event fired when a new repeater item is added the author of the inputfield module can update it so it will support AJAX loading: $(document).ready(function() { initialiseMyInputfield(); }); $(document).on('repeaterItemAdded', function() { initialiseMyInputfield(); }); But in InputfieldRepeater.js I don't see events being triggered for repeater item add, sort, delete, etc that we can monitor for.