ryan

@Robin S The purpose I was focused on for the method is to see if the system has any page that matches the given criteria. An example of the use case appears in the Template class updates here. It verbally makes sense in code for what it's intended for. Usually I'd use a get or count for that, I didn't need any of the extras that $pages->get() or $pages->count() provide, so thought we could eliminate some overhead. Plus I can think several other other cases where the same was true, so the need has resurfaced enough times that it seemed like good method for PW to have. The method returns the ID just because it already has that info either way, and it seemed potentially more useful (and 0|1+ communicate the same thing as false|true). I had also seen where you'd mentioned a getID recently, and since this method already has the page ID, I thought this also seemed like a good opportunity to accommodate that need too. So far I haven't come across a good use case for getID() in my own projects, outside of checking for existence of something (which 'has' seems like a better term for). But it certainly makes sense alongside the existing findIDs() method, though that method is more about accommodating a scale that find() can't. But it sounds like you've had use cases for it which means others likely have too, and that's plenty good reason for me. I'll go ahead and add getID() it as an alias of has(). Depending on what need you are looking to solve, I imagine this will help people to find what they are looking for more easily.

This latest version of the core on the dev branch focuses on comments field updates, significant refactoring/improvements to ProcessWire’s core Template class and PagesLoader class (which is used by the $pages API variable), and we introduce a useful new $pages API method— https://processwire.com/blog/posts/pw-3.0.153/

@adrian There are two options when you initialize your CommentForm that let you define what you want to be populated, and whether or not you want it to be editable. These are the 'presets' (array) and 'presetsEditable' (bool) options. I'm initializing with the new CommentFormCustom class below, but the presets options also work with older versions of PW: $options = [ 'className' => 'CommentFormCustom' ]; if($user->isLoggedin()) { $options['presetsEditable'] = false; $options['presets'] = [ 'cite' => "$user->first_name $user->last_name", 'email' => $user->email, ]; } $form = $page->comments->getCommentForm($options); As for using a local image for avatar, or deciding whether or not to show cite and email, this is where the CommentFormCustom class comes in handy. It leaves you in full control of the markup, so you can render whatever avatar image in there you want (whether CommentFormCustom or CommentListCustom), and exclude fields in your markup when conditions dictate. In previous versions, if you didn't want to show specific fields in the form then you would hide them with CSS. @AndZyk Here's how you might do that with a hook. This looks for markdown style links, i.e. [text](url) and converts them to HTML links. The regex may need improvement still, but maybe it's a starting point. $wire->addHookBefore('CommentList::renderItem', function($event) { $comment = $event->arguments(0); /** @var Comment $comment */ $text = $comment->getFormatted('text'); $textOriginal = $text; // look for markdown style links: [text](url) if(strpos($text, '](') { $regex = '!\[(.+?)\]\((https?://[^)\s\r\n;"\']+)\)!i'; $link = '<a href="$2" rel="noopener noreferrer nofollow" target="_blank">$1</a>'; $text = preg_replace($regex, $link, $text); } // populate changed comment text if($text !== $textOriginal) { $comment->set('textFormatted', $text); } });

For logged in users, name and email are already filled in automatically and have been for awhile. There is also an option where you can make them non-editable, so that a logged in user can't modify them for each comment they make. But if you want to pull them from something other than "name" and "email" (which I think might be what you were looking for), then the new classes would definitely make it a lot easier to customize, and populate whatever you'd like in there. Likewise to render a custom avatar or hide fields, etc. The custom classes should open up a lot of new possibilities.

I hope you are having a good week and staying healthy with all that’s going on with this Coronavirus pandemic. Here in Atlanta, they have closed the schools indefinitely, so I’ve got my kids with me during the work days for awhile, which started this week. That might slow me down with work and development here, but hopefully not too much. It might also take me a little longer than usual to respond to messages temporarily, as I get used to the new schedule. It’s a nice change of pace to have the kids home during the day, even if it slows work a bit. Thankfully everyone here is healthy and we don’t yet know of anyone being sick. But then again, nobody is apparently able to get tested for it, so who knows. It sounds like the whole world is dealing with this, I hope you and your families stay healthy and safe. I’m still working on the same client project I’ve been working on here for months, and of course doing it all in ProcessWire. This week the client project needed to do a lot with user-submitted comments, and I had to make a lot of major upgrades to ProcessWire’s comments system in order to accommodate them. Most of these upgrades are related to API improvements and making the comments field able to better handle completely custom markup for both comments and the forms to submit them. (Commit details). A couple new classes were added, and existing classes went through major refactoring. While there have been some nice API additions as well, there aren’t any breaking changes to the existing API, so it should all keep working as it always has. I’m not going to bump the core version this week because, as major as the additions were, I don’t think they will matter much to most existing installations, so there's little reason to upgrade for most. So I’ll continue plugging away here and save the version update for when there are some more things to share as well, hopefully next week. Thanks for reading and have a great weekend.

@Zeka Thanks, I think I tracked down the issue (caching issue that occurs only when multiple date fields) and have pushed a fix on the dev branch. @szabesz From your /site/init.php you can set the location with $config->setLocation('classes', 'path/to/classes/'); for example $config->setLocation('classes', 'site/templates/classes/'); You can also use the method mentioned earlier by adding your own directories to the $classLoader. However, the more potential locations there are for something, the more overhead, so I would recommend sticking to the $config->setLocation() and keep all of your classes in one directory. This keeps everything fast and efficient. If that's the case, then you would have to add locations with the $classLoader and accept the overhead of doing so (though it's probably negligible so long as things don't grow too much). But I also think with that kind of structure, things look isolated when it comes to reusability, limiting their usefulness. That may be fine for your use case, but as far as classes go, one of the primary purposes is reuse and extending one another where appropriate, so you ideally want to keep them together. @bernhard ProcessWire preloads a few pages on every request, since they always get used. Preloaded pages are loaded as a group rather than individually, enabling it to boot faster. This happens before the init state for modules, so a module will not have the opportunity to specify a class for these preloaded pages, but a file in /site/classes/ will. See the $config->preloadPageIDs setting for a list of what those pages are. But essentially they are the homepage, admin root page, guest user+role, and superuser role. For your case, it sounds like only the homepage is a consideration here. I would suggest just asking PW to uncache the homepage at your module's init() state. This should force it to reload (when it's next requested) using your custom class. $homePage = $this->pages->cacher()->getCache(1); if($homePage) $this->pages->uncache($homePage); You can also use $config->setLocation() for this, i.e. $config->setLocation('fieldTemplates', 'site/templates/my-custom-directory/'); I think this is fine if you are just doing it once or twice, but if you find you are repeating yourself, typing out "/articles/fields" or similar in multiple places, then you always want to abstract away stuff like that into a single location so that if you ever need to change it, you change it in just one place. PHP functions are ideal for this. This will be simple to do, but when it comes to the directory and file names that you are using, I recommend using the exact same names that you do with your templates and fields, which will make it a simple matter to abstract away repetitive code or locations into functions. "All these directories" are 3 directories, 2 of which are for optional features that are disabled by default — the absolute minimum number of directories necessary to support these things. ProcessWire is focused in what is the most simple, efficient, familiar (as it relates to the admin), and maximizes reusability. It's not opinionated about it outside of those factors. For something like field-templates, a primary purpose of having them is so that you can reuse them across different templates (to avoid repeating yourself); otherwise they aren't that useful. For the structure that you appear to be using, it looks to me like your intention is to isolate them by template, so why have them at all? If the purpose is code/markup isolation (which is still worthwhile) then I think just using an include() or $files->render(); would be preferable, more efficient and flexible for your use case. So that's what I'd recommend there. The same goes for the new page classes—if you are isolating these things in the way you've suggested, it'll be confusing for classes to extend one another or be shared across multiple templates, and it'll take more overhead for PW to find them. If you don't intend to use them like that, maybe they can still be useful, but not nearly as much so. So at that point I would reconsider whether you want/need custom Page classes. Basically, you are using a highly opinionated structure for your site files, and that can be a good thing because you've decided where everything goes and have a plan/system for how it will grow in terms of your file structure. ProcessWire is built to support a lot of different types of websites and applications, and at any scale. But it's not opinionated about this stuff beyond the bare minimum, precisely so that you can be as opinionated as much as you want with your own projects. That's why you are able to build a more complex structure for your files that suits your need, and also why it's also just as suited for others that might prefer a simpler structure in their projects. There's also no need to feel obligated to use things like field templates or custom page classes just because they are there. The point of these features is to reduce redundancy and prevent you from having to repeat yourself. But you may have your own preferred ways of doing that—whether it's with functions, file/directory structure, or anything else, it's all perfectly fine in PW. A template file receiving a $page is the only assumption needed in ProcessWire and everything else is optional. So use these things when they help you do that, and avoid using them when they don't. The reason these features are disabled by default is because not everyone needs them. Personally, the only time I use field templates is for multi-value fields with lots of properties, like repeaters, where I need to reuse the same output/markup across multiple template files. Though custom Page classes I'm already using quite a bit and likely will in most cases.

This week we have some major improvements to our core date/time Inputfield, as well as a new ability to specify your own custom classes for Page objects. Read on for all the details and examples— https://processwire.com/blog/posts/pw-3.0.152/

@bernhard While that need hasn't often come up here, it sounds like it might be a common need elsewhere (?) per what you said, so I think it sounds worthwhile. Though I'm thinking maybe off the $files API variable as more obvious $files->diskPathToUrl() and $files->urlToDiskPath() type functions, but it would also be simple enough to have the $config methods respond to them too, so long as there's a at least one slash present in the value. Back to date/time API methods, were there any in particular that you thought were commonly needed but missing from PHP's built in set of tools? The two I found over time were the ability to produce relative date/time strings like "1 hour ago", and a common function that could accept different types of format strings (like those from date and strftime) so that's why PW's $datetime has those.

The focus of the InputfieldDatetime updates that this topic is about is purely about the Inputfield element and wouldn't affect anything about front-end API of date fields. Basically just the means by which users input dates into the system. When it comes to working with dates and times at the API side on the front-end, that's a different topic, but I guess I've always seen this as something that PHP does really well already, particularly the DateTime class can be very helpful. PW's always trying to work alongside PHP and with what PHP provides, as much as possible. Maybe some people encounter areas of working with dates and times that PHP doesn't cover well, but admittedly I haven't yet in projects here. Though there are a few specific cases that are covered in WireDateTime ($datetime API var) mostly for date/time functions that were needed by the core, but can also occasionally be useful on the front-end. But I see PHP's date/time classes and functions as being the tools a PW powered site would typically use when working with dates/times. Not only is there tons of documentation and examples out there, but these are tools that many PHP developers are already going to know before they know PW. I like it when people can take stuff they already know when keep using it in PW. I'm definitely open to expanding what PW's $datetime provides if there's a really common need that PHP doesn't cover well. Though I'm glad to see there are also quality modules like the ones mentioned above, as that seems like a great way to accommodate these needs too.

I’ve been working on some major upgrades to our InputfieldDatetime core module and they are just about ready, but because there’s a lot of new code involved, I just want to test things out more thoroughly before pushing to the dev branch. I’ll have more details on this for you next week, but here’s a summary of what’s new in our Date/Time Inputfield coming in 3.0.152: If you’ve used date inputs in ProcessWire before (whether in the admin, FormBuilder or elsewhere), you know that they consist of a text field with a configurable date format and optional jQuery UI powered date picker. On recent projects, I’ve wanted more options here. First off, I’ve wanted support for the HTML5 “date” and “time” input types, because on some browsers (mobile-based in particular) the browser implementation is quite good. On mobile clients (testing in Android Chrome at least), I find it’s actually pretty amazing, certainly preferable to the jQuery UI date picker. On desktop clients, I think the jQuery UI date picker might still be preferable, but the browser implementation is still quite good (though varies widely from browser to browser). So I’ve upgraded InputfieldDatetime to support both HTML5 “date” and “time” inputs as configurable options, as well as the ability to use them both together. Another thing I’ve often wished for when it comes to date inputs is the ability to have the Month, Day and Year isolated into separate selects. This is something that would work in any environment, and not require any particular feature support from the browser, nor would it require jQuery UI (like if you are wanting lightweight date fields in FormBuilder). This type of date selection seems to be the simplest, easiest and most portable way to go, and it’s something I’ve wanted for quite a long time. So support for this has also been added to InputfieldDatetime this week as well! Of course the order of month, day and year is completely configurable. Some other useful additions include support for HTML5 step values (date or time), minimum and maximum dates (and times), support for seconds in time selections, automatic localized month names in selects (via strftime), and the ability to ask for just month and year (when day is not applicable), or month and day (when year is not applicable). These updates—along with others—will appear in ProcessWire 3.0.152 on the dev branch within the next week.

This week we’ve got a couple of really useful API-side improvements to the core in 3.0.151, among other updates. First we’ll take a look at a new $config setting that lets you predefine image resize settings, enabling you to isolate them from code that outputs them, not unlike how you isolate CSS from HTML. Following that, we’ll introduce and show you how to use a handy addition to our static language translation functions. If you’ve ever come across the term “abandoned translation”, you’ll really like what this adds— https://processwire.com/blog/posts/pw-3.0.151/

@adrian @porl Since this post is in the ProFields board and you guys are discussing a Matrix Fieldtype (that's not related to ProFields), I'm a little worried people might get confused and think this had something to do with FieldtypeRepeaterMatrix (which I at first thought) but it appears you are discussing something different. And actually looks like maybe it would be useful for users outside of this board. Do you mind if I move the topic to one of the public boards, since it's not specific to ProFields, and may be useful others that might be using that Fieldtype?

Last Saturday we started getting hit with heavy traffic at the processwire.com support forums, and it soon became a full blown DDOS frenzy. This post describes all the fun, how we got it back under control, and what we learned along the way— https://processwire.com/blog/posts/driving-around-a-ddos-attack/

We’ve got several updates on the dev branch this week, but I want to finish one more of them before bumping the version to 3.0.150, so will likely do that next week. The biggest change this week is the addition of a new core class called FieldsTableTools. This will be used internally by the $fields API variable for manipulating field table schema in the database, and its methods are accessed from $fields->tableTools(); Though this is one you probably won't be using from the API unless developing Fieldtype modules, so if you just want to know what the benefits are, feel free to skip to the last two paragraphs. Initially these methods are primarily focused on managing unique indexes for fields, though will expand to manage other schema manipulations as well. An example of its utility is also included in this week’s commits—our email fields (FieldtypeEmail) now have the ability to enforce uniqueness at the DB level. If you edit an email field (Setup > Fields > email) and click on the Advanced tab, there’s now a checkbox there to enforce unique values, ensuring that a given email address cannot appear more than once (i.e. not appear on more than one page). The same ability will be added to text and integer fields (FieldtypeText and FieldtypeInteger) as well, but we’re starting with the email field because it’s needed for an update hopefully wrapping up next week: the optional ability to login to the admin with your email address. Having a unique index on a DB column is actually a pretty simple thing, but as it turns out, it takes a lot of code to support the ability in an existing installation. That’s because we have it as something you can toggle on and off (on that Advanced tab), and when you toggle ON a unique index, there can’t be any duplicate values in the existing data, or the index will fail to apply. So there’s a lot of supporting code in FieldsTableTools to do things like detect and warn about duplicate values, delete empty values before adding the index, identify when the index is present without querying the table, reporting error conditions in a manner that understandable and recoverable, as well as the actual schema manipulations that add or remove the index. I realize this sounds a bit technical (and that's partly why I'm not putting this in a more formal blog post), but I think most developers will at some point find it very useful in building sites and applications. Not only will it enable us to safely support login-by-email in the admin (coming next), but it’ll be useful in any situation where you need to prevent a value from repeating. Whether that is in preventing double bookings for a date, location, seat, etc., or preventing any kind of redundancy like post titles, author names, product titles, phone numbers, or codes (UPC, ISBN, ASINs, EIN, SSN, etc.), this feature can come in handy. And supporting it at the DB level is a lot more solid than supporting it at the code level. Right now it’s just supported in email fields, but all of the logic has been delegated to the newly added class so that we can easily support it in any other fields (with text and integer fields coming next). Following that, the $fields->tableTools(); will also be gaining methods for modifying other types of field schema. For instance, rather than just supporting the INT column type for integer fields, wouldn't it be nice to go to Setup > Fields > [some integer field] and select both unsigned and signed integers of different types: TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT, for any new or existing integer field? MySQL also offers a similar array of size variations for other types that would be useful in our text and textarea fields, among others. So you'll be continuing to see ProcessWire offer more options for existing FIeldtypes in future core versions, enabling you to more efficiently store and manage content in PW. But of course we'll do it in a way that keeps it simple, ensuring that you don't have to think about these things unless/until you want or need them.

I hope that you all have had a great week! I’ve got several commits to the core on the dev branch this week, with both improvements and fixes. I’m going to save the version bump to 3.0.150 till likely next week, when there should be more to write about. In addition to working on and supporting the core and modules here, I’ve been collaborating with Pete (forum admin) on a client project in ProcessWire. It’s keeping us both pretty busy, but I really value and enjoy the opportunity to develop sites in ProcessWire—it’s always a nice change of pace to develop something using ProcessWire, in addition to developing it. And it’s also a real pleasure to collaborate with Pete, he does amazing work. While working on this project, I’m still very much focused on core and module updates, but emphasizing smaller core updates like fixing issues and making incremental improvements to existing parts of the core (like in this week’s commits). Once we finish the first phase of this project (mid February), then I’ll be focusing on some larger updates and additions (and the related blog posts). Thanks have a great weekend!

ProcessWire 3.0.149 on the dev branch includes various improvements and a few minor fixes. Here are the most significant differences relative to 3.0.148 master: There have been several improvements to the $notices API variable as well as a significant refactoring of the code. Several new flags are now supported and can be specified by name rather than just by bit mask. While these updates won’t matter much for front-end site work, they are going to be helpful for the admin as well as potentially in other modules that work in the admin. Some of the updates are still a work in progress, so more will likely be added in the near future. (Commit) The Comments Fieldtype and related classes have received upgrades as well. (Commit) Several new API methods have been added for handling the parent/child relationships involved in threaded comments. The ProcessCommentsManager has also received major upgrades and it puts these new API functions to use by now allowing you to change which page a comment lives on (move a comment from one page to another), as well as change which comment another one replies to. Lots of refactoring was done in this module as well. (Commit) A minor but useful detail in AdminThemeUikit: if you click in the search box (top right corner) and don’t immediately start typing, it now suggests that you try typing “help” for options. Since this is an English word, the “help” term can also be translated in the AdminThemeUikit files (_search-form.php file). PW’s admin search engine can do quite a bit more than I think people realize at first, so I thought this was one way to help more people see what the options are with it, at least in AdminThemeUikit. (Commit) There were several other minor updates as well, but the above are the ones that I thought were the most interesting. Thanks for reading and have a great weekend!

@teppo (and @Robin S who had a similar question): There is coupling from LoginRegisterPro to InputfieldFrontendFile, but there isn't any from InputfieldFrontendFile to LoginRegisterPro. So I think InputfieldFrontendFile can be used for other cases outside of LoginRegisterPro. But for the moment, I've been focused just on the LoginRegisterPro use case, so haven't tried to use it for other things yet. The main thing is that for ajax file uploads to work, the system creating and rendering the form behind it (whether ProcessPageEdit, LoginRegisterPro, ProcessProfile, ListerPro, ProcessUser, etc.) needs to recognize an ajax request for a specific field and pass control to it, rather than doing the usual form rendering or processing. Afterwards it also needs to intercept the result and provide an ajax response (like JSON). LoginRegisterPro does this exactly the same way that ProcessPageEdit does (looking for specific HTTP headers), so unless I've forgotten anything, InputfieldFrontendFile would work in PW's admin page editors too. InputfieldFrontendFile also uses Pagefiles/Pageimages objects as its value attribute (just like InputfieldFile or InputfieldImage). That's because in ProcessWire, any file has to have an "owner" that can manage files, and of course Page objects (via a dedicated PagefilesManager instance) are what do that in PW, and Pagefiles/Pageimages objects are 1-to-1 with a Page. So that's where the real coupling is, to a Page, and to a Files field (or Images field), rather than to LoginRegisterPro. It's a good fit here because LoginRegisterPro works with User objects, which are just another type of Page. What InputfieldFrontendFile can't replace is something like the file upload field in FormBuilder. In that case, the form entries are the "owners", and they are entirely different from Pages and have their own protected file storage and delivery system. Also an entry isn't allowed to exist till a form is submitted, so ajax file uploads wouldn't work there, except potentially on a paginated form after the first pagination.

I hope you all have had a good start to 2020! Last week's release of the new master ProcessWire version 3.0.148 has gone smoothly, and if you haven't yet upgraded, it's a good time to do so. This week I've been working to finish up the new front-end file upload field called InputfieldFrontendFile, which is part of the LoginRegisterPro module package. I've released beta version 1 of that module in the LoginRegisterPro support board in the downloads topic, so it's ready for download now, as is a new version of LoginRegisterPro to accompany it. Today, I've written up a lot about this module, as well as posted a few screenshots here: Front-end file uploads with InputfieldFrontendFile module I've also got some ProcessWire core updates in progress this week for the dev branch, but this week has gone by so quickly I think I'll have to save those for next week. Thanks for reading and have a great weekend!

Today we have a new master version released, version 3.0.148! The last master version was 3.0.123, so there are 25 new versions worth of upgrades, fixes and optimizations in this new master version, relative to the previous. In this post we’ll take a closer look at what’s new, how to upgrade, and more— https://processwire.com/blog/posts/pw-3.0.148-master/

Merry Christmas/Happy Holidays and Happy New Year! This week we take a look at two new modules released this week: LoginRegisterPro and FileValidatorImage. Plus discussion of upcoming plans for new FileValidator modules and how they are useful in PW. Then a brief highlight of two great new ProcessWire-powered websites— https://processwire.com/blog/posts/new-modules-and-great-websites/

I hope that you have had a great week! I’ve been working hard on finishing up the LoginRegisterPro module this week and actually have it ready. But I’ve been told I have to get off the computer in 20 minutes, so so I think I’ll wait till Monday to release it. But I do have the new info page (which is kind of like last week's blog post) and new documentation page now online. The documentation page in particular is pretty comprehensive. In last week’s post there was a form to request more info once it’s released, so if you are interested in this module and haven’t filled out that form, please do. That’s how I’ll be sending out the introduction coupon code this time around, for those that want it. There have also been some core updates this week, but it was just a few commits, so not enough to warrant a version bump today. That’s actually a good thing, as no major new issues turning up means one step closer to merging onto the master branch. There will be a new master version before this year is done! Thank you for reading and I hope that you all have a great Christmas and/or holiday week next week!

@Robin S I agree and this is already in progress. It's not in the first version but is in the next one—here's the relevant section from the draft documentation:

This week we’ll take a look at LoginRegisterPro — a new module that provides an all-in-one, self contained module for providing new user registration, secure logins, profile editing, and more. It does this all in a manner that is reliable, efficient, comprehensive and secure. As we continue preparing the ProcessWire core dev branch to become our new master, I've been trying to stay hands-off on new feature additions there as much as possible (till the new master is out), and instead focusing on finishing up modules I've had in development. Last time I told you about the UserActivity module, and this time we’ll look at LoginRegisterPro, which is another module dealing with users; though significantly larger in scale/scope. LoginRegisterPro is a module I've been working on for more than a year, and finally this month have it ready to share. While I don't have it available for download today I do expect to have a beta release as soon as early next week. Read this week’s post for more details— https://processwire.com/blog/posts/login-register-pro/

This week we’ve got version 3.0.147 out on the dev branch. Relative to version 3.0.146, most of the new commits (about 13 of them) are focused on resolving reports submitted at GitHub. I love refactoring existing code and adding optimizations and improvements to the core (and then writing about them in the blog). But right now I’m trying really hard not to! I’d like to have a new master version out before the new year, so the focus is on making sure the core is as absolutely stable as possible. Any time I refactor or add something new (or even sometimes when fixing something or another), there’s a chance of introducing new bugs, and it needs thorough testing on the dev branch, so right now the goal is that everything is thoroughly tested and stable before merging to the master branch. As a result, I’m trying to keep my hands off the core as much as possible, other than fixing obvious things that aren’t likely to introduce new code that needs testing. Please consider 3.0.147 release candidate 1 (RC1) for the next master. Thanks for all of your help and testing. Hopefully by (or before) 3.0.150, we’ll be ready for a merge to master. One way I try and take a break from modifying too much in the core before a master version release is to focus on other modules instead. That’s why last week I wrote about the new UserActivity module, and why next week I’ll be posting all the details for a new LoginRegisterPro module — one that I’ve been working on-and-off for more than a year, but have recently given it a lot of attention in getting it ready for release. I’ll save most of the details on LoginRegisterPro for next week, except to say that it provides an all-in-one solution for front-end login, account registration, profile editing and more. You might be wondering how that’s different from the LoginRegister module I built and released awhile back. That LoginRegister module was built for a very specific purpose and client, largely as a proof-of-concept. But there was a lot more interest in it than I ever expected, and several people suggested that there was a need that would be better served by the quality and support of a Pro module. The result is LoginRegisterPro, which is a full reimagining of that from the ground up. It does everything LoginRegister didn’t, in addition to everything it did. It goes much further in terms of security, reliability and customizability, and I look forward to telling you more about it. I may have it ready to release as soon as next week, but just wanted to make sure all the documentation was complete (and there is quite a lot of it so far). A couple other things I’m looking forward to working on here in the next month or so are the 2020 core roadmap and [finally] the new modules.processwire.com site. Thanks for reading and have a great weekend!

@bernhard I had looked into that and having the same page open in 2-windows/tabs in the same session is not a case the module can reliably alert you to. Sessions are not unique per browser window/tab, and browsers don't provide any indication about what window/tab a request comes from. The only foolproof way to detect it is to provide some variable unique to the window/tab in the query string (like ?window_id=123), and then make sure that variable stays in all URLs clicked on or posted to from that point forward. It's not practical, and also breaks as soon as you open a target=_blank window or cmd-click force a request to open in a new window/tab on your own.