FireWire

I sketched my ideas to come back and share them with the people who suggested the feature and I haven't worked on any true implementation yet. I can assure you there's no rush, I wanted to get some feedback before diving in and coding everything. If I had made a decision in private, programmed everything, then come back and announced the new changes it would be far more work to change my approach if it had a negative reception. Luckily the custom header actions are 20 lines of code and aren't a commitment.

I'm adding a header action with something similar to the following: Inputfields.addHeaderAction('title', { label: 'Some custom actions', icon: 'fa-question', menuItems: [ { label: 'Option 1', href: 'https://somedomain.ddev.site/admin/page-to-show/', modal: true, active: true, callback: null, }, { label: 'Option 2', callback: function() { ProcessWire.alert('Shows option 2'); }, active: true, }, { label: 'Option 3', callback: function() { ProcessWire.alert('Shows option 3'); }, active: true, }, ] }); When there is a combination of types of actions then the options that execute a callback will trigger the option that executes a href/modal. When clicking the option that opens a modal, the other options are not triggered. Example that opens the "Logs" page in a modal. Clicking "Option 2" executes both the callback and opens the modal in "Option 1": The same occurs if "Option 3" is clicked. I'm trying to figure out if this is something I'm doing wrong or if there's a bug when mixing option types. I was able to create a workaround by adapting this code by @bernhard that uses a callback to programmatically open a modal: Inputfields.addHeaderAction('title', { label: 'Some custom actions', icon: 'fa-question', menuItems: [ { label: 'Option 1', active: true, callback: function() { const link = document.createElement("a"); const $link = $(link); $link.attr('href', 'https://moduledev.ddev.site/admin/setup/logs/'); $link.addClass('pw-modal'); $link.on('click', pwModalOpenEvent); $link.on('pw-modal-closed', () => $link.remove()); $link.click(); }, }, { label: 'Option 2', callback: function() { ProcessWire.alert('Shows option 2'); }, active: true, }, { label: 'Option 3', callback: function() { ProcessWire.alert('Shows option 3'); }, active: true, }, ] }); This works but doesn't use the native API. Anyone have any insights that could help? Many thanks!

@bernhard I like your thinking 🤝 @Tiberium I'm glad you chimed in as well. Good to know that there are many people that will benefit from a new feature. Here's the UI I'm working towards: Going to create a new header action for translation related features. This will keep the UI tidy, clear all will be enabled by default, and doesn't need an option to enable/disable it on the module config page. @bernhard The icon to show the translator will be moved from the icon next to the translation button to the menu for consistency, since it's hover there won't be extra clicks. It will of course politely ask you if you are sure you want to nuke all of the content... I like this implementation because it will provide a good location for possible future features as well without crowding UI for fields. It will take a little bit to implement, I'm trying to keep up with work and I think I caught a bug with the custom header actions in PW core. I'll tag you both when it's on the dev branch so you can take it out for a test drive.

I like to live dangerously* *please don't live dangerously Thank you for the correction of my oversight @teppo. I've edited my example to include that in case someone doesn't make it further down the comments 👍

@bernhard I was working on some blocks in RPB and noticed that there were some edge cases where changes weren't being detected by RPB. I ran into this with the trash icon on RepeaterMatrix items. Clicking it checks a hidden checkbox programmatically and doesn't emit a change event, so it's pretty much invisible to everything else that isn't RepeaterMatrix code. I added this mutation observer to InputfieldRockPageBuilder.js to watch for elements that have had the 'InputfieldStateChanged' class added. // trigger changed event when InputfieldStateChanged is added to elements $(document).on('ready', function () { const rpbItemsObserver = new MutationObserver(mutations => { mutations.forEach(mutation => { if (mutation.target.classList.contains('InputfieldStateChanged')) { RockPageBuilder.changed(mutation); } }); }); $('.rpb-items').each(function (_, rpbItem) { rpbItemsObserver.observe(rpbItem, { childList: true, subtree: true, attributes: true, attributeFilter: ['class'] }); }); }); In my testing this took care of some edge cases where changes aren't visible to RPB. Could be helpful for handling other sneaky inputs as well 👍

@protro I use this module with htmx and it works nicely. It's pretty easy to do and it can all be done in HTML without handwriting JavaScript or parsing JSON. Here's a simple example. It should work, it may need tweaking but the concept is accurate. <!-- Your search form --> <style> .search-box { position: relative; } .search-indicator { align-items: center; display: flex; inset: 0; justify-content: center; opacity: 0; pointer-events: none; transition: opacity .3s; } /* Style your AJAX indicator as you please */ .htmx-request .search-indicator, .htmx-request.search-indicator { opacity: 1; pointer-events: auto; } </style> <div class="search-box"> <form hx-get="the search URL here" hx-target="#search-results" hx-disabled-elt="button[type=submit]" hx-indicator=".search-indicator"> <input type="search" inputmode="search" name="q" placeholder="What would you like to find?"> <input type="submit" value="Search"> <div id="search-results-container"> <!-- Search results will load inside this div --> </div> </form> <div class="search-indicator"> <span>Searching...</span> </div> </div> hx-get tells htmx to request the page from the URL you provide hx-target tells htmx where to put the markup that it receives back from the AJAX request, it accepts any CSS selector hx-disabled-elt directs htmx to disable the submit button during the request to prevent people from clicking the button multiple times, it accepts any CSS selector hx-indicator isn't required, but tells htmx which element to add the .htmx-request class while the request is in flight and then remove it when the results are loaded for a nice "loading" display. It accepts any CSS selector On the search page all you have to do is render the results that will appear inside #search-results-container, just markup. This is a rough example, but just illustrates how simple it can be. You'll have to tailor this to your needs. You can probably use markup that the SearchEngine module generates, but I haven't used that before myself. <div id="search-results"> <?php if ($searchResults->count()): ?> <ul> <?php foreach ($searchResults as $result): ?> <li> <p><?=$result->title?></p> <a href="<?=$result->url?>">View Page</a> </li> <?php endforeach ?> </ul> <?php else: ?> <p>There were no search results for "<?=$sanitizer->entities1($input->get->q)?>"</p> <!-- Thanks to teppo for reminder to sanitize --> <?php endif ?> </div> That's the only markup you need. You'll probably need to do some additional work to make things like paging happen, but it's all doable. I cobbled this together based on some code I've already written so it's just a starting point and probably needs some tinkering. Here's a handy reference of htmx attributes that will let you do anything you need.

I do want to keep the scope of Fluency focused, but I'm comfortable with extending what it provides modestly. It would be a similar to how Fluency adds the content change indicators to tabs. It isn't something specific to translation functionality, but because Fluency provides the ability to do "mass translation" across multiple languages it's something that is helpful. I think that a "clear all" type of button is something in the same spirit. If Fluency can generate large amounts of content, it may be useful to have an extra tool to make working with it a little easier. It's the "enhancement" part of the "translation enhancement suite for ProcessWire" 😎 ha! I am weary of going too far beyond and making Fluency intrusive. Maybe adding it as a config option, off by default, to enable that can be helpful and stay out of people's way.

@bernhard I had a response typed out, didn't click "Submit Reply" and just came back find out that you never saw it 🤦‍♂️ Not clearing is intentional. The only way Fluency works right now is to take the source content and make the request to ProcessWire, pull from cache, or make a call to the translator API, then send it back to the client and replace the contents. At one point I think it may have cleared it but I updated the module to prevent taking any action if the source field is empty since it saved a round trip and an empty call to the translation API. Since Fluency is for translating and adding some nice-to-have things like the content change indicators on the tabs, maybe a secondary button off to the right to "Clear all content" would be useful? That could be a more intentional UI feature. What do you think? Worth doing?

This.

@bernhard That was very helpful, thank you for taking the time to explain more. I definitely don't want to replicate past ideas or force RC into trying to be something it isn't! This is an interesting idea. I'm understanding your approach better now and I think that my concept was too focused on having the RockDateRangePicker field do "too much". I'll share a little more about what I got wrong when using RC. When I opened the original event and saw the RDRP field it was confusing since it automatically shows the date and "Recurring" is checked, to indicate that this is a recurring event, but the contents of the RDRP field do not match the schedule/recurrence that the event was created with. If I uncheck "Recurring" and save the event page, nothing is changed with the other events, so I was confused on what the purpose of the Recurring button, schedule, list of dates, etc. was for. Even though you labeled it "Create Additional Events", I was focused on the UI since it presents things to interact with. The other part where I stumbled was the "This event is part of a recurring series" message. It made me think that clicking on "Click here to edit the main event" had something to do with the recurrences since it showed the other buttons below the date field. Since this occurrence isn't the "main" event, would it be a good idea to remove the "Recurring" and "Range" buttons and only allow for setting/editing the time? I used Thunderbird for my email/calendar client and took a look at how the UI works. I had never thought about it before and it's also more simple than the suggestion I was making, and might be more inline with RC's approach. I made a quick video and if managing recurrences could be something like this it would work really well. The Thunderbird UI, date selection, calendar style, etc. can all be ignored of course. Here are the steps I took: Create an event that occurs every Tuesday Edit the event and change it so that it occurs every Wednesday Move one of the occurrences in the series to Thursday Edit the event to change it back so it occurs every Monday calendar_events.mp4 What is interesting is that moving the one occurrence to Thursday "detached" it from the schedule. It is still a part of the main event, but the date is no longer managed by the recurrence rule. So I was able to change back from every Wednesday to every Monday and that individual occurrence was not changed. Any further edits to the schedule, like changing it to Monday of every other week, would also not affect the occurrence I moved to Thursday. Maybe the "generator" UI only appears when you create the event and then afterwards it only lets you edit the recurrence rule without displaying or managing any of the individual pages. Thunderbird does not have any "central" manager for all events the way that Recurme did or in the way that I was suggesting. It only allows you to adjust the schedule and doesn't let the user get involved any deeper than that when dealing with the schedule. Like RC, the calendar UI is used to manage individual occurrences. Interested in your thoughts. This is different than what I was originally thinking and perhaps this style is more compatible with RC's approach. RC has the great approach by using pages as the way to store and retrieve data since it doesn't "fight" the ProcessWire style. I definitely don't want to stray from the formula 😎

@bernhard One of the other things that may be difficult for the end user is after creating a recurring event, there's no reference to the recurrence afterwards. So creating a recurrence with advanced options like this: Opening that event again only shows "Every day for 100 times" and the "Simple" view rather than "Advanced". It's not really possible to tell what the schedule is for a recurring event after creating it. It seems like the date/occurrence field is only a generator and can't be used to re-schedule, change, or manage the recurrences. Opening the original event should show how the events are scheduled, and then let you update it. It would be good to be able to delete existing recurrences by clicking the trashcan icon next to each. When changing or deleting recurrences the "Create Events" button could change to "Update Events" which re-run modifications/deletions to recurrence pages on the server. The client that will be using the calendar is coming from their site that was built using Recurme which isn't as powerful as RC but lets you view and edit the schedule. Without being able to manage events from one location I'm not sure how they will respond to losing the ability to do that.

@bernhard I'm having trouble with selecting the "All events of this recurring series" option when deleting an event. When I choose that option the event is deleted, then it shows a "This page has no process assigned" message. When I close the window, only that one event has been deleted and all the other recurrences are still present. deleting_recurring_events_all_in_series.mp4 If I open the next occurrence it shows "This event is part of a recurring series. Click here to edit the main event", but clicking on that opens the page that is in the trash. delete_recurring_event_parent_in_trash.mp4 When I click on the next event and attempt to delete it with the option "This and all following events", it still only deletes that one event and shows the "This page has no process assigned" message. delete_all_following_events.mp4

@bernhard I ran into the broken recurring event that noodles was having. After performing this fix in RockCalendar.module.php everything works as expected. I'm on 1.6.1. Not sure if there's something "special" about my PW setup that is causing the issue but it works for me now.

I knew that at some point but didn't connect it in my brain when I made the map feature. The other ones were made before I knew that. The rest of them are original. I just upgraded RPB and saw the notes on the module config page which was a good reminder 👍

Hi all (yet again)! I'm still at it with some new buttons added, now up to 28 in total. New buttons include Form, LightboxGallery, Map, and CalloutImage, as well as a reverse color CalloutImage. Happy building! 😎

An escape key binding could be implemented with a snippet of code that looks for a modal element with a class or attribute defining it as active. So a binding that looks for that and executes a click action on the nearest close button or programmatic closing may be doable. That's a hypothetical based on instances where I've implemented it in my projects though, so just a cursory thought. I find myself reaching for the escape key often to exit windows, so it would be a welcome feature if implemented!

As someone who has implemented accessibility measures before, AA is the standard for public non-governmental sites serving different abilities and satisfies all legal definitions of accessibility. Adhering to AAA standards means a full compromise of the design to achieve that rating and is a rarity. These ratings are also targeted at public facing websites where legal compliance is required. A public facing site, i.e. the site that ProcessWire manages, should adhere to the standards that apply to the audience it serves and is the responsibility of the developer. The admin has a different audience. With the new theme having flexibility in customization, as with @ryan mentioning the availability of CSS variables in the new design in a more recent update post, higher levels of compliance could be achieved by theming. Even if CSS variables were not available, the admin them can be (and has been) modified. If there are special use cases where developers using ProcessWire must provide an experience for users or clients that need additional levels of accessibility then it would be a good place to have some community help developing themes that meet more strict standards. Consider this- ProcessWire itself is an application used for the production of content, not consumption of content. To that end, accessibility measures designed for content consumption should not be implemented at the cost of usability or preference for it's purpose and widest user audience. If someone needs the ProcessWire admin to look like this, then I and many other users, would kindly ask that they implement a theme to accommodate that and release it to the community as a module. This is a good target. Adjusting shades to help with contrast would help a wide audience with minimal impact on development costs. Tabbing and escape key binding are good. Considerations at this level are general good practice. The differences between applications (ProcessWire) and websites (a product ProcessWire can be used to produce) is a good thing to keep in mind. It would be difficult to expect the end user of ProcessWire to have the ability to use all functionality and manage a site on the back end using a screenreader and keyboard alone which is one of the goals of accessibility even at the AA level. I say this as a person currently developing a website for a nonprofit organization that serves the Parkinson's disease community. Their site needs to be accessible (we are targeting AA) but they would never consider having the admin they work with be accessible by the people they serve.

Hey translators and polyglots! v2.1.1 has been released to address a bug introduces in 2.1.0 that affected some, but not all, users. If you are experiencing issues please reference this Github issue that may provide more information. If you haven't experienced any bugs, upgrading is still recommended to prevent any oddities in the future. Unlikely, but safer than sorry. 2.1.1 is available via the modules directory and can be upgraded from the module config page in your ProcessWire admin. Thank you to @jacmaes, @ryangorley, and others contributing in the Github issue for reporting and assisting with debugging!

@bernhard Many thanks as always 🙌

Heyo, Just ran into a conflict between RPB and other fields on the page. I'm using a custom inputfield that uses Quill as the editor. There's an event listener that is catching changes in an instance of a Quill input while the field is located outside of RPB blocks. InputfieldRockPageBuilder.js L327 // monitor inline ckeditor fields $(document).on("blur keyup paste input", "[contenteditable]", function (e) { RockPageBuilder.changed(e); }); Quill uses a contenteditable attribute for the editor so an instance of that field anywhere on the page is triggering a RPB field update event. // monitor inline ckeditor fields $(document).on("blur keyup paste input", ".rpb-item [contenteditable]", function (e) { RockPageBuilder.changed(e); }); I scoped the event listener selector by adding .rpb-item and that kept it from firing when editing a Quill field, but I don't have any CKEditor fields to test whether that affects other fields. "That fixed it for me, don't know if it breaks something for someone else." 😆

@ryan Makes sense. Really looking forward to seeing what y'all been cooking up! I paused the other day and appreciated all the quality of life improvements that have come over the years and value them as much as the big features. Almost can't wait. It's like Christmas for adults, who are also developers.

Hey everyone! Fluency v2.1.0 has been released with new features and bugfixes. Translation cache now caches translations permanently until cleared on the module config page when translation caching is enabled. Some Fluency methods are now hookable. Refer to README for documentation and use case. Credit to @Hari KT for inspiring this feature. Globally excluded strings can now be entered either one per line or all on one line separated by a || (double pipe). Credit to @bernhard for the feature suggestion Translating static strings using the ProcessWire translator now offers the ability to specify the language code to be used for the source language Fix issue where strings configured to be excluded from translations on the module config page were being translated. Credit to @bernhard for finding and reporting Correct issue where custom language code field that may optionally be added to ProcessWire language pages was inconsistent and incorrectly documented. Fix missing localization strings for some errors Various small improvements, some bugs that had not yet affected regular usage Various housekeeping and code cleanup that only matters if you like reading the source 🤷‍♂️ Thanks all, and please report any issues!

I think this approach is an excellent idea and hopefully something that will be considered. In addition to the benefits @teppo described, using CSS really open things up for JS as well where getting/setting values via scripts could make admin development very dynamic. Laying some future friendly groundwork in CSS would be a major advancement.

Boy howdy, I'm pretty excited to see this.

Perfect!!! This will make everyone's dreams come true 🙌 I have been looking forward to spending more time with RockCalendar. I've just had to prioritize things according to client needs so I've had to put that feature on the back burner but can't wait to work with it. It's such a relief to know that there's a quality modern module to handle this feature. Well done and many thanks! Note: It double posted for some reason, but this is the better comment 😆