ryan

Good, yeah I’m happy with it too. But I’m just thinking having a regularly updated fresh look would be helpful for attracting new users. It wouldn’t be at the expense of keeping a solid utilitarian theme for when more serious work needs to get done. Sounds good. If that’s the case, maybe a good place to start would be for some of the skilled designers in the community to propose some tweaks to what we already have. I personally would like to see something fresh on a regular basis, but again, not at the expense of also having something solid and consistent. PW supports multiple admin themes for many reasons. Sounds like a good idea. I wouldn’t know where to start with deciding what specifically is adjustable in this way, but I could certainly make it happen on the configuration side. I was not aware that AdminThemeUikit couldn’t be extended. It was intended to be extendable. Most likely there’s a simple fix. I will correct that. It’s already quite hookable. But if you can tell me more specifically what additional methods you’d like to be hookable, I should be able to do it. Can you give an example use case? In ProcessWire, all modules already have access to the internal API, which is always going to be more powerful than an external one could ever be. So I’m not sure I understand yet how shared code like modules would benefit in this case. So far as I understand it, this seems like it’s the primary benefit in the PW context. I think there’s likely a distinction between new users that are used to some other platform, and new users that haven’t spent a lot of time in other CMSs. In my experience, users new to CMSs (rather than just new to ProcessWire) figure it out very quickly, with little or no guidance. Whereas users used to something else (WordPress, etc.) encounter something entirely different, and everyone inherently prefers what’s familiar. But users are going to increasingly be "used to" something or another, and more likely WordPress than not. That used to be the case around here too. But today I’m finding more seem to be aware of the downsides of WordPress and the liability it brings. It’s seen as a target and a risk with baggage. At least if there isn't someone keeping an eye on it and taking care of it; so it's a responsibility, which means it's also a cost. But the fact that you can run any version of ProcessWire (even a 10 year old version), without worry, it says a lot. Meanwhile, ProcessWire has been powering websites for as long as WordPress has. But it’s been doing so without the risk and drama. Like I say, PW’s record speaks for itself, as does WP’s. Given a choice of popularity or long term security (which is what it comes down to), I leave that for the client to decide what's in their best interest. ProcessWire may have been a new player or unknown factor at one time, but that was a long time ago. Not only is it open source, but ProcessWire has more than a 10-year track record in open source, and a 17 year development record in total. It is used by tens of thousands of websites by thousands of web developers worldwide. It has been in active development the entire time. There is nothing proprietary about it (open source and PHP). It is well documented. It is coded in a manner that makes it accessible to any competent PHP developer. It is both developer and community supported. And when it comes to things going wrong, it’s far less likely to happen in ProcessWire in the first place. Other projects come and go. I think it's safe to say ProcessWire has been, is now, and will continue to be one of the most stable players in this space. Yes, again for appearances. But there's not much downside here. I’ll try to give this some more focus. How does that work? Is it anything other than dg just committing code from adrianbj (same as a copy/paste), or does it have something more technical going on with regard to the merge?

@Zeka Thanks, I still feel this is redundant in PW, but it's been mentioned enough times that I can't rule it out. So will keep eyes open here. Yes, if you mean things like S3 storage or similar, this is something I've been interested in too. This is definitely on my wishlist too.

Awesome! Thanks @Jonathan Lahijani that would be great.

Ouch. But this is really common. When it comes to a developer working at a company, new software is sometimes a threat. It's always easier to work with what you already know than to take a risk on something new. JSON files are nice and simple, so it's hard to argue with the sole developer and content editor; maybe PW is overkill for his needs. There's nothing hacky about getting PW data into JS. It's very simple. But I get what you are trying to say, is that PW doesn't do it, so it's the developer that chooses how to do it. Here's the problem, and reason why I haven't made PW do it, as simple as it is — the only real front-end input request that returns data from PW is the URL. And the contents of the returned data is at the discretion of the developer. That's it. It's incredibly simple and an amazing security barrier. Once you have a JS API to PW data, it sounds really cool... until you consider the security implications. What makes the PW API so useful is that you have access to everything as if it was already in memory. This is great in PHP because only PHP has access to it. But anything that JS has access to is also open to the world. Anything could slurp up anything from the API at that point, not to mention it would be a huge denial of service hole. The exception is if it's all behind some kind of authentication. But the vast majority of PW websites are not built behind a login wall. So then we might say, we just apply restrictions to what can and can't be loaded from the JS API. But at that point, it's taking just as much work as if we just output our own JSON, while still likely not as secure. I remain really interested in the idea, but so far have not been able to get the math to add up in being a worthwhile venture. I even built a module years ago called ServicePages that did some of this, and I got so disturbed by the potential implications of it that I ended up deleting the module permanently. Meanwhile, outputting just what you need for your JS remains 100% secure and simple. Maybe someday we can get the math to work here though. I think it's great he's building this. While I don't think the core needs to expand in this direction, I really like to see modules like this get built that can fill needs as people have them. The more the core can support people in building modules that solve their needs, I think the better. There are very good reasons why the admin and front-end are different environments that do different things. I think it's best if the core doesn't dictate much about the front-end, and always trying to keep PW as far from generating markup as possible. So I don't think it's likely PW would provide all of the admin in the front-end, other than the existing front-end editing features. But I don't think that's what you meant. Can you clarify about what you are looking for here more specifically? What front-end functionality have you built that you think should be in the core? Interesting, I don't know much about this, but it does sound like a good Fieldtype to have. What do you use a recurring date for on the front-end? I don't have a good answer for that particular issue report because it's asking to disable access control in a manner that I just don't know how to do safely. But I'll look at it again. There will always be little things, especially for people like you and me, who work in PW more than the most here, and probably represent less than 1% of the PW users. But I have to balance time between the little things and the big things in order to keep everyone happy. Likewise, when it comes to prioritizing issue reports, I have to consider how many people are affected by an issue and whether workarounds are possible. Hundreds of minor issue reports were resolved in 2020, and likely 1-2 months worth of hours getting through them. This is part of the job that I do every year and will continue (and actually I enjoy it). I could spend 6 months doing nothing but issue reports, but it likely wouldn't make any difference to 99% of users and would hurt the rest of the project. So I try and find the right balance. I don't know who would need that feature other than you and I didn't even know it was there, but if this is a major pain point, maybe we can build you a voice command for it. ? Kidding aside, I agree that it's good to start thinking about new stuff in the admin theme in 2021. I like the current Uikit admin theme, but I also used to like the old AdminThemeDefault too, and now it looks so primitive and behaves so clunky relative to AdminThemeUikit. So I imagine to some users, maybe the AdminThemeUikit is starting to feel old since it's been around for a few years now. Ideally we'd have a new admin theme design every year, and maybe someday we will. I'd like to stick with Uikit 3 as the underlying framework, but the look/feel can be a blank slate.

Yes the flexible content one seems to be a recurring theme, so I’m interested in that. As far as non-external headless, ProcessWire was the first to do this, at least as far as I know. The admin was later built in as an application in ProcessWire. For external API headless, this has been something I’d planned to do years ago (per old roadmaps and JS APIs). But, when it came to actually starting to implement it in the way I thought it would be useful, I found it opened a can of worms in terms of security. And security is one thing that you can trust I won’t make compromises on. I’ve come to settle on being comfortable with an external API so long as it is protected by very strong authentication. But then it also becomes less of a common strategy to build around, and more of a specialist thing… maybe useful to a small percent of users. Maybe there’s a middle ground and it’s worth revisiting this year. I've recently been in contact with @Brett who is is working on some really cool stuff with GraphQL (and more) and ProcessWire, which I'm following very enthusiastically. I definitely wouldn’t expect it to feel as slick as anything built for the purpose, as RepeaterMatrix was not intended for that. But the fact that it can be used at all for that need means we’ve probably got a good head start. Since this strategy doesn’t really fit in the projects I work on, it leaves me at a bit of a disadvantage in being an expert on it. Nevertheless, I’m interested in building it, but might need someone else work with. It sounds like you have a lot of experience here, interested in collaborating on it? This is subjective of course. I’m the opposite, a sidebar drives me nuts. But I’m not against sidebars, just against sidebars for when I’m using PW (or anything else where I have to be productive). I’m simple minded and easily distracted, and focus on one thing at a time. I can't do the multiple-monitors thing, and whatever window I'm working in is always maximized. Sidebars always compete for my attention in a way that other things (like mastheads or footers) don’t. But I'm probably the minority in this preference. When it comes to our next admin theme (or evolution of the current) I think it makes sense for something like a sidebar to be a configurable option. I’m too many years beyond my graphic designer days now, so I don’t think I should lead the next iteration of the admin theme. But I do think it’s a good time to start thinking about the next iteration of the admin theme, as well as dropping the older ones. I think you are providing good answers to the question. Unique and groundbreaking are not requirements by any means. The core is in a really great place right now, the foundation is solid, more so than the other projects out there. So now’s the time to start looking for what’s going to the most helpful to current and future ProcessWire users going forward, and start implementing them. This is the drawback of having a developer that’s committed to a project for life. I could be wrong, but I don’t think there are many projects like PW where the developer has been working on it for nearly 20 years, and is committed to working on it for at least another 20 or more. Not to mention, committed to make it easy for others to work on as well. Most people work on stuff and then move on to other stuff. I don’t do that. So I look at every PR a lot more critically than I think most projects do. The PR submitter submits the PR and that’s the end of their responsibility. Whereas, every bit of code that gets added to the core is something I accept responsibility for. It's something PW users and my clients trust me to vouch for. I look at new code in the core through the lens of supporting that code for the next 20+ years. Nevertheless, I do try and identify PRs that can be added and supported, and then take the time to understand how they work, and even recode them if necessary to fully understand how they work, so that I can support them in PW’s core for the long term. It takes awhile to work through them, but I’ll continue to do that. My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through. PW will always be a project that puts security, stability and long term sustainability above appearance or popularity. I understand there are times where a project calls for using what’s popular, and I see no harm in doing that, so long as you are also committed to supporting that decision as being in the best interest of your client. PW’s track record speaks for itself. WP’s track record speaks for itself.

Thanks for the feedback. Just to be clear, this question is not looking for answers about the location of issue reports, wishlists, PRs, or feature requests. All of that is already clear, always important and ongoing — great stuff, but also information we already have. It never hurts to be reminded, and of course we'll be working with much of that in 2021. But that's not what I was asking about. Zoom out and look at the bigger picture, and look towards the future—what's game changing and "next level" for the years ahead that we might not already know about? It doesn't have to be unique to PW either; maybe you see another project doing something major that would be nice for PW to also be able to do. I might be unique in this respect, but when I develop sites in PW now, it doesn't feel as though I'm lacking or compromising anything at all; everything I want and need is there. But my needs are also pretty simple. I do know that in the last couple of years, Markup Regions and custom Page classes were the two most recent game changers [for me at least]. But that's all the past. There will be more game changers for you and me, I have some ideas about things, but nothing concrete. I recognize this is something that's going to be personal and different for everyone. For the majority, I really doubt that any single product meets every need you have, whether ProcessWire or something else. But the intention is that ProcessWire can meet most of them, and better than other projects, for our current and future users. I'm trying to put together a long term, big picture roadmap (2021 and beyond) that keeps us focused on that. I have thought this sounds interesting no doubt. I'm interested. I'll catch up with it again. Not speaking of this particular feature request, but more in general. Unless it's something most people need, I look at a lot of specific feature requests more from the perspective of "how can the core best support someone in being able to fill this need?" (from a module, hook, etc.). For stuff where the need doesn't also surface in my own projects, I'm not an expert on it, so I'm not as likely to be able to please the people that do have the need. But making the core flexible enough to accommodate some need with module or hook, or something else—that's where I am an expert and can provide a lot of value. Improving the core by expanding its flexibility in accommodating things for people that wanted them, and not necessarily expanding what it does on its own. I like the GitHub requests repo or the Wishlist forum. But if you already have a GitHub account, I think it's a little easier to keep track of there. I'm not all that familiar with this as it seems to be a strategy that doesn't really meld with the types of projects I work on. But I've always been interested in it, and it seems to fits the big picture role I'm talking about. It's something I'd like to spend more time with in getting to know better. I know a lot of people use various strategies here already. But it's adapting things like repeater matrix to fill the need rather than something more designed for the purpose. I'm curious if you could expand more on why this is your personal favorite and how you would use in in your projects? I think this is something that might be too specific of a need (I'm guessing not many run into it). But it is actually a need I have had here. I've always answered it just by building whatever feature was needed into the front-end of the site. So the front-end basically has a custom-admin portion, for logged in users that have a particular role. Usually it's publish/unpublish/approve/disapprove something or another, list reservations, toggle things, etc. Simple stuff that needs little explanation. Though when the need involves full page edits (body copy, images and such), that's really what PW's admin is for, and that's where I'll put them. But if a user doesn't need to be using the page editor, then I don't bring them into the admin at all; and instead use the API to for simpler admin functions built into the front-end. Is this similar to your use case, or are you thinking of something different?

Happy New Year! Today I’ve bumped the version on the dev branch to 3.0.170, and it’s quite a lot of updates. This post covers most of them. In this post, there’s also a question for you: what would you like to see in ProcessWire in 2021? https://processwire.com/blog/posts/pw-3.0.170/

This week I’ve been doing some work on the core, but it’s been a short week with the holidays, so I’m holding off on committing the updates till I can test and tweak them a little more next week. I’ve been working on some upgrades to the core Fields editor (Setup > Fields), as well as some improvements to our Inputfields system, among other things. Next week I’m also planning on working through some of the GitHub issue reports and some other parts of the core as well. With it being Christmas today, I’ve barely been at the computer and I’m guessing not many of you are either, so I’ll keep this short and wish you and your family a Merry Christmas and/or Happy Holidays!

I see, yes that's true. If you move all the subfields out of it, then it's basically just a non-visible placeholder at that point.

@Robin S No doubt, that would be nice. But as far as the core goes, that's a pretty major project and involves creating a new interface method for all Fieldtype modules. It could be months, and I'm not sure we'll ever get into that or not, or whether 3rd party, etc. Whereas, this was something simple that could be added today, right now, that will at least make the option available. If it sees a lot of use, I'm sure we'll keep expanding the options. But as it is right now, Combo is the only field that can do this (thanks to your contribution), so I think it probably makes sense that it's also the place where you specify it, at least for the moment. It's not perfect, but very often pursuing perfection means either never starting, or never finishing. ? @adrian Actually the list position is still relevant, it just becomes relative to any other fields that have been moved to the same field. Or if the field being moved-to is present in one template and not another where the Combo field is used, then the list position is also still relevant when it displays in the Combo field. Let's say you specified the same "body" field for all of the subfields in the Combo (to insert after). It would move all those fields after the "body" field in the page editor, and they would retain the drag/drop order you have put them in. The end result would look the same as the Combo field, but without the wrapper/fieldset. I had to play around a bit to get this working, but it is in the version I posted, so wanted to mention that the list position still matters, especially if moving multiple subfields to the same location.

I've updated Combo to use @Robin S strategy for moving the subfields around the page editor and posted it in the ProFields download thread as v2. The definition is available for any Combo subfield and it's very simple, but I figure it's something at least to start with.... it's working and ready to use. It does use a datalist-based autocomplete, so you don't necessarily have to remember all your field names. Thanks Robin S. for the idea on how to make it work, it seems to be a clean and reliable way to do it.

@Robin S Great idea, that's a nice proof of concept. That getInputfields() method is only in Combo, so I hadn't even considered using it for that purpose, but looking at the way you've done it, it looks like it actually is possible to do this, and without JS. Nice. I was thinking JS might be the only way since Combo is an Inputfield that renders markup, rather than an InputfieldWrapper that keeps a collection of Inputfields that can be grabbed and manipulated. But using that getInputfields() method seems to get around that limitation, opening up the ability to detach those individual Inputfields via hooks. Does everything seem to work during form processing and such? It looks like the Combo Inputfields might get processed twice on form submit? If so, you could make it conditionally add the buildFormContent() hook only if empty($_POST['id']) or something like that. But since it's a proof of concept, that hardly matters. If you don't mind me experimenting further with your idea here, I will see what I can do to build something like it in. Even just a simple subfield setting in Combo that lets you specify "Insert this subfield [after or before] [field_name] when present in the form" seems like it could add value here without adding too much configuration baggage.

@Robin S Since it sounds like you came up with a solution in Textareas, how did you do that? How does it work? Since this is page editor presentation thing, I was thinking maybe it rearranges them on the front-end (JS?) or maybe it rearranges the Inputfields before the form render?

Worries? Combo achieves these these goals perhaps the best of all the ProFields. And all of the ProFields achieve these goals and more, and I stand by that 100%. If we could solve every use case with one field, we'd only need one. But there are several ProFields because each solves a different use case. That's the point. To gain the benefit, you have to use them for what they are designed for. No field in PW can pursue the use case mentioned earlier because it's outside the scope of what fields can do or are even for. I'm interested in the use case still, but for the core, not for any individual field, where it would be technically impossible. Good strategy, and same here. I don’t often reuse fields unless the name makes sense for it. That’s how it’s supposed to work. It’s the more generic (title, body, images, files, headline, summary, etc.) that make the most sense for that. Though in my case at least, the reusable fields are also the ones most used, since they generally apply to almost all templates. Yes, I wouldn’t do that either. Though something like “headline” and “headline2” or “body” and “body2” (or further) might be fine as it’s not uncommon for a template to represent primary and secondary headline/body content, and for that need to be a recurring one on multiple templates. Respectfully, I think that’s backwards, and not a correct statement in my opinion. You are of course entitled to your opinion, and no problem, but I would not put my time and effort into building something that “isn’t beneficial in very many cases.” These fieldtypes (and Combo in particular) I think are beneficial for a ton of cases. In the case of Combo, it’ll likely be one of the first modules I install on every site I work on, and have no doubt it’ll be the same for others. Everyone has different needs, but I think easily more than half of all ProcessWire users will find major benefits in Combo. But I don’t claim that ProFields or even ProcessWire will solve every need that every person has ever had either. Though my hope is that ProcessWire is the platform for solving most. And combined with ProFields, even more so. Btw, Textareas and Combo are completely different animals, and while they keep getting mentioned together, they really have no relation to one another other than that they are both ProFields. Relative to using separate fields (first_name, last_name, street, city, state, zip) I think the performance benefit will depend on when and where you are using the content of those fields. If you are using all the info in those fields in a given request, then it will be a definite worthwhile benefit. If you are more often just using the "city", then probably not a benefit. In reality, this particular example is too small for it to matter one way or the other. So I would say for this case it depends on whether you prefer to treat these bits of content as a group or not (in your page editor, in your template placement, and in your code). Likewise, if you are reusing that combination of content (group), it’d be a lot simpler to just add the Combo field to a template rather than all the fields individually. Same goes for whenever you want to change something about it. It adds a lot of development efficiency to work with the combo rather than always all the bits within it. Or maybe even a 3rd option: use both. But only you can decide what option best suits your need. They are all good options. This is a concern I have with what’s being asked for with mixing subfields and fields together. It’s confusing for me at least to start mixing up what these things are. They would definitely need to be well isolated, though I think Robin S.’s screenshot did a good job of that making it clear what was what in terms of the definition stage. I would find it confusing in the page editor though, as the editor would no longer accurately reflect the actual field. Could be an issue, or not, I’m not really sure. Count me is interested, but just not in achieving it with a field like Combo, since it’s not even possible. But it is possible in the core. And it sounds like it may be possible to some extent in a module (per what Robin S. as developed), though I'm not sure exactly how, but am curious. This is not at all true, so I’m assuming this is just a hypothetical “if” for your particular use case. There is indeed a performance advantage, and it can be major. And for most it will be significant. But like with anything in software, it depends on what you are doing and how you are using it. If you are actually using the content as a group (as intended), I think the performance benefit can be major, as the effort of loading multiple fields is now reduced to the effort of loading just one. If you are wanting to use it as a storage container for other unrelated fields that aren’t used as a group, and may be used inconsistently, performance would be better served by regular PW fields, which are already designed for this and are already quite performant. Based on everything you’ve mentioned, I agree that think your particular needs sound like they are best served by PW fields. Combo offers a lot of flexibility, but it was never intended to replace all that you can do with templates and fields. It is itself still a field, after all. Combo would be very useful for this, no doubt. A group of normal content fields is a fine use case for Combo. But if wanting to use it as a storage container for some normal content fields that don’t really go together, I agree that you’d want to resist the urge to use it in that way.

When I talk about the goal of ProFields being to reduce the number of fields necessary, I don't mean that to stretch into “at all costs”, going beyond what would be logically related in a fieldset or object, or stepping outside the responsibility and purpose of fields. All of the ProFields are focused on reducing field usage for cases where logically grouping them makes sense: visually, semantically, structurally. ProFields are not intended to hack around, change the meaning of, or blur the lines of what’s provided by ProcessWire. ProFields are designed to work with ProcessWire, using its interface and architecture to maximum effect, extending it in the way it’s designed to be extended. There’s nothing that a field like Combo (or any other) could do to make its subfields start pretending they are regular fields. So it’s not even a request I can entertain because it’s simply not possible for a Fieldtype to get involved in that. Don’t look for any ProField (or any field) to do this, because that’s well outside what a field can do technically, and outside of its responsibility or control. If you find yourself having this interest for subfields in a particular field tossed around in different locations of the template, take a step back and ask why. Then consider, this is what ProcessWire fields do, it’s what they are for, and they do it without breaking the borders of responsibility or blurring any lines of what they are. There’s nothing wrong with using regular ProcessWire fields for their intended purpose. Neither Combo nor any of the ProFields are meant to replace that. ProFields answer specific things, they are not intended to replace the template-field relationship, nor could they. Use ProFields where they cross over with a specific need they answer, and skip them when they don't. I understand subfields are cool and popular now, but fields are still where it’s at. Templates are still templates and fields are still fields. A Combo field is also still a field (not a template), and a subfield is still a subfield (not a field). I’d drive myself mad and have an unmaintainable code base if I started mixing up these things or breaking their relationships. I’d like to better understand why you would want to do any of this stuff in the first place (versus just using Fields how they are supposed to be used). Is it because you want them to be stored together behind-the-scenes so that they can be searched as one? Is it because it’s less tables to look at in your DB or less fields to see in your Setup > Fields? Is it because you think it might use less memory/resources that way? Or something else? I think if I understand what the underlying point of this is, that would be helpful. If it turns out that there really is some significant and real benefit in doing this, that can’t be met by using the system as intended, then I’d be interested in looking into it further. But it’s something that would have to be considered in the core and managed by the template (fieldgroup component). That’s because a Field getting involved in the responsibilities and relationships of templates to fields would be bad architecture and a broken system. Whereas, if the core provided an interface where a Field can specify which of its subfields are allowed to be visually “detached” in the page editor, and the template and page editor know of and read that interface, that’s where the architecture could work (no responsibilities broken). The Uikit theme is not a requirement of Combo, so if you find Reno isn't working, that's likely just a 1st beta version glitch that I need to work out. I'll get that figured out.

I’ve just released the first version of the ProFields Combo field and it’s now available for download in the ProFields support board download thread! Rather than writing a long post today, I’ve instead focused on writing the Combo field documentation. The documentation page includes a lot that you may already know from previous posts, but it also includes a lot of new details that haven’t yet been posted. Please consider this version to be a development/beta version. It’s the first release and hasn’t had a lot of testing yet, so consider it not yet ready for full production use. Though if you get a chance to test it out, please let me know how it works for you. I appreciate any feedback you have. A couple things I haven’t yet tested thoroughly enough yet are exporting/importing of Combo fields or pages using combo fields. I also haven’t done enough testing in FormBuilder yet. So I’d recommend avoiding use of PW’s field or page export/import functions with this, or using in FormBuilder, at least for a few days. By next week I will have tested those things and made any necessary updates. Thanks for reading and have a great weekend!

@adrian Having the option in something like Combo is definitely a nice choice. But like with the Table field, it places limitations on what kind of fields you can use in it (focused on simpler types), and what those fields can do. The approach isn't nearly flexible enough for a "supports any kind of field" modular system like PW. For instance, you could never have the likes of a Repeater field in a Combo field, among others. So it's kind of limited and primitive in that respect. But for a focused purpose module like Combo, that's where I think this approach is really useful and worthwhile.

@adrian It's definitely possible, and maybe we'll add the option for that. For this first version though it loads all the data in the field in the same way that other PW fields do. But you are right that it would likely be relatively simple to have it load them dynamically.

Last week’s post was about the new ProFields Combo field and it seemed like there was a lot of interest. Thank you for that, it really got me motivated to finish it and release it sooner rather than later. I am very excited about the Combo field and worked on it most of this week, hoping that I may be able to have the Beta version ready for release in the ProFields board by this time next week. This is a little more break than I like to take from the core, but the focused development time means it gets done a lot sooner, and likewise in a stable release state a lot sooner. Since I don’t have core updates to walk through this week, I thought I’d focus on some Q&A about the Combo fields. Below are questions that were asked either here in the forums or in the blog post. Please feel free to reply with any other questions that come up too. There are definitely cases where this type of arrangement Combo provides would provide some nice performance gains. And there are other cases where they might reduce it. Consider that fields on a page in ProcessWire are dynamically loaded when you access them. So when you access anything from a Combo field, all of the data in the Combo field loads at once (1 query). So if you’ve got 10 fields in a Combo field, and you are going to be using much of that data in the request, then you’ve just made some nice performance gains, at least relative to having those 10 fields split into dedicated/separate ProcessWire fields. On the other hand, perhaps you are rendering a list of pages, and you only need one or two fields of data from the Combo field. In that case, it’s less efficient than regular ProcessWire fields because you’ve loaded a bunch of data in memory that isn’t going to get used. So I would say Combo fields are great for data that you use when rendering a full Page, but not as great for cases where you are rendering lists or summaries of pages (where you might not be using much of that data). In the blog post I mentioned that Combo fields store data in individual DB columns, but also keep a separate index so that all of the combo data can be searched together. If that’s what you are referring to, I would say the primary downside of this storage method is that it takes up more space. It adds convenience and efficiency for searching, but at the cost of consuming more disk space [in the database]. This is something that may be beneficial to some and less so to others, and it may end up being an optional thing too. The index is similar to a JSON encoded version of all the fields. But it’s something that I think is worthwhile for another reason: backups. Like the Table field, the Combo field maintains a unique DB schema consistent with your selection of fields. Every time you save a Field, it checks the schema and determines whether to add columns, drop columns, or modify existing columns (and likewise for indexes). The JSON encoded version of the data is immune from data loss as a result of schema changes, so I see it as potentially useful as a way to backtrack, should it ever be needed. As for your question about other fields in ProcessWire, Combo stores it exactly the same way as other fields, with the only difference being that it keeps a separate combined index of data; and is able to because the core Fieldtype architecture enables it to do so. Why not use the same duplication approach with other fields? I can't think of any core fields where this type of storage duplication would be beneficial in the way that it is with Combo. Outside of the core, the approach might be worthwhile in ProFields Table though. Yes! Combo fields work in Repeater and RepeaterMatrix fields. Since Combo fields are not a repeatable type, they play nicely with repeatable types. They might look similar but they are also completely different. A page fieldset (FieldtypeFieldsetPage) is technically a single repeater item, but presented in a non-repeatable way. It’s a convenient way to make a group of fields that you could reuse across any number of templates. And in that respect it’s quite similar to Combo, at least in appearance. But that appearance is where the similarities end. Fields in a FieldsetPage are still individual ProcessWire fields defined on a template, and the Fieldset itself is an independent Page (an individual repeater item behind the scenes). So if you’ve got a FieldsetPage with 10 fields in it, then it’s still consuming the resources of 10 ProcessWire fields, plus 1-2 additional pages for structure. The goal of ProFields is to reduce the number of fields necessary to answer a particular need, and that is not the goal of FieldsetPage. If a Combo field can answer your need, it can do so a lot more efficiently than a FieldsetPage can. On the flip side, since FieldsetPage uses regular ProcessWire fields, it can support more types than Combo can. Nevertheless, once Combo is available, I would most often choose it over a FieldsetPage except in cases where I needed a type of field that only FieldsetPage could support. Yes, any field within a Combo field can be queried individually in selectors using the field.subfield syntax. For example: $pages->find(“combo.first_name=Ralph”); It’s just like querying a Page reference field on pages in ProcessWire. So far, my experience is that it can do all of the same things, and supports all of the same operators; whether querying text, numbers, Page references, selectable options, etc. There are technical differences behind the scenes though. All the data in a Combo field for a page is represented by a row in a database table, so matching some types of values (like multi-Page references) has to use indexes rather than lookup tables. This is similar to the approach taken in the Table field. Per last week's post, Combo fields can do one thing that other fields in ProcessWire can’t though. Because it keeps an index of combined data, you can perform text matching on all of the subfields in a combo field together, just by omitting the “subfield” from the selector. An example is that $pages->find(“combo~=Ralph”); would find the word “Ralph” in any of the fields in the Combo, rather than just the first_name field. So not only is it easy to do, but it can do that more quickly and efficiently than other fields in PW. Thanks for reading and have a great weekend!

@matjazp @adrian Looks like we've got a glitch there. Not sure what's up yet, but it seems to be in the old modules directory data and may have been there awhile. Matjazp had 2 accounts somehow and tpr/rolandtoth had none. I added rolandtoth as an author and updated the modules pointing to his GitHub account. I deleted the 2nd matjazp account (matjaz-potocnik) and reassigned those modules to the matjazp account. Let me know if I didn't get any of this right. So far it looks like there is the only case of the glitch, I couldn't find any others like it, though please let me know if you do. By the way, module author names were pulled from the info entered when the module is submitted or edited (on the old modules directory site). They are not pulled from the module info on GitHub. On the new site, module author names are created with the account, and assigned to existing modules sharing the same confirmed email address. That's how it knows which modules are yours after you create your account. Some people might have used multiple emails over time, as I think both Teppo and I did, so in those cases I've been assigning some modules manually. Currently for new modules it just supports one "author", since it is now tied to a dedicated account. (Just like with a GitHub account). So when there are multiple authors on a new submitted module then the README is where you'd want to highlight that. It would also be fine to have an organization or company as the author of course, but it would still just be 1 account.

@adrian Thanks, I have fixed it so it'll update the "updated" date when either the version number, or anything in the module info changes.

This week we’ll take a brief look at a powerful new ProFields module for ProcessWire that’s just around the corner—the Combo field: https://processwire.com/blog/posts/about-the-new-processwire-profields-combo-field/

@MSP01 Thanks for the feedback. 1. I couldn't duplicate that, when searching "admin action" it does find ProcessAdminActions for me at least. Though several days have passed so maybe Adrian recently updated something in the module info that makes it match. 2. The class name is the primary headline. But someone else mentioned this too, I will add something else that specifically indicates it. 3. I also can't seem to duplicate this. Those pages should be redirecting to the new modules directory URLs. Maybe it got stuck on that one for one reason or another. I have cleared the caches just in case.

@nbcommunication I'll have to investigate further, maybe it's possible to support down the road. For the moment, compatibility is based on what you specify in the "requires" section of your getModuleInfo() method, or ModuleName.info.json file or ModuleName.info.php file. But since you are wanting to communicate that the module is not compatible with a previous version of itself, I don't think there's an automated way to do that at present. For the short term at least, if you can't update the module to provide a backwards compatible option, then it might be worth maintaining as two separate modules. Or if you only want to maintain the new one, then maybe give the new one a new name and delete the old one, or update the old version README to instruct the user further. That would at least prevent anyone from automatically upgrading the module and finding it doesn't work.

ProcessWire 3.0.169 contains 19 commits relative to 3.0.168, and most are focused on improvements and minor fixes throughout the core. For more details see the dev branch commit log. This week I’ve also been working quite a bit on a new ProFields module that at the moment is called Combo. It contains both Fieldtype and Inputfield modules within it, and I’ll have more to tell you about it soon. But I can say that it fits right in with the purpose of ProFields, which is: greatly reduce the number of fields needed to accomplish a particular need. And it does so in a way that isn’t easily achieved with any other module at present, so I think it’ll be a nice addition. The Inputfield part of it can also be used independently of the Fieldtype, meaning you could use it in FormBuilder forms, etc. I’ve got to keep it short today because of the Thanksgiving holidays here in the US (my wife is off work and kids have no classes today). Thanks for reading and have a great weekend!