Jump to content

ryan

Administrators
  • Content Count

    13,044
  • Joined

  • Last visited

  • Days Won

    754

ryan last won the day on January 27

ryan had the most liked content!

Community Reputation

16,971 Excellent

About ryan

  • Rank
    Reiska

Contact Methods

  • Website URL
    http://processwire.com

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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!
  2. 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!
  3. @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.
  4. 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!
  5. 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/
  6. 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/
  7. 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!
  8. @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:
  9. 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/
  10. 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!
  11. @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.
  12. @Robin S Thanks for your feedback. I'd not taken the public API very far on this yet because I wasn't sure exactly what people would want, so it's useful for me to hear what you are looking for here. Beyond the API functions mentioned in the blog post, there actually is more, but it's lower-level, returning arrays of IDs and stuff rather than Users or Pages. But it has a good foundation to build upon, so I will plan to add some more methods like the one you've mentioned. If you are interested in doing it now, here's a function that would find what you are looking for with the UserActivity module: /** * Find active users * * @param int $seconds Find active within this many seconds (default=90) * @param string $roleName Name of role to find or omit for no role filter * @return PageArray * */ function findActiveUsers($seconds = 90, $roleName = '') { $activeUsers = new PageArray(); $role = $roleName ? wire('roles')->get($roleName) : null; $module = wire('modules')->get('UserActivity'); $options = [ 'seconds' => $seconds ]; foreach($module->findActivity($options) as $item) { $user = wire('users')->get($item['uid']); if(!$user->id || ($role && !$user->hasRole($role))) continue; $page = wire('pages')->get($item['pid']); // set some properties to $user in case you want them $user->set('activePath', $item['act']); $user->set('activeProcess', $item['process']); $user->set('activePage', $page); $activeUsers->add($user); } return $activeUsers; } // Example $editors = findActiveUsers(90, 'editor'); foreach($editors as $u) { echo "<p>User $user->name is at $user->activePath</p>"; } @bernhard I hadn't considered that particular situation, though I wouldn't recommend sharing logins like that. But technically it would be possible to support the situation with this module since those logins would have different session IDs. I'm happy to add it if it's something people are doing. But regardless of whether using this module or not, if you've got an installation where people are sharing logins I would recommend changing it so each user has their own login, otherwise it would be impossible to know who changed what, and one person changing the password could lock out the other users, etc.
  13. This week we’ll take a quick break from core updates and have a look at a new module called UserActivity, just added to the ProcessWire ProDevTools package— https://processwire.com/blog/posts/user-activity-module/
  14. ProcessWire 3.0.146 contains about 22 commits (relative to 3.0.145) and these commits are largely focused on resolving reports from the processwire-issues repository. However, there have also been several improvements and related additions. One of these additions was a foundational upgrade that adds support for Fieldtype modules to use a custom class for Field objects. This will open more possibilities for improved Field/Fieldtype-specific APIs. Several have asked for improvements in the APIs of Repeaters and other fields, so this is a step that begins the lay the tracks for moving in that direction. Traditionally the API calls for working with Fields and Fieldtypes have not been nearly as simple as those that work with Pages, so this will be an upgrade that narrows and eventually eliminates that gap, longer term. On the core side, I currently plan on using this to improve the API for Repeaters, Comments and Options fields, and perhaps others. Outside of the core, ProFields will eventually take advantage of custom Field objects as well. As usual, none of this will break any existing code, but it will add simplicity for those that work with Field/Fieldtype APIs in ProcessWire. As for other changes in 3.0.146, I think last week’s ProcessWire Weekly did a great job of covering them, so if you are interested be sure to check that out. Next week is partially a holiday week here in the US, so I’ll be on a little bit of a reduced schedule, but will still be working on the core. I’m also releasing a new module into the ProDevTools set of modules next week, so I’ll tell you more about that one in next week’s blog or forum post. Thanks for reading and have a great weekend!
  15. @Jonathan Lahijani Showing the namespace (matrix4) is something new to this version of PW, and it can do that because namespaces of fields within a fieldgroup are a core concept. So this is an extra that we didn't have before, but that I think is worthwhile here. However, Repeater Matrix is a module, and not even a core module, so things like RepeaterMatrix type names/labels are not known to the core. Part of ensuring the core remains flexible and maintainable means that it does not get involved in the implementation details of specific Fieldtypes. It just knows the Fieldtype interface, which is common to all Fieldtypes. So there's no reasonable way for us to have this particular core Process module identify labels of matrix types to show here. When it comes to RepeaterMatrix, the preferable way to edit these settings would be when editing the RepeaterMatrix field, rather than when editing a field within it outside of the matrix context. By doing that, the RepeaterMatrix module has control at that point, so implementation details are fully in scope and you wouldn't need to now what "matrix4" means or anything like that.
×
×
  • Create New...