ryan

@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!

@Ivan Gretsky GitHub is a requirement for modules that are automated with regard to automatically pulling version and readme, etc. If someone needs a case where the module can't be managed at GitHub (like a commercial module or other specific case) then I would just ask them to contact me so I can add it manually. I feel it's safest for our users by having downloadable modules provided by GitHub. They have security measures in place that give me a lot more peace of mind than a link to a random ZIP file off on some site none of us know. Without GitHub as a middle man, I think there's a much higher probability of getting something questionable in a ZIP file, whether it's because of a hacked site or any number of other reasons. GitHub also provides great security options for protecting individual accounts, which I think further increases the safety for consumers of ProcessWire modules. The other side of it is that GitHub provides an API that we can read data from in order to ensure our module information is up-to-date and that users don't have to manage that information in more than one place. That API also includes a function to safely convert GitHub-flavored markdown to HTML, which is very useful for the modules directory. Presumably it would be possible to also implement this for other providers (GitLab was mentioned), so if there's significant demand for it then it would be worthwhile. But it took me a long time to implement the GitHub integration as it is, and at present I likely couldn't afford the time investment to implement another different API right now. Down the road I'm open to adding support for more Git providers. For now though I had to work within the bandwidth I could afford to devote to this project. @Mikie The module class name is used throughout, but it's true it doesn't literally say "class name:" anywhere. I think you are right it would help with clarity if it does that somewhere, so I'll plan to add it. As for version compatibility, I'm going through all of the PW 2.x modules and deleting any that aren't 3.x compatible and don't look like they will be. This will take me a little while, but basically the intention with the directory is that you can assume it's 3.x compatible. For more fine grained detail on version compatibility, it's going to read the module info array. It doesn't report that info at present, but this project isn't fully finished yet so it will be reporting more from the module info array in the coming weeks.

There’s a new modules directory on the ProcessWire site now up and running. In this post we’ll cover a few details about what’s changed and what’s new. While last week's post introduced the modules directory, this post (part 2) focuses on newly added features for module authors (just pushed live today)— https://processwire.com/blog/posts/new-processwire-modules-directory/

@adrian The modules directory does not distribute Pro modules or track their version numbers. Though I am planning to have it track version numbers for Pro modules, but that'll be added on once the rest of it is finished. Pro modules will continue to be distributed through the dedicated support boards since IP.Board manages the access for all of it. Maybe someday I can build more in that regard, but I don't have the bandwidth for that currently. The new modules directory makes no changes to the web services portion, which will continue to be provided by modules.processwire.com. I didn't want the changes to interrupt anything, as the web service gets quite a lot of traffic. @Ralf Thanks for the suggestions. I will look into it further. I have found that searching the body for modules introduces a few too much noise into the results, but including the module summary in the search might be a good middle ground. The keywords are of course a good idea too.

This week I’ve been continuing to work on the new ProcessWire modules directory, this time focusing on the front-end editing aspects for module authors. This is the part that deviates the most from the existing modules directory (and makes revolutionary improvements upon it), so none of this is on the production server yet, and it’s going to take a little more time to develop. LoginRegisterPro and FormBuilder are saving a lot of time in the development. LoginRegisterPro handles the account management side, while all module editing forms are powered by FormBuilder. By next week I’m hoping I might be able to launch the new editing features so that module authors can begin to use the system, but we’ll see how it goes. This week there have also been several updates to the core dev branch, including both improvements and issue fixes. By next week I also expect to bump the version to 3.0.169. For more on the modules directory improvements, be sure to also see last week’s post.

@adrian Thanks, pagination fixed. I meant to mention about non PW3 modules above, that I'm going to be removing them from the directory, or at least from the generated lists that it outputs. I don't think there's any need for the directory to maintain PW2 modules anymore, but I wanted to go through them one-by-one just in case there are any that are mislabeled as PW2, or maybe some are still actively developed and work with PW3. But the reason the new modules directory doesn't say anything about PW version is because it was going to be exclusive to PW3 compatible modules going forward.

This week I’ve continued work on the new modules directory and today have launched an updated version of it on the site. This is just an initial version of it, as there’s still plenty to do. But the basics are up and running if you’d like to take a look at https://processwire.com/modules/ The new modules site is using ProcessWire’s multi-instance support to boot a copy of modules.processwire.com and to pull and manipulate data from it. In order to prevent content duplication, I’ve setup most of the pages at modules.processwire.com to redirect to their equivalent versions in processwire.com/modules/. There’s not much new here in terms of data that is being displayed, though it is also different in several ways. For starters, it finally has the look-and-feel of the main site. The modules homepage takes a different approach and lists 3 modules each in these different sections: Recently added modules Recent updated modules Popular modules Modules recently liked by users Modules in the “recently updated modules” section are those that have had recent commits at GitHub. The “popular modules” section randomly selects 3 modules that have a certain threshold of “likes” quantity and date of user activity, combined with being updated within the last 6 months. Or you can view them all (no random selection) at the dedicated popular modules page ... this section will grow as users interact with it. The “modules recently liked by users” section looks for modules that have had the “like” button clicked on recently, and puts them into this bucket. Like the “popular modules” section, this one will grow and increase in relevance once there is more user interaction with the new modules directory. There’s also a new feature on this modules site where you can maintain a “cart” (of sorts) that keeps track of which modules you have liked. In addition, the new modules site estimates how much usage each module has by analyzing request data from the ProcessWire modules web service. This is something the old modules site does not do. It uses this data solely for providing a unique sortable view of modules. Because this data hasn’t been tracked for long, it’ll increase in relevance over time. One area that I want to build out quite a bit more is the module “authors” section. Since the new modules site will be using authenticated login sessions with LoginRegisterPro, we’ll be able to maintain a lot more “profile” info for module authors (full name, bio, photo, website, anything else?) There are a few things still in development, so you won’t see them just yet: Edit module ability (it directs you to the old modules site for that) Add module ability (also directs you to the old modules site) Informational pages (how to install modules, etc.) More to come here, but that’s where it is now. Nothing all that exciting I know, but still an improvement hopefully. If you find anything that isn’t working, or have other feedback or suggestions, please let me know. Thanks for reading and have a great weekend!

We got hit by hurricane/tropical storm Zeta overnight Wednesday and it took down the power lines in our neighborhood, and in many places in Atlanta. We aren’t supposed to get the electricity back till Monday, though I’m hoping they might surprise us and have it back sooner. But I’m basically offline other than my cell phone, charged in the car. I work off a desktop computer (iMac) so not able to do any kind of computer work until the electricity is back. As a result, I don’t have any updates for you this week. Though I was making great progress on the ProcessWire modules directory site up until the storm came through and we lost electricity. For now my job is to keep the flashlights working and find ways to keep what’s left of the food from going bad (since the fridge/freezer is also offline). The same thing happened with hurricane Irma, back in ProcessWire 3.0.75. It took out the power for several days. Though we weren’t in the middle of a covid hotspot back then. The deal is that Atlanta has a lot of big old trees, and all the power lines are above ground. So any time a significant storm rolls through, it knocks down a tree, the tree knocks down a power line, and the power goes out. Atlanta is pretty big, so multiply that by a few hundred trees and power lines (and a pandemic), and much of the city is out for awhile. Even a little storm sometimes knocks out the power for a few hours. That’s just one of the joys of where I live. I’m sorry about that, but since we’re supposed to be back online by Monday, I expect to have good updates for you next week. Thanks for reading and have a great weekend!

ProcessWire 3.0.168 contains 16 commits relative to 3.0.167 and is focused largely on minor issue fixes and improvements, with 8 reported issues fixed and 8 improvements. This week the larger focus was on the ProcessWire modules site. I finally got some serious work done with that this week, and am building good momentum. The front-end of the modules site is being moved into the main ProcessWire site, though the back-end will remain an independent ProcessWire installation. The main ProcessWire site uses multi-instance support to boot the modules site whenever it needs to pull or update data from it. Here's a simplified example: $site = new ProcessWire("/htdocs/modules.processwire.com/"); $items = $site->pages->find("template=module, sort=-created, limit=10"); echo $items->each("<li><a href='/module/{name}/'>{title}</a></li>"); The nice thing is that I’m finding performance to be excellent here, about the same as if I weren’t booting multiple ProcessWire installations. I’m sure there’s some overhead if measured, but it sure isn’t felt. One thing I did learn is that when it comes to pagination, if you want your separately booted site to be aware of the current site’s pagination, you need to tell it the page number. Otherwise the bit of code above will always return the first 10 modules, regardless of pagination number. It seems obvious now, but it took me a minute to realize why. So if pagination is being supported, you'd add this before the $site->pages->find(...) in the example above: $site->input->setPageNum($input->pageNum); For front-end work like this, it's also a good idea to tell your booted site if you want output formatting enabled, so that page titles and such come out entity encoded, for example: $site->pages->setOutputFormatting(true); ...or if you prefer the shorter alias: $site->pages->of(true); One big difference with the new modules directory is on the management side for module authors. This part is powered by LoginRegisterPro so that now you have an account to manage all of your modules within. Further, you have the option of maintaining your module author public profile and protecting your account with PW’s two-factor authentication. That's just for starters. All of this is in the early stages of development, but if the development schedule remains as planned, I’ll be following up with more info over the coming weeks, in addition to the regular core and module updates. Have a great weekend!

@alexmercenary Thanks, glad that you are liking this module (saw your post in the FormBuilder board too). Makes my day actually, thank you. This is a module that I thought was necessary to build before December, when SCA in Europe will apparently be a requirement. I wasn't able to find a way that the existing Stripe Inputfield could be updated to support 3D Secure, at least not in a way that would be reliable with the form workflow. Basically, with 3D Secure, the charge takes place at the time the user inputs the card and an independent popup verifies it. So if the card collection is part of another form (as the Stripe Inputfield is), and someone pays but never submits the form (or submits but never fixes validation errors), you end up with an orphan charge. Stripe's solution to this scenario is that you should issue a refund. I thought that was too much for people to keep track of (charges that are missing a form submission). So thought it was necessary to build this module and include it with FormBuilder, especially for any of those in Europe that might already be using the Stripe Inputfield.

@rick If you needed to back out of the payment screen, I haven't yet found a way to make the browser back button play nicely here. But Stripe provides a back button for this purpose though (see the ProcessWire logo on the left where it has a left arrow and says "Back" when you hover), and this one does enable you to effectively cancel the transaction and return to the form.

This week a second new module for processing Stripe payments has been added to FormBuilder. Unlike our other Stripe Inputfield for FormBuilder, this new one uses Stripe Checkout and supports 3D Secure (SCA) payments. We’ll take a closer look at it in this blog post, plus we’ve got a live demo of it here too— https://processwire.com/blog/posts/stripe-payment-processor-form-builder/