ryan

FYI the ProFields Table field does this quite well, and I'm currently using it for this. You could also do the same with a repeater, but Table would do it more efficiently. If you need 2 dates (like a range) then also note there is FieldtypeDateRange/InputfieldDateRange available in ProFields as well.

Thank you for all the feedback, I'm enjoying reading it and it's opening up a lot of good ideas, so please keep it coming. I also have some ideas to add. With regard to big/major features, I'd ideally like to focus on things that absolutely must be in the core, and not on things that can be built and supported by others as modules. My wishlist would be that ProcessWire focuses more on its roots, being the best it can be as a framework and CMS for running modules. If I can focus on that part of the core, and let others develop major new features with modules, then not only would the core be that much better, but I think I'd have the bandwidth to do things like develop a more formal testing framework, make the docs that much better, have more time for issues and requests, etc. Things like media/asset managers and web/block builders/editors (as examples) are best built by those that use them. When you are both the user and developer, you can develop and support something better than if you hired someone to develop it. @bernhard is a great example, he has stepped up and built answers to several things that people ask for, and he's both developer and user of those things. I understand some of these external modules cost money. But when something doesn't cost money to you, it has still cost money and time resources from someone else, the developer, or whoever sponsored the developer. So it's a question of who pays for it and how they are doing so. My strategy here has been to focus on developing things that I can use in my projects and very often the clients help cover the cost. That's how much of ProcessWire has been built. Other features that I use but could not afford to develop and support for free have been developed into Pro modules. This helps fund the core too. I don't make enough to survive on that alone, so I do a lot of client work as well, and I like the diversity of work. When I say that one particular feature is not likely to be developed in PW's core in the next version, I'm not saying that it's a bad idea at all, nor am I rejecting it, but more likely that I don't have the ability to fund that feature at the moment. (But maybe will later). Or in many other cases, it may be that a particular feature might only be useful in some installations rather than most, and thus belongs as an external module. If something like RockPageBuilder or PageGRID or others could suit your needs on a particular project, support the developer and get it. The more we can do this, the more that developer can do, the more decentralized the responsibility for ProcessWire can be, and the more I think it benefits not just that module and developer, but the entire ProcessWire project. Maybe the developers of these modules would be open to having a free version with less features so people could get to know them better and upgrade when they need it. Kind of like how there is Lister and ListerPro. One idea I'd like feedback on. What if ProcessWire 4.x would be just the core and only the modules essential for the "blank" profile? And that's all the core would be. Then, on the download page (or maybe the installer), you could select all the modules you want to be part of your installation. For instance, you know you'll need repeaters, so you check the box for the Repeater Fieldtype. You know you want Tracy, so you check the box for that. At this stage you could select both 1st party and 3rd party modules to basically configure your own ideal version. From here we could also highlight other options like the Page Builders mentioned. There would have to be some predefined options, like a "well appointed" installation that is the same as the core as it is now. It would be a whole different way of building ProcessWire, but much more back to the roots of PW, becoming even more of a community project, sharing the responsibility a little further and getting more people involved, growing the family.

@Jan Romero No hacks are necessary and it's actually much simpler than I think you might realize. The row pagination essentially works the same as with pages, and you can override the current pagination in the same way (via start and limit). The only difference is where you call it from. Why don't you open a topic in the ProFields Table support board? I'm happy to answer any questions you have.

Elementor is not part of Wordpress, but a plugin developed by someone else to run in WordPress. Maybe this is an opportunity for someone in ProcessWire. And there are already RockPageBuilder and PageGRID in ProcessWire to consider as well. The dominance of WordPress has always been the case, and it will likely continue to be the case. ProcessWire is unique and has always been something completely different from WordPress. The CMS projects that are trying to mirror WordPress never seem to last long because, if you want something like WordPress, then why not just use WordPress? Though I don't know anyone that really knows both well who prefers to develop in WordPress. Instead, WordPress dominance is largely a matter of name familiarity with clients, which is completely understandable. But there are also several things it genuinely does well, and I always believe in using the best tool for the job. If the types of projects you work on are a good match for WordPress, then great, but I hope you also have projects that are a good match for ProcessWire as well. ProcessWire fully supports it. Many (most?) of us is have used exclusively on new installations for years. I don't know what those are. it sounds like another opportunity for modules. But more info needed. Good idea. This is something I think I can do. Can you describe further? In the majority of cases, older modules will still work fine. I'm not aware of anything in the modules directory that does not work, but if any become apparent I will remove them. Maybe it would be a good community effort to identify modules that could be removed from the directory. I think this might turn off as many people as it turns on. I know I wouldn't like it. But if it can be automated as an installation option then sure, why not. ProcessWire already supports WEBP and has for awhile. I was working on core AVIF support, but Robin S. released an AVIF module so I put mine on the back burner. And this may be the sort of thing that is better as a module, or maybe it'll be better in the core at some point, I'm not sure. Right now we don't build core versions in a way that breaks things from one to another. At least not in a way that is known at the time of assigning a version number. When that changes, I think we'll want to adopt semantic versioning, and maybe that's a part of 4.x. Maybe it would benefit 3rd party modules more in the shorter term, so it's worth looking at there first. Sounds interesting but I need more details. If there's anyone that is an nginx expert that wants to step up to have this responsibility I'd welcome it. I've mentioned this before too, but nobody has stepped up. I'm not an nginx expert so don't feel qualified to support it on my own. For real? This is the first I've heard of any chaos. Good to hear. We do have the PageAutosave module which does Live Preview even better than ProDrafts. This module is available in ProDevTools or ProDrafts boards, but maybe it can have a wider release. This is exactly the sort of thing that PW is great at supporting already. But I have been exploring building an everything-SEO module here, as it's something I'd like to use and support, but just not as part of the core. The hard-core SEO experts will still want to do their own SEO stuff like they do now, but for those that want something they can turn-key and have it all ready, a module is ideal. I'll very likely be building one within the next year hopefully.

ProFields Table gets a ton of love, perhaps the most of any module I develop currently, as I work with in every single day. I looked at all of the threads you linked. The first linked thread has been waiting for your reply for awhile, and the last one is already in the GitHub queue. In the others, I'm seeing feature requests as well as some back-and-forth between us about one behavior or another, but none appear to be actual bugs. If you disagree on one or another, drop a reply to bump it in the relevant thread. I try to focus on features that will benefit the largest audience. Following that I do try to add support for new selector features and things of the sort you've mentioned. Sometimes folks ask for things that might take more time than I have to implement and might only be used by one person, so I have to be selective in what gets added when, whether in Table, the core or any other modules. Generally if someone needs one particular feature and it won't take a lot of time to implement then I do try to implement when the request comes in. If I've not yet implemented something you want then it's more than likely just a matter of not having the time to do it immediately. That doesn't mean I don't love you, it just means I'm working within the resources I have.

@szabesz I think the phrase "everything necessary" might be worth considering here. A class ideally just has one responsibility. Page instances are there to provide an interface to one page's content and be swapped in and out of memory on demand. When there are things like hooks going into a Page, that changes the role completely. If you start doing this a lot on a large site then it may affect scalability. Maybe it's fine for one individual installation or another, however. In your case, this isn't an issue, as you've solved that concern with a static method. I think that's okay for an individual installation, but it wouldn't be okay for PW to suggest for everyone because it's not multi-instance safe. The core avoids also static methods when possible because they are disconnected from any instance of the class. When there are static methods, it's always worth looking closer if it's worth the convenience (sometimes it is) or if they would be better off somewhere else. Using hooks in your /site/init.php, /site/ready.php or /site/templates/admin.php (when appropriate) is a safe strategy, but I agree it's not great if you have a ton of them. At that point it might be good to have an autoload Module, or to start including your own files from one of the previously mentioned ones. But if you find it beneficial to use /site/classes/YourPageClass.php then also consider a separate class (ProductPageTools.php?). Rather than having a static method, you can have a static variable in your ProductPage class that refers to that instance, but there will only ever be one of them, and it will be multi instance safe. Page classes already do this for a lot of things, delegating to other classes (PageTraversal, PageValues, PageProperties, etc.) for code that can be shared among all Page classes. There's only ever one instance of those classes, no matter how many Page class instances there are. And they are all multi-instance safe. This also keeps the memory requirements of the Page classes very low, since the Page class has very little code itself, and mostly delegates to other classes where the same single instance operates on all Page classes. class ProductPage extends Page { static private $tools = null; public function wired() { parent::wired(); if(self::$tools === null) self::$tools = $this->wire(new ProductPageTools()); } } class ProductPageTools extends Wire { public function wired() { parent::wired(); $this->wire()->pages->addHook('saveReady(template=product)', $this, 'hookSaveReady'); } public function hookSaveReady(HookEvent $e) { // ... } } Maybe you have a method with a lot of code that you want to be callable from ProductPage (any number of instances) but maintain in ProductPageTools (only ever one instance). This is how the core delegates to other classes and limits the scale and scope of classes that may have many instances. class ProductPage extends Page { // ... public function foo() { return self::$tools->foo($this); } } class ProductPageTools extends Wire { // ... public function foo(Page $page) { $result = ''; // A whole bunch of code to generate $result from $page return $result; } } If the strategy you are using now works well for you then I'm not suggesting you change it. But just wanted to point out the strategy I'd suggest as a scalable and multi-instance safe one that also maintains separation of concerns and keeps the Page class from becoming complex or heavy.

@Ivan Gretsky @cb2004 @David Karich Sorry, I must not have written it very well. I'm tired, but wired from coffee at the same time, maybe not a good combination. In any case, I'm enthusiastic about most of the suggestions, even if I can't implement them all. I've updated the original post to just summarize the main points instead.

Thank you for all of the feedback! Definitely want to build more e-commerce, but just not in the core. I'm intrigued by what Jonathan mentioned and want to learn more. I suspect it influence the roadmap quite a bit. Would enjoy building an asset manager but since my clients don't need it, I could only build it by self funding it. I don't have the ability to self fund it yet. Agree PW should continue to grow on the framework side in the next major version. I don't know in what ways specifically just yet (feedback welcome), but am stating my agreement. I think we've been on a good path in this regard so far and should keep going / go further. Don't agree that Page objects need more initialization methods, but let's duke it out. ? Agree we could use a new site profile, preferably a professionally designed one. Agree we'll definitely continue improving the admin theme and maybe even add another. Prefer to avoid features that blur the line between content and style or front-end and admin, though there can always be exceptions. The requests for Inputfield/InputfieldWrapper sounded good. Supporting more DB platforms is also on my wishlist, but not sure it can be done in the next year as there are some challenges there. Note: replaced original/longer post with summary/bullet points.

Thank you for all of the valuable comments last week! I'll reply to several of the comments soon in last week's thread. A couple months ago a new addHeaderAction() method was added to to our Inputfields JS API, enabling you to add custom header icon actions to any Inputfield (more details here). A short while later, the same method was added to our Inputfield PHP API. This week it's been expanded so that now you can also add drop down menu header actions to Inputfield, like the one in the screenshot below. Though this is just a simple example: Here's how we defined that action and menu in JS: $f = Inputfields.get('checkboxes_field_name'); Inputfields.addHeaderAction($f, { name: 'tools', icon: 'fa-wrench', tooltip: 'Select or unselect all', menuItems: [ { name: 'select-all', label: 'Select all', icon: 'fa-check-square-o', // called when the user clicks on the action callback: function() { $f.find('input[type=checkbox]').prop('checked', true); $f.trigger('change'); }, // called to determine whether action is available to click on (optional) active: function() { return $f.find('input[type=checkbox]').not(':checked').length > 0; } }, { name: 'unselect-all', label: 'Unselect all', icon: 'fa-square-o', callback: function() { $f.find('input[type=checkbox]').prop('checked', false); $f.trigger('change'); }, active: function() { return $f.find('input[type=checkbox]:checked').length > 0; } } ] }); For more details on the options, see documentation here in the inputfields.js file where the addHeaderAction() function is defined. How does that JS code get called in the admin in the first place? Well there's a lot of different ways you could do that, but in my case, I hooked after ProcessPageEdit::loadPage in my /site/templates/admin.php file and added a custom .js file (containing the code above): $wire->addHookAfter('ProcessPageEdit::loadPage', function(HookEvent $e) { $page = $e->return; /** @var Page $page */ $config = $e->wire()->config; if($page->template->name === 'tour') { $config->scripts->add($config->urls->templates . 'scripts/admin-tour.js'; } }); Have a great weekend!

Fridays are always the days when I'm full-time on ProcessWire. Other days I may be doing client work, or ProcessWire, just depending on the week. This week it's been mostly client work. And I just learned that I'll have to be out of the office tomorrow (Friday) for a family commitment. So I'm writing this weekly update today instead, and just sent out Teppo's great ProcessWire Weekly newsletter with ProMailer today (usually it gets sent Friday). Because of this change in schedule, I don't have much new to report just yet. Instead, I wanted to start talking a little about future plans, so here's a few ideas. I think we should get another main/master version out, perhaps by September. Following that, I thought we should focus on ProcessWire 3.1, or maybe it's time for version 4. What would be in this next major version of PW? For starters, we'll finally drop support for older PHP versions and start taking advantage of all that's been added new newer PHP versions (8+). This will involve lots of updates to the ProcessWire core code base, while remaining 100% API compatible with PW 3.x. I thought that would be a good starting point into our next major version at least. In addition, we'll likely be trimming some things out of the core and into separate non-core modules, such as FileCompiler, CKEditor, the two legacy admin themes, and a few rarely used Textformatter modules. Most likely we'll also have an overhaul of this website and some nice improvements to our primary (Uikit) admin theme to accompany the next major version as well. There will be plenty more too, but this is what I've been thinking about so far. Your feedback is welcome. Thanks for reading and have a great weekend!

@7Studio You might be able to do that with the new PageListCustomChildren module.

@kaz You probably don't want to change those salt values, they should match between your dev and live site. It's something that you should never change, as PW sets it up at install time and it should stay there for the life of the site. It sounds like you are using MAMP and if this is a local dev environment (I thought we were talking about the live server before) then I think MAMP by default uses this DB connection information: $config->dbHost = 'localhost'; $config->dbUser = 'root'; $config->dbPass = 'root'; $config->dbName = 'your_database_name'; If that's what your MAMP uses (which I think is the default) you could use those as-is except that you'd update the last line (dbName) .

@kaz Those salt values are generally going to be the same between your dev and live sites, unless you went in and manually changed them, and there would be no reason to do so. The error message you are seeing is saying that you don't have the right database connection information. It looks like you still have the database connection information from your localhost development site, and it's going to be different for your live site. Note the database login/pass is completely unrelated to those salt values, so you don't need to worry about those. You need to correct these entries below in your /site/config.php file to match those of your live server: $config->dbHost = 'database.host.name'; $config->dbName = 'database_name'; $config->dbUser = 'database_user'; $config->dbPass = 'database-user-password'; Replace all of the "database..." values above with the actual ones from your server.

@MarkE If it's a Process module (i.e. extends the Process class) then that's a module designed to be an application in the admin, and that module is only executed when clicked on in the navigation (assuming the user has permission for it). It sounds like you also need a module that has the "autoload" enabled, meaning that it either loads every time PW boots, or under some autoload condition that you define. Process modules aren't meant to be "autoload" modules. Process modules are interactive applications, creating and processing forms in the admin. Autoload modules hook into ProcessWire and adjust runtime behavior. These are very different responsibilities, so you want 2 modules: one Process module and one autoload module. For instance, there's FormBuilder and ProcessFormBuilder, UserActivity and ProcessUserActivity, ProCache and ProcessProCache, etc. If you absolutely had to have it all in a Process module, you could, but you'd have to do your own permission check in the execute() method(s), and your module would appear in the admin navigation even for people that didn't have access to it. It's cleaner to do it with two modules, and one can install/uninstall the other just by using the "installs" property in your module info for one of them, and "requires" for the other.

@monollonom Oops! Thanks for letting me know, fixed and re-posted

This week there were several commits to the core, mostly for resolving pending issue reports. In addition, this week I've posted a new version of the "Page Edit Children" module in the ProFields download thread. Below is the changelog for this new version: Added support for adding new children that can be fully edited right away (without having to save first). This is similar to how it already worked for the clone action. It makes it a lot quicker and easier to build out child pages, and you can add+edit as many as you want before hitting "Save". In addition, you can now drag/drop the "Add New" fieldset to the place where you want to add the new child page. This enables you to easily insert new pages anywhere you want, rather than only adding them at the bottom of the list. Added support for new child actions: Lock/Unlock and Hide/Unhide. These accompany the existing Publish/Unpublish and Clone actions. You can now configure what actions you want to be available via setting in the module configuration. For instance, maybe you don't need Hide/Unhide or Lock/Unlock, so you can simply turn them off. Action status is now more obvious, as the "on" states of actions (like unpublished, locked, hidden) now appears in red, making it much more obvious when a child page has one of these states. Added new configuration option that lets you choose whether the sort handle for each item should be on the left side of each child, or on the right side (with the other actions). You probably want it on the left side, unless you are using custom page icons (defined with templates) and you want them to appear. In v1 the sort handles were always on the right. Added support for an optional headline that appears above the child pages. Added support for customizing the "Add new" label in the module settings. If you want to change the icons that are used for actions, you can now do so by hooking the new actionIcons() hookable method. Added a confirmation dialog for the Clone action. This helps make it easier to recover if you accidentally click the clone action. There were also various other minor updates, including minor fixes and optimizations. This version is available for download now in the ProFields thread. This is still considered a development version so be sure to test thoroughly before using in any production environments. For version 3 (or nearby), I am hoping to add support for one of the feature requests: editing both children and grandchildren on the same screen. The screenshot below d emonstrates a few of things mentioned in the changelog above. Thanks for reading and have a great weekend!

@heldercervantes did you swap in a fresh copy of that file, or is that the same one that's bee there awhile? I grabbed that file mentioned from the site (RockFrontend.min.js) and un-minified it, and I'm guessing it's a false positive because I don't see any obvious monkey business in it. No references to other scripts or host names, no encoded strings, no obfuscated code, nothing that looks malware-ish to me. It is doing some iframe stuff, swapping of iframe src attributes and such, and it could that this is something that some malware does, but I think it's most likely legit here as it's using the same naming conventions in attributes as the rest of the code (i.e. starting with "rf.." for rock front-end). Anyone have any ideas why it detected it as malware? Even if I try to access the file in my browser, it gets blocked (since it's blacklisted), so I had to use wget to grab the file. Edit: I see you edited your message and that it's not the original file that got flagged. It'd be interesting to see what was in the older version. If it had malware in it, you'd want to check where it came from... like did it get modified by something after getting to your server, and if in a shared environment, are the file permissions too open?

This week a need came up in a client project. The client's team wanted to be able to navigate to their tours (pages) in the admin page-list by different criteria (operator, brand, boat, etc.). You can do this in Lister already (filtering by page references), but the client was looking for some predefined navigation paths in the main page list, as they thought this would be a helpful and time saving optimization, as they spend a lot of time in ProcessWire. They don't always know the exact tour at first, so starting from an operator, brand or boat helps them get to where they want to go more quickly. Once implemented, I thought it was actually quite useful for a lot of situations so decided to develop it into a module on my own time, and that's now available for download in the modules directory. I've published a new blog post that describes it more and covers all the details— https://processwire.com/blog/posts/page-list-custom-children-module/

All of this week’s dev branch core commits are from today, though some were worked on throughout the week. There's a mix of issue fixes and worthwhile new features. The InputfieldTextTags now can handle a couple more situations than it could before, such as single-Page selection mode and numeric-only tags, when used as an input type for Page fields. Another worthwhile addition is that ProcessWire now compares the PHP time to the database time once per superuser session and alerts you when they differ. It also provides some instruction on how to fix that situation. This prevents you from getting strange page modification times like "3 hours from now" when you just saved, and similar cases, for when the DB time happens to differ from the PHP time. (Thanks to @bernhard for the suggestion). This week's update is a day early because I've got to pick up my daughter from camp tomorrow and it's a couple of states away, so I'll be on the road tomorrow rather than at the computer. I hope you have a great weekend!

The core dev branch version has been bumped up to 3.0.240 this week. As always, see @teppo's excellent ProcessWire Weekly for details on what has been added recently. More can also be found in the commit log. This week adds the ability to hook into ProcessWire's admin live search to add your own custom results. This is useful for modules or for your own hooks placed in /site/templates/admin.php. Previously, only modules implementing the SearchableModule interface could manipulate the admin search engine results. Now there's another even simpler way to do it. We'll focus on examples placed in /site/templates/admin.php, but they could also go in /site/ready.php, /site/init.php or in an autoload module's init() or ready() method. The following is a simple example for when one types "today" into the search engine, it returns search results of pages that were modified today. $wire->addHook('ProcessPageSearchLive::findCustom', function(HookEvent $event) { $data = $event->arguments(0); // array $search = $event->object; // ProcesPageSearchLive $group = 'Pages modified today'; // description of this type of search if($data['q'] === 'today') { $items = $event->wire()->pages->find("modified>=today, include=unpublished"); foreach($items as $item) { $search->addResult($group, $item->title, $item->editUrl); } } }); The point of that example is just to demonstrate something simple. In reality, that example isn't that useful because you can already type "modified>=today" to get the same results in the search engine. So let's look at a potentially more useful example. There have recently been requests for better "id" search support in the search engine. In this next example, we add support for "id=123" searches, where it will match templates, fields or pages having id "123" (or whatever ID you specify). Further, it will also support it if you just type "123" on its own. Here's how we might accomplish that below. We'll limit this particular type of search to the superuser since this hook doesn't have any access control checking. if($user->isSuperuser()) { $wire->addHook('ProcessPageSearchLive::findCustom', function(HookEvent $e) { $search = $e->object; /** @var ProcessPageSearchLive $search */ $data = $e->arguments(0); /** @var array $data Search data */ $type = $data['type']; // what to search $q = $data['q']; // search query text // support search of "id=123" or just "123" // skip search if not an "id" search, or query is not a number if(($type != 'id' && !empty($type)) || !ctype_digit($q)) return; // reduce default search operator "%=" to just "=" (if used) $operator = trim($data['operator'], '%'); // search for id in templates, fields and pages foreach(['templates', 'fields', 'pages' ] as $apiVarName) { $apiVar = $e->wire($apiVarName); // get API var $selector = "id$operator$q"; // selector i.e. id=123 or id<10, etc. // some additional considerations for page ID searches if($apiVarName === 'pages') { // PW already handles "id=123" for pages, so skip that kind if($type === 'id' && $operator === '=') continue; // add more to selector for page searches $selector .= ", include=all, limit=$data[limit], start=$data[start]"; } // find by selector $items = $apiVar->find($selector); // tell ProcessPageSearch which results we found foreach($items as $item) { $title = $item->get('title|label|name'); $url = $item->editUrl(); $search->addResult($apiVarName, $title, $url); } // optionally return false to tell it to stop searching after this hook // which would prevent the default behavior of the search engine // $e->return = false; } }); } As you may (or not) know, the search engine displays help if you type the word "help". Help for the search engine usually consists of example searches and descriptions of what those examples do. If we want to add some help for our example above, we could add this to to the top of our hook above, perhaps right after the $data = $e->arguments(0); line: if(!empty($data['help'])) { return $search->addHelp('ID Search Help', [ 'id=1234' => 'Find templates, fields, pages with id 1234', '1234' => 'Same as above but “id=” is optional', ]); } That's the gist of it. These are fairly basic examples but hopefully communicate enough to show that you can add any kind of results you want into the search engine. Right now it's pretty simple and enables anyone with a ProcessWire site to add custom results into the admin live search. But if you find your needs go beyond this, the SearchableModule interface does support more options too. It's also worth using TracyDebugger to examine the $data array that the hook receives, as there are several other things in there you may find useful as well. Thanks for reading and have a great weekend!

This week I'm releasing the ProcessWire Fieldtype/Inputfield module "Functional Fields" as open source in the modules directory. This was originally built in 2017 for ProFields, but hasn't required much in terms of support resources, so I thought I should release this newest version (v4) publicly. While this module is completely different from other Fieldtypes, I think it's quite useful and fulfills some needs better than other Field options. Give it a try and please let me know what you think. For an introduction to Functional Fields, please revisit this blog post which covers all the details: https://processwire.com/blog/posts/functional-fields/ Functional Fields is available for download in the modules directory here: https://processwire.com/modules/fieldtype-functional/ Thanks and have a great weekend!

@kuba Thanks for letting me know. Somehow I missed that during testing, but upon investigation it looks like I was using some old school configuration ideas in there that didn't make sense anymore. I was never able to observe the issue myself, but I bet it was related to that, combined with the other updates I made last week. I've gone through and refactored the whole configuration processes of the module up to modern standards so that it should work correctly now. I just tested it thoroughly in both single and multi-language mode again. Please let me know if you run into any other issues with it.

@bernhardTwo things I can spot here: 1. You are calling renderReady() from a hook after Inputfield::render. That is too late. What @adrian mentioned about hooking Inputfield::renderReadyHook() instead would likely enable you to do what you want to do. 2. Your renderReady() method has if(!$grid) return; and you would need to change that to if(!$grid) return parent::renderReady($parent, $renderValueMode);

This week the core dev branch version remains at 3.0.239 but relative to last week, it contains several optimizations and improvements. Details can be found in the dev branch commit log. I've also moved two Textformatter modules out of ProFields and into GitHub and the modules directory. These include: Auto Links This Textformatter module automatically links your specified phrases/words to your specified URLs. This is a potential SEO and accessibility tool for creating automatic contextual links with little effort. If there are pages that you commonly link to in your site from your textarea/rich text fields, then this Textformatter can save you some effort, automatically linking to those URLs. Text Blocks This Textformatter module enables you to assign a name to any block/region of text in a Textarea field. They are defined by typing start_name where you want the block to start, and stop_name where you want the block to stop. The block(s) of text can then be shown in any other Textarea field at runtime (site-wide) simply by typing the block name on its own line in the format show_name. Note that the word "name" in all of these examples would be whatever you've decided to name the block. Both modules have been updated just for public release with a new version. Both are considered Stable, as they have both been running without incident for several years. These modules were moved from ProFields to the public modules directory for three reasons. First is that they don't consume hardly any support resources, so they don't need to be commercially supported modules anymore. Second is that I'd like to keep ProFields focused more on field related modules (Fieldtype, Inputfield, and related) rather than Textformatter modules. Though admittedly the TextBlocks module does blur the line a bit, as it promotes potential greater reusability with existing Textarea/TinyMCE/CKEditor fields. Third is that there's already a lot in ProFields and I wanted to make room for new modules, such as the recently added PageEditChildren, which is part of ProFields at least in the short term. The FunctionalFields module may come out of ProFields well, as it hasn't required much in terms of support resources recently, though it is a useful Fieldtype/Inputfield module that is very much in keeping with the theme of ProFields, so I'm still debating on that one. Thanks for reading and have a great weekend!

@kuba Most likely this week.