Jump to content

ryan

Administrators
  • Content Count

    12,906
  • Joined

  • Last visited

  • Days Won

    736

ryan last won the day on December 3

ryan had the most liked content!

Community Reputation

16,673 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. @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.
  2. @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.
  3. 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/
  4. 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!
  5. @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.
  6. ProcessWire 3.0.144 and 3.0.145 add improved field template context override settings and include a new Inputfields API, along with numerous other issue fixes, optimizations and improvements to the core. This blog post is a continuation (and more in-depth version) of last week's post on 3.0.144 that was in the forum— https://processwire.com/blog/posts/pw-3.0.145/
  7. @teppo I didn't do anything from this side, so not sure why Packagist decided to update then. I'm guessing they just do it automatically at certain intervals, kind of like the modules directory. Good idea—I'll login to it and see if I can get it to update manually. Thanks.
  8. This latest version on the dev branch includes a few additions, optimizations and fixes. I'm only in the office for a brief time today, so I'll plan to cover these in more detail hopefully in next week's blog post (along with next week's updates), but here's a preview. There's a lot of improvements to the "Overrides" tab that you see when editing a field (Setup > Fields > Edit). These are the field settings in the contexts of different templates. In 3.0.144, you now get a list of all field settings that you want to allow to be customized per-template. In previous versions, you only saw this option if you were in $config->advanced mode. It's still a YMMV setting, so appropriate disclaimers have been added to the field. But since it's been there for more than a year and there have not been any reports of issues (that I'm aware of yet), I thought it didn't need to be limited to advanced mode anymore. The table that shows you what overrides are in place is now improved as well. You can now click any override setting to open a modal window to see/edit them as needed (previously they were just non-clickable text labels). This is the same window that you get when clicking a field in the Template editor. Though unlike the Template editor, it takes you directly to the setting you clicked on and highlights it. After saving or closing the window, it updates the table for any changes you made. In addition to this, the overrides table now shows a Diff rather than separate Old and New values for modified settings, which better clarifies what was changed. (That Diff comes by way of a new method added in the WireTextTools class). Version 3.0.144 also adds a new Inputfields Javascript API. More methods are likely to be added to it, but you can see what's available in this first version in the comments for this file (inputfields.js). The purpose of this Inputfields JS API is to make it simpler to manipulate Inputfields from the JS side, as well as solve some needs that I've had in the core and modules; which presumably some other developers may have had as well. It takes a lot of stuff that previously required knowing which classes and attributes to manipulate and simplifies them to simpler methods calls from the new Inputfields JS API variable. It also abstracts away some admin-theme specific stuff so that you can use the same API to perform certain manipulations regardless of admin theme. I'm still working out some details and likely have some issues to fix and additional functions to add, so I'll save examples and more description for next week. Though the updates mentioned for the "Overrides" tab do use a little bit from this API. This version also contains a couple of fixes per GitHub issue reports, and that'll continue into next week's version as well. More updates next week. Until then, thanks for reading and have a great weekend!
  9. This version on the dev branch contains 26 commits (relative to 3.0.142) and is focused primarily in resolving reported issues, and we managed to cover 18 of them in this version. Thanks for the reports and help in our GitHub issues repo. This version represents about 2 weeks of work, and ProcessWire Weekly #284 has good coverage of those that occurred last week. More details about this week's updates can be also be found in the dev branch commit log. There are also some other minor additions and improvements in 3.0.143 as well. My favorite are the improvements to our logs system. It now collapses identical log entries that occur near each other. That means a single recurring log entry (like an error message) won't repeat indefinitely in the log and take up a lot of space. Now it just adds a counter to one log entry and updates the timestamp, rather than duplicating the entire log entry... Much more efficient. When you view a log in Setup > Logs, it identifies these collapsed log entries for you. In addition, the output in the "errors" and "exceptions" logs now have improved readability, isolating error messages and filenames from stack traces. Lastly, the ajax navigation in Setup > Logs now shows logs in newest-to-oldest (modification date) rather than alphabetical, which I find a lot more useful. The log at the top of the list is always the one most recently updated. For core updates in coming weeks, I'm primarily focused on preparing the current dev branch to merge to the master branch, as it's been awhile since the last merge and the master branch is itching for a new version. Most of you reading this already run on the dev branch, but there are many out there that also stick to the master branch, and with all the new stuff on the dev branch, I'd like to get our master up-to-date with this as well. Thanks for reading, have a great weekend!
  10. @Klenkes @eelkenet @Jens Martsch - dotnetic Thanks, I was able to duplicate and fix the issues mentioned above. Please let me know if you observe any other issues.
  11. @Jens Martsch - dotnetic Heh, no problem, that happens here regularly too. :) Let's get back to your first video—I'm trying to figure out how to duplicate this one. I think you could be on to something here because many Fieldtype methods require a Page object, and there is no Page object associated with each image. As a result, we use a fake Page without an ID, and I'm guessing this is the source of the error you are seeing, but I can't figure out how to duplicate the scenario here. Here's what I've done to attempt to duplicate: I've started with a new instance of the "Regular" site profile, added a field-images template, and added fields to it. Logged in as superuser, I edited the /about/ page, uploaded an image to the image fields, and populated all my custom fields with text, and saved. I created a new role named "editor" and checked the box so that it has page-edit permission to "home" (which inherits through the tree). The user doesn't have any other permissions. I created a new user with this role, logged in with it, and edited the /about/ page and clicked to open the images field. I can see all the field text, and modify and save it as well, and changes are retained. So I'm not sure what to try next in terms of duplicating the issue, so I'll ask a few questions; Do you have any field-level access control involved here on your images field, or on any of the fields defined on your field-images template? Did you enable access control on your field-images template? (it should be disabled) Do you have any modules installed that add access control hooks or modify the way access control works? Do you have any optional core permissions installed? (like page-edit-created, page-publish, page-edit-images)? Any other factors you can think of? Thanks!
  12. @Jens Martsch - dotnetic Thanks for the videos. Let's focus on your 2nd example first, because I see things in first one that I don't recognize, and it looks like there is access control at the field level too, so lots of factors—let's come back to that one. In your 2nd example (blank installation) you haven't yet uploaded an image into the field, so it doesn't look to me like it should be showing any fields yet. But you are circling something with your mouse, so I'm not sure I understand. But you shouldn't see any of your custom fields if you haven't yet uploaded any files/images yet, so can you try that example again or let me know if I misunderstood? (no need to record it to a video, just wanted to make sure I wasn't missing something).
  13. ProcessWire 3.0.142 has a lot of updates but the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look and also outline all of the new features in the just-released FormBuilder v40— https://processwire.com/blog/posts/pw-3.0.142/
  14. Last week I worked primarily on GitHub issues, and did some of that this week as well. Likely I'll be doing a lot of this in October. Thank you for all of your reports. While there's already a lot of commits on the dev branch, I'm going to wait till next week to bump the version, as I've got some stuff in progress that I want to get committed first (more on that below). Next week I'm releasing version 40 of FormBuilder that supports paginated forms, as well as forms within forms (not to mention some other minor additions). Basically, all the stuff that was covered in this video from a few weeks ago, plus a little more. I actually think it's ready right now, but as is often the case, I started writing instructions for using the new features today and thought of a couple minor tweaks that would be helpful along the way. So I'm going to apply those early next week, finish the instructions, test it all out again, and then release it... likely mid-week next week. For the ProcessWire core, one feature people have been asking for for quite awhile is the ability to specify custom fields with file and image fields. I've been working on that here quite a bit this week, and have the initial test cases working quite nicely! Unlike the Description and Tags fields that come as built-in options with file and image fields, the new option instead uses a subset of ProcessWire's Fieldtype and Inputfield modules to support this (note: it does not use pages like repeaters do). This gives you more flexibility in defining what you want and how you want it to look. Though there are some limitations of what kinds of fields you can use here, but I think you will like what it offers and how it works. For those that just need a description and/or tags, then of course those features will remain as they are. But for those that need something more for file/image fields, you are going to have a whole lot of new options in 3.0.142. Unless I run into any roadblocks in finishing development of this part, I'll have it ready by this time next week along with a blog post that outlines it in more detail.
  15. Actually I'm still working on minor details, but I'll have it posted by 5pm EST.
×
×
  • Create New...