ryan

@FireWire Apologies, I still don't completely follow what you are trying to do in the code above, but wanted to comment about a couple of things. This is because at this point in your code, you've only dealt with the Field object (or in this case a CustomField object), and no $page has been involved. Since values are stored with pages, all you've got here is a set of blank Inputfields, which probably isn't useful for anything. In this case you are iterating that Field object, which I don't think has any value. What you want to iterate is the value from the page. So if your CustomField is named "custom_field": foreach($page->custom_field as $property => $value) { echo "<li>$property: $value</li>"; } Are you setting an 'addClass' property to your Inputfield definitions in your /site/templates/custom-fields/field_name.php file? And you want to use the value of that property somehow on the front-end of your site? That property is for adding a class to the Inputfield in the admin, but if you want to have access to it on the front-end of your site, I suppose you could do this: $defs = $fields->get('custom_field')->defs(); /** @var CustomFieldDefs $defs */ foreach($page->custom_field as $property => $value) { $f = $defs->getPropertyInputfield($property); echo "<li>addClass for $property is: $f->addClass</li>"; } But you might also just consider going straight to the source, by including your field definitions php file directly: $defs = include('./custom-fields/field_name.php'); /** @var array $defs */ foreach($page->custom_field as $property => $value) { $def = $defs[$property]; if(isset($def['addClass'])) { echo "<li>addClass for $property is: $def[addClass]</li>"; } } Note this will only work if you don't have your properties nested within fieldsets. If they are nested in fieldsets, you can still do it, but you'd just need to account for that in the code. You wouldn't need to account for it in the example above this one.

Looks interesting! I just created an account https://pinkary.com/@processwire. I'm not sure what happened to Twitter but seems like it's gone downhill. I don't have an appetite for it. I've only kept the ProcessWire account on Twitter to post links to new blog posts, but not sure I'll keep doing that. Threads seems a lot better, but I don't think there's much of a webdev community there, that I've found anyway. This forum is my favorite social network. I look forward to trying out Pinkary more.

@FireWire You can just iterate $page->your_custom_field as if it were an array. There are a couple of foreach() examples in the blog post, in the section headlined "Outputting custom fields". Though let me know if I've misunderstood what you are looking for.

As far as JSON column types, the module lets you choose between JSON, TEXT, MEDIUMTEXT and LONGTEXT (or is it BIGTEXT, I can't remember). The main difference between them is how many kilobytes/megabytes/gigabytes you can hold. Functionally I can't tell any difference between them, and you can easily switch between them in the module settings. But as I understand it, JSON columns have the benefit of being more optimized for MySQL JSON-based queries, even if those queries still work on the text column types. I expect there may be a measurable difference at larger scale that isn't yet apparent at the scale I'm currently working at. The downside with the JSON column type is that you can't have a FULLTEXT index. So you can query individual subfields/properties, but can't perform a text search on all of them at once. As I understand it, JSON column types also have the benefit of being able to support MySQL 8 multivalue indexes. These enable you to pick and choose which individual fields within the JSON you want to index separately, or combine several of them in one index. I plan to support these with CustomFields in a future version. For now, I find MEDIUMTEXT to be a good fit for my project, as I do like to be able to perform text searches on the entire field at once, while also being able to query individual fields within it.

I've got a lot of travel coming up in the weeks ahead, so there may be a few quieter-than-usual weeks in terms of core updates. I'll be in and out of town a few times, and I'm not much of a traveler, so will see how it goes. I'm not yet sure whether I can do work remotely, or what will be available in terms of internet access. There's a lot of client work to wrap up before hitting the road, so I've been focused on that this week and will have to next week as well. It's all ProcessWire related work though, so still having fun. There have been a few core updates this week, and there will likely continue to be in the coming weeks, but just not major core updates. By November hopefully all will be back to normal in terms of schedule. I'll be focused on getting a new main/master version out then. I also expect to have a new version of the CustomFields module (from last week's blog post) ready in the next week or so as well. Thanks for reading and have a great weekend!

@Robin S These property/subfield definitions are in files rather than the database, so there are no database-style IDs. Or, you can think of the property names as the IDs. There is already is a to-do note in the module to add support for property aliases, so that you can rename properties without having to convert data. That's not in this v1 beta version, but likely will be in the next one. That will enable you to rename properties when/if the need arises. But you'll still have to update your own code that refers to any of those names, as would be the case with any other field. When it comes to deleting properties, the no-longer-needed data would be cleaned up whenever it is saved. This is like any other Fieldtype that encodes multiple properties/subfields together (Textareas is one example, Combo is another, depending on the chosen storage method). If you regularly need to rename and delete these kinds of things after development of a site, regular old ProcessWire fields (without subfields) are hard to beat. But either way, you still have to consider your own code that's referring to those fields. Thanks, I will correct the typo!

@Jim Bailie If I understand the question correctly, you want to convert several regular ProcessWire fields into a single Custom Field? There isn't an automated way to do that. I suppose there could be though, as they are using all the same configuration properties.

@Jim Bailie They are defined just in a PHP (or JSON) file, so exporting (or importing) the definitions would be just a matter of copying the file from one system to another.

This week we introduce a new module named Custom Fields. This module provides a way to rapidly build out ProcessWire fields that contain any number of subfields/properties within them. No matter how simple or complex your needs are, Custom Fields makes your job faster and easier. Not only does this post introduce Custom Fields, but also documents how to use them and includes numerous examples— https://processwire.com/blog/posts/custom-fields-module/

Strange I'm using Chrome on Mac too, is anyone else able to duplicate that issue?

@adrian I'm not seeing that here, maybe it's browser specific - what browser are you seeing that issue in?

This week the most useful core update is likely the refactored column width slider in the template editor, located Setup > Templates > [your template] > Basics > Fields. You may or may not already know that clicking, holding and dragging the percent indicator on the right side of each field adjusts the column width. With the term “column width”, I mean the width of the field in the page editor, for when you want to have multiple fields in different columns on the same row. It’s a convenient and time saving shortcut. But it was also a little tricky to use, as it allowed anything between 10% and 100% in 1% increments, and it was a little finicky trying to get the percentages just right sometimes. It’s something that’s been bugging me for awhile, and @Pete messaged me on Slack this week and mentioned it. He suggested making it operate in 5% increments rather than 1% increments. He also suggested making a double click of the percent indicator open up the dedicated column width range slider that allows for more precise adjustments. I thought those were good suggestions, so I went ahead and implemented them this week. In addition to now using 5% increments, it also supports the commonly used 33%, 34% and 66% width values as well. But if you happen to already have some field that is using a less common width, like 27% or 72%, etc., then it reverts back to 1% increments for the same behavior as before. Of course, you can also use the 1% increments by double clicking the percent indicator to open the dedicated column width range slider. Thanks Pete for the suggestions, I think it all works better now. I’ll be applying the same changes to FormBuilder’s equivalent of this feature as well. This week I’ve also been working on the new CustomFields modules (FieldtypeCustom and InputfieldCustom). Most recently I’ve been working on adding support for multi-language fields, as well as adding more examples and tools to make it really easy to use and configure. I may have it ready as soon as next week or the following week. The PageAutosave module is also getting a new version soon. I’ve been focused on the LivePreview feature of it and making a version of it that doesn’t depend on auto-save. The alternative LivePreview option (which we’ll just call “Preview”) will work anywhere because it has no field limitations. It simply updates the preview window whenever you save the page. While that’s not as fancy as live preview as-you-type, it’s still very helpful, while being reliable in any situation. It’s reliable and portable enough that I may end up putting the feature in the core, but will be testing it out in the next version of the PageAutosave module first. Have a great weekend!

We couldn't use a cloud version for the core of course. TinyMCE 7.x version would be bundled in InputfieldTinyMCE the same way the current one is. It may be that the cloud version is used for the Pro module though (if that is built), as I think that's how the company distributes their commercial version, but I don't really know. I'll be sure to ask more about it when the time comes. Interestingly, the person I talked to seemed to be involved with both CKEditor and TinyMCE. It appears they are now owned by the same company: https://www.tiugotech.com/tools/

I was able to speak with someone at TinyMCE on a Zoom call this week and we had a good meeting. They are going to make it possible for us to continue using TinyMCE 7.x+ in the core, even though it is using a GPL license, while we use the MPL 2.x license. They will make a custom license available for ProcessWire and I hope to have the details of that potentially next week. We’ll have to review the conditions and everything to make all is good, but it sounds like it will very likely solve the issue for us. I’m really happy about this and look forward to working with TinyMCE 7.x They also expressed interest in us potentially collaborating on a separate module that would make some of the commercial and advanced TinyMCE features available to ProcessWire users that wanted them via a paid service, like a Pro module. This option hasn't been available to us before, so I thought it sounded interesting. I'll definitely be communicating with them more about that to see what's possible. That’s all I know so far, but will keep you up-to-date as I learn more.

This week I've bumped the dev branch version to 3.0.241. Relative to the previous version, this one has 29 commits with a mixture of issue resolutions, new features and improvements, and other minor updates. A couple of PRs were also added today as well. This week I've also continued work on the FieldtypeCustom module that I mentioned last week. There were some questions about its storage model and whether you could query its properties from $pages->find() selectors (the answer is yes). Since the properties in a custom field are not fixed, and can change according to your own code and runtime logic, it doesn't map to a traditional DB table-and-column structure. That's not ideal when it comes to query-ability. But thankfully MySQL (5.7.8 and newer) supports a JSON column type and has the ability to match properties in JSON columns in a manner similar to how it can match them in traditional DB columns. Though the actual MySQL syntax to do it is a little cryptic, but thankfully we have ProcessWire selectors to make it simple. (It works the same as querying any other kind of field with subfields). MySQL can also support this with JSON encoded in a more traditional TEXT column with some reduced efficiency, though with the added benefit of supporting a FULLTEXT index. (Whereas the JSON column type does not support that type of index). For this reason, FieldtypeCustom supports both JSON and TEXT/MEDIUMTEXT/LONGTEXT column types. So you can choose whether you want to maximize the efficiency of column-level queries, or add the ability to perform text matching on all columns at once with a fulltext index. While I'm certain it's not as efficient as having separate columns in a table, I have been successfully using the same solution in the last few versions of FormBuilder (entries), and have found it works quite well. More soon. Thanks for reading and have a great weekend!