Leaderboard

PHP is slow... well, maybe not that slow at all. Interesting read. https://dev.to/realflowcontrol/processing-one-billion-rows-in-php-3eg0

That sucks, but I'm guessing they might make exceptions for some projects, so I'll have to ask them. Still, not nearly as much of an issue as what CKEditor did. But if it stays GPL and they don't make an exception for any projects, then most likely we couldn't include TinyMCE 7 with the core. In that case, we'd develop it was a non-core module, and folks would have to install it as a 3rd party module (in /site/modules/). ProcessWire's core is completely separate from what people develop or what they might add-on their site, so they don't have to share the same license. PW is built so that modules are independent of ProcessWire in the same way WP and PW are separate applications that can run on the same webserver, or a website is independent of the webserver that's delivering it, or a browser is independent of the HTML it renders or JS it executes. https://processwire.com/about/license/3rd-party-files/

@Denis Schultz - new version of Tracy now uses AdminerEvo. Thanks again for letting me know about this new fork. Hopefully it has a long life. I had to tweak a few things so if anyone see any issues (should be mostly cosmetic hopefully), please let me know.

Bad news for all of us: https://github.com/tinymce/tinymce/discussions/9496 "....we have decided to release TinyMCE 7 under the GNU General Public License Version 2 or later, abbreviated as GPLv2+..." To see why this is pretty bad news, read: https://github.com/BookStackApp/BookStack/issues/4908 BTW, I am a happy admin user of BookStack which is highly recommended! Now BookStack and ProcessWire share the pain of TinyMCE moving away from MIT :(

Any plans to switch to the maintained fork: https://github.com/adminerevo/adminerevo ?

Hey all! Fluency 1.0.8 has been released. Now available for upgrade in ProcessWire admin and in the modules directory. For the Composer fans out there, Fluency has been added to Packagist and can now be installed by running `composer require firewire/fluency` This version contains a new feature where you can now disable translation on a per-field basis. Just check the "Disable translation for this field" checkbox under the 'Details' tab and Fluency will not be added to that field. This is helpful where fields may contain different content for different languages but may not be suitable or desired for translation- email addresses, phone numbers, full string URLs, etc. It can help clean up the UI when editing pages and prevent unnecessary translations. Also includes the following: Activity overlay text has been resized and reformatted, now looks better where the size of the field is smaller. Translation cache is now enabled by default as stated in the README file Performs some polite cleanup when uninstalling the module. Fix issue where CKEditor fields in collapsed Repeater and RepeaterMatrix fields may fail to initialize. Credit to @ryangorley for finding/reporting. Fix issue where fields with combinations of languages that are and are not configured in Fluency are properly handled. Languages that aren't configured in Fluency are now indicated where others have the translation button present. Credit to @ryangorley for finding/reporting. Fix for issue where the way that Fluency stored module configuration data may cause ModSecurity false positives depending on how rules were configured on that server. Credit to @update AG for finding/reporting. Various minor fixes and code cleanup. Please share any bugs here or, if possible, create an issue in the Fluency Github repo. Thanks!

It has been a great meeting yesterday ? We are working on something... ?

https://jan.ai/

https://www.cognition-labs.com/introducing-devin Well I guess that's it then. It was nice riding with you folks. I am out...? Oh, wait a minute. There's still hope. I just need to learn ML... ?

This is pretty amazing stuff. I recently worked on a few tasks for a client that involved parsing ticket sales data in CSV and Excel formats. I was only working with ~67,400 rows of data. I used my go-to library Simple Excel which gets the job done and has a great interface for looping, filtering, reading, writing, etc. data. Maybe I'll try playing around with that implementation at some point... I guess then I'd have to figure out how to write something efficiently- because deadlines can wait (haha). Good share!

It's a pity that I did not make it. Is there still a chance to participate? And if there is, how? ?

“Gentlemen you had my curiosity ... but now you have my attention.” ― Quentin Tarantino, Django Unchained

I'd like to introduce you to my newest employee: Devin

You could get the field without going via the template fieldgroup, but to get the inputfield and selectable pages I think it's compulsory to supply a Page object. In the case of selectable pages, it's quite common for the selectable pages to change depending on the current page which is perhaps why it's a compulsory argument to getSelectablePages(). I guess you could get the inputfield settings that determine the selectable pages (i.e. parent_id, template_id, findPagesCode, findPagesSelect or findPagesSelector) and then use that to build a $pages->find() selector but that seems like more trouble than supplying a $page argument. For a Page Reference field that isn't in a repeater I think the simplest way is: $options = $page->getInputfield('my_page_ref_field')->getSelectablePages($page); But a Page Reference field inside a repeater is a special case because where the selectable pages depend on the current page, the current page is interpreted as the editable page that contains the repeater, not the repeater page that contains the inputfield. There is discussion about this here: https://github.com/processwire/processwire-issues/issues/479 So you might do something like this: $options = $fields->get('my_page_ref_field')->getInputfield(new Page())->getSelectablePages($page);