ryan

This week I'm happy to report that the InputfieldTinyMCE module is now released. It is currently released in the modules directory and GitHub but the plan is it will be merged into the core, likely before the end of the year. No need to wait till then though, as you can start using it today. Please consider the module in beta for the moment, though the TinyMCE library itself is in a stable state. A lot of the work that went into developing this module went into the configuration aspect. Here are a few a more details that weren't covered in last week's post: After installing the module, on the module configuration screen, you can decide whether several settings should be configurable for each field, or if you want to just configure them with the module (affecting all fields): One of things that I thought was important was to make it a lot simpler to add custom classes/styles to the editor. I always found this kind of a pain in CKEditor. So in TinyMCE, I made it so that you can just define these custom styles with the field settings using just simple CSS definitions. InputfieldTinyMCE takes care of converting to a format that TinyMCE can understand (for its menus), as well as the styles to show in the editor. For instance, I wanted to add some common Uikit text classes to a custom "Uikit" group in the Styles dropdown: And here's the result in the editor: The markup produced has the correct Uikit classes in the markup so that on the front-end of my site the output is Uikit ready. You can add 3rd party or your own custom plugins from the module settings: And then you can enable them for any field in the field editor: These are just a few interesting tidbits, but there's a lot more. Also, if you didn't see last week's blog post, that covers a lot more too. Either way, I'd encourage you to download InputfieldTinyMCE, give it a try and please let me know how it works for you. If you come across any bugs, please open an issue report. Thanks for reading and have a great weekend!

@Violet Thanks for the great feedback, I appreciate it! @markus_blue_tomato Yes, I actually find TinyMCE 6 quite a bit easier to extend than CKEditor 4. For instance, here's how you could add a "hello" button to the toolbar: InputfieldTinyMCE.onSetup(function(editor) { editor.ui.registry.addButton('hello', { icon: 'user', text: 'Hello', onAction: function() { editor.insertContent('Hello World!') } }); }); Then you would edit your toolbar in the field config and type "hello" to it to any toolbars you wanted. Then every time you click the "hello" button on the toolbar, it would insert the text "Hello World" at the cursor.

@bernhard I'm not sure I know why that issue occurs in CKEditor, but I don't see any reason why the issue should exist in TinyMCE. I'm sure there's also a way around it in CKEditor, though I don't understand the issue well enough yet to suggest something. Most (maybe all) of the TinyMCE settings should lend themselves very well to context. The way I've got it setup currently is that it maintains all the settings (that differ from the defaults), namespaced by field name in ProcessWire.config.InputfieldTinyMCE.settings. Then any field-template context settings (that differ from the field settings) are in data attributes on the Inputfield. Field settings override defaults, then template-context settings override those. InputfieldCKEditor settings work in a similar way, but with less efficiency (all settings bundled rather than just those that override defaults), and it doesn't have the option for the data attribute override settings. Hopefully TinyMCE will work for the context you mention but let me know if not, I'm sure we'll be able to figure it out.

Lots of good guesses! Here's all the details: https://processwire.com/blog/posts/new-rte-for-pw/

This week we take a look at a new rich text editor for ProcessWire, why we chose it, some highlights, screenshots, and why we think you’ll like it— https://processwire.com/blog/posts/new-rte-for-pw/

@Pixrael I have in the past, though they've never had a compatible license. They make great stuff. But for things like this I tend to stick to things that have a GitHub repo and compatible license. I've always seen Redactor as something that would be good for a 3rd party module rather than a core inclusion.

With 2023 fast approaching, and CKEditor 4 having an EOL in 2023, I'm starting to feel a little pressure to get a plan in place. But is the replacement (CKEditor 5) the best path forward? https://processwire.com/blog/posts/reconsidering-the-ckeditor-5-upgrade/

@Pete Oops, looks like I neglected to push the final "bump version" commit. Just pushed it and the version number should update within a day. Thanks.

@bernhard Not really. This sort of thing would be simple on some fields but very difficult on others. For instance, text fields, numbers, etc... very simple. But for any field that stores data beyond the field_* table (Repeaters, Files/images, PageTable, etc.) it would be difficult to achieve and to maintain. The only way to do it reliably across all Fieldtypes would be is if each Fieldtype implemented the ability on its own (through some base Fieldtype provided interface, which we may add at some point). That's because individual Fieldtype modules are the the only authority on how and where their data is stored. Granted, the vast majority of Fieldtypes just store data in their field_* table, keeping it simple, but it's those more complex ones (repeaters, files, etc.) that are the primary obstacle to some undo or version feature that works the same across all fields. It's one of the reasons I gave up on developing the Snapshots module, which I spent weeks on before realizing such features are not sustainable for complex Fieldtypes until it becomes part of the Fieldtype interface.

This week we have ProcessWire 3.0.206 on the dev branch and a new version of the ProDevTools UserActivity module, which we'll take a closer look at in this post— https://processwire.com/blog/posts/user-activity-v6/

@Boost Typically your _main.php would contain just the regions that would be common among all templates. Usually this is desirable because most websites have a common theme behind them. But if your template files are so different that nothing in <body>...</body> is the same, then maybe your _main.php is just this: <html lang="en"> <head id="html-head"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title><?=$page->title?></title> <!-- plus any other common head output --> </head> <body id="html-body"> <!-- any common body stuff, or even blank if none --> </body> </html> Then template file "basic-page.php" might look like this: <body id="html-body"> <div class="some-container-class"> <h1><?=$page->title?></h1> <?=$page->body?> </div> </body> and template file "gallery.php" might look like this: <body id="html-body"> <h1>Photo gallery: <?=$page->title?></h1> <ul class="gallery"> <?php foreach($page->images as $image): ?> <li><img src="<?=$image->url?>" alt="<?=$image->description?>" /> <?php endforeach; ?> </ul> </body> <!-- example of adding some JS and CSS files to the document head --> <script src="<?=$urls->templates?>scripts/gallery.js" pw-append="html-head"></script> <link rel="stylesheet" href="<?=$urls()->templates?>styles/gallery.css" pw-append="html-head"> <!-- or this does the same as the above with different syntax --> <head id="html-head" pw-append> <script src="<?=$urls->templates?>scripts/gallery.js"></script> <link rel="stylesheet" href="<?=$urls()->templates?>styles/gallery.css"> </head> I personally wouldn't create separate main template files like that and instead would just use a simple enough _main.php to accommodate anything I want to do with it. You certainly could use direct output too, and I'm guessing maybe half of PW sites do this. But consider the case above where we needed to add script/link tags to the document <head> from our template file. This is where direct output becomes more limiting, unless you want to start adding template-specific logic in other include files, like whichever one outputs your <head>. Either that, or you end up needing your template file(s) to each output an entire HTML document. So markup regions are really convenient in part because you can output directly (like direct output), but can also manipulate markup that's already been output, or will be output later.

@M1ss1on When CSRF tokens are involved (like on pages with forms) you don't want to have output cached. For your AJAX request, either make it a POST request, or make it a GET request with a query string — either should bypass ProCache. Though since it's a CSRF token here, depending on your case, you'll need the original non-AJAX request that renders the page to also be uncached. So in that case I would turn off ProCache for the template used by the page in question. In the ProCache settings you can select what page templates it should cache.

@maddmac Yes. Though currently they are a FieldtypeOptions field, but can be changed/added to just as easily. Still, maybe I should convert from Options to Page fields for stuff like this. @MarkE A module is something you might integrate into an existing project. I see this instead as a separate app and not something that you integrate into an existing website or project. Though extending it into a new project, using it as a starting point, building on top of it, etc., is definitely the purpose of any site profile. Though this particular site profile is one that you might use as-is, or extend it, depending on your needs. @fuzenco I currently have 2 versions of the default invoice template. One is using Uikit 3 markup. The second is using email-friendly plain HTML and a tool that converts class attributes to inline styles at render time for broad email compatibility. When you send an email, it uses the invoice email template and when you view or send the client the URL it uses the Uikit template. Either can be printed to PDF in your browser, but generating PDFs isn't built-in to the site profile (at least not yet). Yeah these are already features of Stripe. Handling payments isn't really my expertise and other than that I know how to work with Stripe reasonably well, so that's the direction I'd take for that. Though all my clients pay by check or bank transfer so not sure I'll be using the feature myself. @dragan I don't know anything about VAT, so am not sure what that entails. Though I understand it's something tax related and think it would be fairly simple to integrate tax related things. I'll have to research it further, though that may be something we leave for people to add on their own according to their own needs. @teppo That's an interesting idea! I'll have to look at what Antti did with that. Though I do wonder to what extent people need payment processing with invoices. It hasn't been part of the invoice services I've used to date. With an online store it's very much connected, but with an invoice it kind of depends how you bill or whether you use credit cards at all. I don't use credit cards for client billing because it's not worth the fees. If I charge $5k for a web development project, then Stripe's cut would be $200, which is significant. I'd rather just have the client send me a check or bank transfer, no fees. But for smaller stuff, I do think it would be nice to have the credit card option built-in.

This week I've been working on something a little different: developing a new site profile in ProcessWire. Actually, I should probably call it an application profile rather than a site profile, as it's not a website profile. Instead it's a profile for an invoicing application in ProcessWire. Though you would install and run it on a web server, but it would be an independent application rather than part of a website... perhaps something you run in a subdirectory, subdomain, or even localhost. This is something I've been wanting to build for awhile—ever since the invoice service I use raised their rates beyond my budget. So I thought I'd build a replacement that I could use, as well as share for others that might have a similar need. I think it might also be a pretty decent PW profile example in general, too. I'd originally considered building it as a Process module but decided not to for a few reasons. Though the biggest one is that a site profile enables the greatest potential for customization and expansion according to each person's needs. Since you can expand upon it by adding your own fields and templates, or editing existing ones, most can really tailor it to their own needs a lot more easily than they could if it were a Process module. Likewise, since the actual invoices (and invoice emails) are rendered from front-end pages, you can customize the look and feel of them to match your brand very easily. (This is something I always wished I could do with the invoice service I've been using previously) This invoice profile requires nothing other than the ProcessWire core. It has no 3rd party or Pro module dependencies. I've got it largely functional at this stage, though will be putting a couple more weeks work into it before releasing it. I'd like to build in the option for clients to pay an invoice with a credit card (via Stripe) for instance. Below are a few screenshots of the work in progress. First is the page-list which shows the current invoices in the system and their status. (click image to view larger) As you can see, there are also pages for Clients and Settings. The client pages contain all the information about each client that invoices can be created for. The Settings page is where you can edit your own company information, logo and billing preferences. Next is the invoice editor. Here we have a repeater for each line item in the invoice. We also have a repeater for payments. All of the totals add up automatically as you type (Javascript added via hooks). They are also calculated automatically at the server side, so that everything stays consistent whether working with the API or in the page editor. (click image to view larger) At the bottom of the invoice editor you'll see a collapsed input for "Invoice action". This is where you can select actions to apply to the invoice. The two we currently have are "Email invoice to client" and "Email invoice to another address". Next up is what we see when viewing the invoice on the front-end. This is just the output of a template file but it is optimized for printing, saving to PDF and sending through email. I've kept it intentionally simple but of course the logo would be replaced with your own and all markup/styles are fully under your control. (click image to view larger) What I plan to add next are payment options, enabling a client to pay by credit card right from the invoice URL or email. What do you think, is this type of PW profile useful to you or someone you know? I've initially built it towards my own client invoicing needs, but I'm curious what other features you would like it to have? Or do you think it's better to keep it simple so that people can more easily take it in different directions? Thanks for your feedback. Have a great weekend!

This week my kids are out of school on fall break, meaning I've also been off work this week (in part at least), so it's been a quiet week for development. Nevertheless, an issue report has been resolved (thanks to matjazpotocnik), two feature requests have been added (here and here), and a bunch of minor core code improvements have been added. While there's not much more to report this week, more is on the way next week. Have a great weekend!

This week we have ProcessWire 3.0.205 on the dev branch. Relative to 3.0.204, this includes 23 new commits including several refactored classes, issue resolutions, several pull requests and various new features. While there's no single major new feature to write a blog post around, there's still a lot here so for full details see the dev branch commit log. This week there's also a new module released in the ListerPro board called PageActionCrawl. This is a ListerPro PageAction module that crawls all pages sent to it. You can use this to crawl your entire site, some portion of pages within it, or even crawl external URLs referenced in URL fields. This is useful for any number of things such as priming caches, finding errors, quality assurance, doing security testing and more. Features include: Supports crawling with GET, POST or HEAD requests. Supports optional query strings and/or URL segments. Reports the HTTP response code and render time for each URL. Highlights error URLs (http code >= 400) in red. Optionally supports crawling of multiple URL variations per page. Supports inclusion of custom POST variables in POST requests. Supports page URLs or URLs stored in FieldtypeURL fields. Supports success and error hooks for custom behaviors on crawled URLs. Speaking of ListerPro actions, I've moved all of the 9 ListerPro action modules into their own new subforum of the ListerPro support board, so if you subscribe to ListerPro be sure to look for the new ListerPro Page Actions board in there. That's also where this new PageActionCrawl module is posted. Thanks for reading and have a great weekend!

@benbyf In your PW admin, when in debug mode, there is a "Debug" link at the bottom right of the screen. If you click that it opens a panel and one of the options in the panel is "Hooks". Click Hooks to open and it'll show you all the hooks that are in use and in what order. The "priority" column indicates order... The smaller the priority number, the earlier it executes, so a priority of 99 executes before 100. But in the Hooks list on the debug screen you'll see priority numbers like 100.0, 100.1, 100.2, etc. This indicates that the hooks were added with the same priority (100, which is the default) and the number after the decimal indicates the order they were added in. They execute in the same order, so 100.0 executes before 100.1, 100.1 executes before 100.2, etc. If you are looking for a way to get this info for some other purpose you can find the code that generates this debug info in /wire/templates-admin/debug.inc, but basically it amounts to a displaying the return values from wire()->getHooks('*');

This last week my wife and daughter took a trip to NYC and it was my daughter's first time there. I was browsing around online looking at things they could do and so I visited the Guggenheim museum website to look into that option... I've always been a fan of the building, a Frank Lloyd Wright masterpiece. In addition to New York, I learned from the website that Guggenheim also has museums in Abu Dhabi, Bilbao and Venice, so I clicked through to view them as well. I really liked the Venice Guggenheim website, which had a much nicer website than the other locations. It was such a nice site that I was curious what they were running, so I viewed the source and... not WordPress (like the others), but ProcessWire. What a nice surprise. Then I was curious about who made such a nice site and there was a credits link in the bottom right corner that says the site was made by basili.co, nice work! It's always fun to come across a ProcessWire powered website randomly like that, and I thought you all would enjoy this one too. This week there are fairly minor updates on the core dev branch. Though the updates include one I've been meaning to do for a long time: improve the API for processing Inputfield forms. Previously there's been no way to check if a form is submitted, short of checking an $input variable yourself. Today I committed an update that adds a $form->isSubmitted() method that solves that, and more. It can identify which form was submitted, which submit button was used, and it also performs additional checks to make sure it's a valid submission before deciding that it's a form worth processing. It improves reliability, accuracy and security. Next week I'll be updating several of the admin forms to use it, among other updates. A few other useful helper methods were added to the Inputfield forms API as well. I realize that these updates may only be of interest to module authors, but I like keep you up-to-date with the week's updates either way. Thanks for reading and have a great weekend!

@adrian @bernhard Thanks, I think I've fixed these issues and they are now on the dev branch. @kongondo I wasn't able to duplicate the language issues you mentioned, but am guessing they must be related to the things Bernhard and Adrian mentioned, but please let me know if you continue to see them.

This week on the core dev branch we’ve got some major refactoring in the Page class. Unless I broke anything in the process, it should be more efficient and use less memory than before. But a few of useful new methods for getting page fields were added in the process. (A couple of these were also to answer feature request #453). Dot syntax You may have heard of dot-syntax for getting page fields, such as $pages->get('parent.title') where “parent” can be any field and “title” can be any field that has subfields. This is something that ProcessWire has supported for a long time, but it doesn’t get used much because it was disabled when output formatting was on. So it wasn’t something you could really count on always being there. Now you can — it is enabled all of the time. But it’s also been rewritten to be more powerful. When using dot syntax with a multi-value field (i.e. any kind of WireArray value) you can also specify field_name.first to get just the first value or field_name.last to get just the last value. i.e. $page->get('categories.first'); will take a value that was going to be a PageArray (‘categories’) and return just the first Page from it. Bracket syntax With bracket syntax you can call $page->get('field_name[]') with the (‘[]’ brackets at the end) and it will always return the appropriate array value for the type, whether a PageArray, WireArray, Pagefiles/Pageimages, or regular PHP array, etc. This is useful in cases where you know you’ll want a value you can foreach/iterate. Maybe you’ve got a Page field that set set to contain just 1 page, or maybe you’ve got a File/Image field set to contain just 1 file. But you want some way to treat all of your page or file/image fields the same, just append “[]” to the field name in your $page->get() call and you’ll always get an array-type value, regardless of the field settings. This bracket syntax can also be used for getting 1 value by index number. Let’s say you’ve got a page field named “categories” that contains multiple pages. If you want to get just the first, you can just call $page->get('categories[0]'); If you want to get the second, you can do $page->get('categories[1]'); This works whether the field is set to contain just one value or many values. Using the first index [0] is a good way to ensure you get 1 item when you may not know whether the field is a single-value or multi-value field. Another thing you can do with the bracket syntax is put a selector in it to filter a multi-value field right in the $page->get() call. Let’s say you want all categories that have the word “design” in the name. You can call $page->get('categories[title%=design]'); If you want just the first, then $page->get('categories[title%=design][0]'); What’s useful about using selectors in brackets is that this does a filter at the database-level rather than loading the entire ‘categories’ field in memory and then filtering it. Meaning it's a lot more memory efficient than doing a $page->get('categories')->find('title%=design'); In this way, it’s similar to the already-supported option to use a field name as a method call, for instance ProcessWire supports $page->field_name('selector'); to achieve a similar result. Dot syntax and bracket syntax together You can use all of these features together. Here’s a few examples from the updated $page->get() phpdocs: // get value guaranteed to be iterable (array, WireArray, or derived) $images = $page->get('image[]'); // Pageimages $categories = $page->get('category[]'); // PageArray // get item by position/index, returns 1 item whether field is single or multi value $file = $page->get('files[0]'); // get first file (or null if files is empty) $file = $page->get('files.first'); // same as above $file = $page->get('files.last'); // get last file $file = $page->get('files[1]'); // get 2nd file (or null if there isn't one) // get titles from Page reference field categories in an array $titles = $page->get('categories.title'); // array of titles $title = $page->get('categories[0].title'); // string of just first title // you can also use a selector in [brackets] for a filtered value // example: get categories with titles matching text 'design' $categories = $page->get('categories[title%=design]'); // PageArray $category = $page->get('categories[title%=design][0]'); // Page or null $titles = $page->get('categories[title%=design].title'); // array of strings $title = $page->get('categories[title%=design].title[0]'); // string or null // remember curly brackets? You can use dot syntax in there too… echo $page->get('Page “{title}” has {categories.count} total categories'); I’m not going to bump the version number this week because a lot of code was updated or added and I’d like to test it for another week before bumping the version number (since it triggers the upgrades module to notify people). But if you decide to upgrade now, please let me know how it works for you or if you run into any issues. Thanks for reading, have a great weekend!

@adrian UserActivity doesn't use ajax on the front-end, so there's nothing to ping to continuously check and verify the activity is still current. Though you still could use it in a non-ajax context, or you could add your own ajax to do it. The reason UserActivity doesn't use ajax on the front-end is just a matter of security... avoiding a place for nuisance garbage to be submitted. It hides its ajax endpoint behind the admin and requires a logged-in user for that endpoint to save an activity. You can use UserActivity's API to save activities on your own though, here's how: $ua = $modules->get('UserActivity'); $activity = $page->url; // i.e. /members/profile-edit/ $ua->saveUserActivity($user, $activity); Then when you want to check if that activity is active, perhaps with a hook into something in ProcessUser or ProcessPageEdit, or even somewhere on your front-end... $ua = $modules->get('UserActivity'); $u = $users->get('adrian'); // user object, name or id $items = $ua->findUserActivity($u, [ 'equals' => '/members/profile-edit/', 'seconds' => 60, // in last n seconds (default=60) ]); if(count($items)) { $this->warning("User may be editing their profile right now"); }

This week we’ve got a new core version on the dev branch (v3.0.204) and a new version of FormBuilder (v53) posted in the FormBuilder board. Relative to ProcessWire 3.0.203 version 3.0.204 has 23 commits containing a mixture of feature improvements and issue resolutions. While there aren't major feature additions here there are a lot of worthwhile improvements and fixes, and I'd recommend the upgrade if using the dev branch. See the dev branch commit log for more details. The new FormBuilder version includes various improvements but the biggest is a new version of the included InputfieldFormBuilderFile module that supports file/image uploads in forms. It has been improved with a preview option (for images), the ability to collect a description for each file, improved multi-file inputs, and more. The new options appear on the “Details” tab when editing a file field in FormBuilder. This new version (v53) is available for download now in the FormBuilder board. If you upgrade an existing installation with file fields, I’d suggest testing out those forms after upgrade, and also review the new options to see if they make sense for your form. Thanks for reading and have a great weekend!

@wbmnfktr Consider the benefits of using a spreadsheet. The benefits of using a Table field are similar, and the data is all accessible, editable and searchable in PW. Table also has many of the benefits of repeaters, but without the overhead. It's much faster in terms of performance and much more efficient in terms of storage (1-1 mapping of input column to table column and input row to table row). On the admin/input side, it's more like using a spreadsheet than a typical Inputfield, which can sometimes be preferable for editors. Table is also much more scalable than other repeatable types (like repeaters). You can have just a few rows or tens of thousands of them, something that you couldn't do with repeaters. Table can also paginate its rows, both input side and front-end. Personally, I use Table on almost every site I develop. One obvious use case I also come across regularly is rate tables like here (click on pricing tab, this is developed with Table). While table is much more scalable than Repeater, it is not as flexible or powerful as Repeater. But when your needs crossover with what Table does, it is certainly preferable.

I hope you are having a great week. Today I've released new versions of two ProcessWire ProFields modules: Table and Combo. In addition to various minor improvements and fixes, the biggest update in both is the addition of file and image fields. Since this is a fairly major feature addition for both modules, please consider these versions in a beta test stage for the moment. Both are available for download in the ProFields board now. Table v23 In ProFields Table both "file" and "image" column types were added. These are fairly basic file upload fields, but a major improvement over not having them at all. It can hold one file per column per row in the table. You can have as many file columns as you need per row. The front-end value of your file or image columns is one you are likely used to using already: Pagefile or Pageimage objects, just like they would be in a regular single-file or image field. This means your file/image values in your Table rows can benefit from many of the built-in methods you already use, such as the ability to present resized images, WebP variations, etc. When you configure a file column you can specify what extensions you want to allow and the maximum number of bytes you are willing for it to accept in an upload. When configuring an image column, you also gain settings to specify the thumbnail image preview size in both regular and HiDPI resolution. Combo v9 The update for Combo fields was similar to the Table field except that file and image fields go quite a bit further in Combo than they could in Table. Specifically, you get almost the full set of InputfieldFile/InputfieldImage configuration settings and features, including the ability to support both single and multi-file uploads, image actions, variations, focus control, description input, tags input and more. The only things missing relative to a regular File/Image field are the manual Crop action (Image field) and the ability to manage separate custom fields for each file or image. The front-end value for your Combo file fields is identical to what it would be on a regular ProcessWire File or Image field. Specifically a Pagefiles or Pageimages (plural) object if supporting multiple files, or a Pagefile or Pageimage (singular) object if supporting 1 file. To say it another way, you can use this exactly as you use other dedicated file/image fields in ProcessWire. Not yet included is the ability to query the properties of a file/image field from selectors, like when using $pages->find(). I'm still working on that part, but since I know most probably don't need that I decided to get this version out first and then continue working on that part. Core updates The core updates this week were mostly minor, even if there were a lot of them. One of the ways that I stay up-to-speed on all the core code is to regularly read through all of it and make small adjustments along the way... anything that makes the code easier to read, or easier for PhpStorm to inspect it. You've seen these kinds of updates pretty much every week for years, but I hadn't thought to mention it before. This week there were more of these kinds of updates than usual so I just wanted to mention that what it's for. What sometimes looks like micro-optimization or minor code changes is usually just me staying fresh and up-to-date with the core. ? That's all for this week. I hope you have a great weekend!

I hope that you all are having a great week! This week I've been working on some updates to the User Activity module and have released version 5 in the ProDevTools board. This version focuses on adding several new requested features, including the following: New options to also detect when you (yourself) are editing the same page in 2+ windows and when you have modified a page in a different window. These are the “collide-self” and “modify-self” options in module config. The module now keeps track of what fields have changed in the page editor and stores them with the activity so that they can be shown in the activity viewer or in page edit alerts. When a page has been modified that is also open to another user it now presents them with a dialog giving the option to reload the page or keep editing. A new “lock” option has been added that blocks a user from editing a page when it is already being edited by another. This is an alternative to just warning them with a pop-up, and it literally prevents them from being able to open the page in the page editor. This can be enabled in the module config and can also be optionally disabled for superuser. A new configuration setting has been added that lets you configure the refresh time in the page list (previously it was not editable). Added feature to limit the “you've been idle for awhile…” to the page editor only. When enabled, idle is still tracked for other admin processes, but idle alerts don't appear. Improvements to ProcessUserActivity (the included activity viewer module), including: 1) visible vs. hidden states are now more obvious. 2) Changes made in page editor are now included in the activity information. 3) The ajax drop-down navigation summary has been improved to include more information. Large portions of the module have been refactored into separate classes for better maintainability and other related improvements. This week there have also been a few commits to the core, but mostly just small fixes and phpdoc improvements, so not enough to write about here, but there likely will be next week. Thanks for reading and have a great weekend!