Leaderboard

In an ongoing effort to provide a sort of case study, and more info about this, I'll post random screens and info about the various features of this site. (1) Custom Dashboards The site uses a custom module that supports multiple dashboards. Any given dashboard is configurable and access controlled also. This is the main dashboard: (2) The admin editor pages take advantage of some great modules, namely RuntimeMarkup @kongondo, PageFieldInfo @Robin S, Field Descriptions Extended and more, There is also a new module not released yet called Admin Comments, which for this project got a lot of use. When dealing with a large and complex data collection as was the case with this project, the editors benefited from the ability to have the data auto-analyzed on each work so the "auto flags" field helped with that. The comments also allowed editors to post information, ideas and comments right into the page editor. The AdminComments module also provides the option for any posted comment to be emailed to the other team members (selectable), and the notification email (which is customizable) allows the recipient to click directly to the editor for that page. This saved incalculable hours of work, and enhanced communication during the project, across this large data set.

module is also now in the modules directory at https://modules.processwire.com/modules/modules-manager2/ Still pending

In most cases (probably all I've heard of so far) this type of issue is caused by the security settings on the host, mod_security (ModSecurity) module, etc. LiteSpeed apparently has its own WAF feature, so that's probably where I'd start digging into this; is something like that enabled, have you recently made any changes on the host, or could the host have been updated by someone else? Has this worked before?

I'd run this check to see if mod_sec is running first and if so, then you can figure out how to disable it.

It's not so much about Hanna Code specifically, but rather posting (obvious) code via any web form. ModSecurity and different WAF implementations may detect this and assume malicious intent, which is problematic here since we actually want (authenticated) users to be able to post code. The easiest thing to do would be disabling this feature altogether, either globally or at htaccess level for a specific site. I'm not familiar with this solution so I've no idea if there's some way to keep it on for most users and/or just disable parts of it, but you may find more about that from the LiteSpeed manual. Edit: at least in Apache you can wrap <IfModule></IfModule> with <Directory /some/path/on/disk/></Directory>, which might help to selectively disable this feature. And it's also possible to check if a cookie exists, in which case you could sniff for a "wires" cookie first, though I've never tested this in practice and don't know if those will work together.

Sure, because they are field settings. This feature wasn't tested and used too many times (by myself) but when I opened a local PW site I usually use for testing, the following was filled int he FieldOverrides textarea in AOS: [Enable any markup in any CKEditor] ?field = "inputfieldClass=InputfieldCKEditor" useACF = 0 usePurifier = 0 Apparently it works, but it's important to know how. AOS is loaded in the admin only, so if you override a field like this, you won't see useACF=0 if you dump the field settings in the frontend (eg. with Tracy). But in the admin the value is overriden, so you can add any markup and it will be saved to the DB. On the contrary, if you decide to remove this override later on, the data won't be changed in the DB automatically unless you re-save the page again.

I worked hard on the module the last days, and rewrote much of the core logic and added some more features. I wanted to record a screencast yesterday, but my recording software ignored my mic. So I show you some annotated screenshots instead. Since then, many things changed again. Right now I am working on downloading and installing a module via a URL, and also making a transition to modal dialogs instead of panels, if applicable. I moved the whole button logic from the PHP script to a vue component. So I am flexible how to display the buttons, and I can reuse them in the cards and in the table layout: I added a reduced card layout, which moves the description of a module into the "more information" accordion: Updated TODOs with much more features to come. I will work on the module in the next 2 days and hope to make so much progress, that I can finally release the first version on github.

Process Cache Control This module provides a simple solution to clearing all your cache layers at once, and an extensible interface to perform various cache-related actions. The simple motivation behind this module was that I was tired of manually clearing caches in several places after deploying a change on a live site. The basic purpose of this module is a simple Clear all caches link in the Setup menu which clears out all caches, no matter where they hide. You can customize what exactly the module does through it's configuration menu: Expire or delete all cache entries in the database, or selectively clear caches by namespace ($cache API) Clear the the template render cache. Clear out specific folders inside your site's cache directory (/site/assets/cache) Clear the ProCache page render cache (if your site is using ProCache) Refresh version strings for static assets to bust client-side browser caches (this requires some setup, see the full documentation for details). This is the basic function of the module. However, you can also add different cache management action through the API and execute them through the module's interface. For this advanced usage, the module provides: An interface to see all available cache actions and execute them. A system log and logging output on the module page to see verify what the module is doing. A CacheControlTools class with utility functions to clear out different caches. An API to add cache actions, execute them programmatically and even modify the default action. Permission management, allowing you granular control over which user roles can execute which actions. The complete documentation can be found in the module's README. Plans for improvements If there is some interest in this, I plan to expand this to a more general cache management solution. I particular, I would like to add additional cache actions. Some ideas that came to mind: Warming up the template render cache for publicly accessible pages. Removing all active user sessions. Let me know if you have more suggestions! Links https://github.com/MoritzLost/ProcessCacheControl ProcessCacheControl in the Module directory CHANGELOG in the repository Screenshots

I'm currently building a Fieldtype/Inputfield for selecting date and time ranges (eg for events). There was quite some interest in this thread, so I thought I start a dedicated discussion... Background: I guess everybody of us knows the problem: You want to present events on your website and you start with a new template and a title and body field... For events you'll also need a date, so you add a datetime field called "eventdate". Maybe the event does not take place on a specific day but on multiple days, so you need a second field... Ok, you rename the first field to "date_from" and add a second field called "date_to". So far, so good. Then you want to list your events on the frontend. Simple thanks to the pw API, you might think. But you realize that it's not THAT simple... Which events take place on a specific day? What would the selector be? Yeah, it's not that complicated... it would be something like: $from = strtotime("2020-01-01"); $to = strtotime("2020-02-01"); $events = $pages->find("template=event, date_from<$to, date_to>$from"); Why? See this example, where the first vertical line represents the $to variable and the second is $from: The start of the event must be left of $to and the end must be right of $from ? Ok, not that complicated... but wait... what if the date range of the event (or whatever) was not from 2020-01-18 to 2020-02-25 but from 18 TO 25 (backwards)? The selector would be wrong in that case. And did you realize the wrong operator in the selector? We used date_to>$from, which would mean that an event starting on 2020-01-01 would NOT be found! The correct selector would be >=$from. That's just an example of how many little problems can arise in those szenarios and you quickly realize that the more you get into it, the more complicated it gets... Next, you might want to have full day events. What to do? Adding a checkbox for that could be a solution, but at the latest now the problems really begin: If the checkbox is checked, the user should not input times, but only dates! That's not possible with the internal datetime field - or at least you would have to do quite some javascript coding. So you add 2 other fields: time_from and time_to. You configure your date fields to only hold the date portion of the timestamp and show the time inputfields only if the "fullday" checkbox is not checked. We now have 5 fields to handle a seemingly simple task of storing an event date. That's not only taking up a lot of space in the page editor, you'll also have to refactor all your selectors that you might already have had in place until now! Idea So the idea of this module is to make all that tedious task of adding fields, thinking about the correct selectors etc. obsolete and have one single field that takes care of it and makes it easy to query for events in a given timeframe. The GUI is Google-Calendar inspired (I'm acutally right now liking the detail that the second time input comes in front of the date input). I went ahead and just adopted that: Next steps I'm now starting to build the FINDING part of the module and I'm not sure what is the best way yet. Options I'm thinking of are: // timestamps $from = strtotime("2020-01-01"); $to = strtotime("2020-02-01")+1; // last second of january // option 1 $pages->find("template=event, eventdate.isInRange=$from|$to"); $pages->find("template=event, eventdate.isOnDay=$from"); $pages->find("template=event, eventdate.isInMonth=$from"); $pages->find("template=event, eventdate.isInYear=$from"); // option 2 $finder = $modules->get("RockDaterangeFinder"); $finder->findInRange("eventdate", $from, $to, "template=event"); $finder->findOnDay("eventdate", $from, "template=event"); ... I think option 1 is cleaner and easier to use and develop, so I'll continue with this option ? Future As @gebeer already asked here I'm of course already thinking of how this could be extended to support recurring events (date ranges) in the future... I'm not sure how to do that yet, but I think it could make a lot of sense to build this feature into this module. I'm not sure if/how/when I can realease this module. I'm building it now for one project and want to see how it works first. Nevertheless I wanted to share the status with you to get some feedback and maybe also get your experiences in working with dates and times or maybe working with recurring events (or the abandoned recurme field). For recurring events the finding process would be a lot more complicated though, so there it might be better to use an approach similar to option 2 in the example above.

Many thanks @Robin S. I had previously tried that, but it didn't work - hence my comment about not being able to set it directly. I now realise that the cause of that was that I had previously set initValue, to disable changing the template. After that, setting value with the full selector does not work - it is necessary to first remove the "template=..." from the selector. Thanks for giving me the confidence that I was setting it correctly so that I persisted in hunting down the "feature". So - adding a regex to split the selector into template (for initValue) and non-template (for value) components works a treat.

I have a hosting account that runs litespeed, and i use this snippet in the .htaccess, which was recommended by Ryan. <IfModule security2_module> # Allow ModSec rule processsing without disruptive action SecRuleEngine DetectionOnly SecFilterEngine Off SecFilterScanPOST Off </IfModule>

Aforementioned issue should be fixed now. As was already mentioned above, this could only be replicated under specific circumstances on macOS; nevertheless it seems that defining the "u" flag for preg_replace() is a relatively safe thing to do, so I've gone ahead and done that. If it ends up causing trouble, I may have to reconsider that, but at least for now it seems to be all good ? Thanks @Mikie for tracking this down!

added new videos to first post

version 2.0.101 released * sanitize all class names for better security * optimize delete function to catch and display errors * unify methods a little bit more (same vars, etc) * remove some debug messages

Oh right, I was thinking about InputfieldSelector in the context of Lister. You just set the value of the inputfield: $f = $this->wire('modules')->InputfieldSelector; $f->name = 'test_selector'; $f->label = 'Test InputfieldSelector'; $f->value = "template=news_item, colours.title=Blue";

There is some example API code in a post above:

Success!!! Completely cleared out everything, rebuilt the field from scratch, readded to the template and now it is working. Very strange that the whole function worked except the delete/insert statements seemed to be ignored, but for whatever reason recreating it all again works fine now. Thanks again for all your help, I truly appreciate it! Whilst I would have preferred a variant of the Table field for my structure I can work around this one. Sometimes perfection gets in the way of things!

We should end our OT ishness ? but there are other similar shortcuts in that panel as well - worth keeping open and seeing what it offers up in various parts of the PW admin. Let me know if you have any other suggestions for features for it.

OMG... wish I knew that some such shortcut existed before.

Or in this case you could just use Tracy's Admin Tools panel which has a one-click "delete field" button when viewing a field's setting in the admin ? PS - not meaning to be a downer on your module in general, it's just not necessary for this use case.

It sounds like output formatting is OFF when the data of the image is requested, therefore pw treats the data of the field as PageImagesARRAY. That's why you have to get the first item manually. This step is done automatically when output formatting is ON and your field is set to single image.

It has been quiet here, but I'm using RockMigrations on a daily basis. It can also be handy during site development, eg today I had to refactor my setup (change some fields, delete them, create new fields instead). I only have test data on this site, so when I want to delete a field, I really don't care about losing data... PW asks a lot of questions before removing a field from the system (which is good in 90% of the cases), but for me it is often a burden. RockMigrations + TracyDebugger to the rescue: $rm = $modules->get('RockMigrations'); $rm->deleteField('location'); Manually one would have to remove the field from the templates first, confirm that one might lose data etc.; Too much clicking imho ?

Maybe you can find some useful code from the downloadAndInstall() method in my ModuleToolkit module: https://github.com/adrianbj/ProcessModuleToolkit/blob/09b437d888c270ffe01f3a80fc5dccab3136e42e/ProcessModuleToolkit.module#L1278

I just released the beta version on github. Updated my first post with the download URL. A new video is coming soon, as many features have changed. For example panels are only being used for a module's settings. All other actions are executed via AJAX and show a notification on success. Happy testing, and have fun with it.

Hi @adrian, I didn't know that module existed, it's not in the directory, is it? Because I looked if something like this already existed and didn't find anything. Might've saved me some trouble ? That said, I had a quick look, here's what I found in comparing both modules: ClearCacheAdmin exposes more options through the setup page, so there are available to everyone, whereas ProcessCacheControl has it's options in the module configuration, so they are only available to the developer. ClearCacheAdmin has multiple links (and multiple options) on the process page, giving the user more fine control, whereas ProcessCacheControl goes for a simpler interface and bundles all those actions into one (configurable) action with a single button. ProcessCacheControl can delete $cache entries without an expiry date, which ClearCacheAdmin doesn't as far as I can tell. ProcessCacheControl also lets you configure caches to be deleted by namespace, whereas ClearCacheAdmin offers each cache entry to be deleted individually (I think this has mostly to do with the module being a bit older, I believe $cache didn't have all those options back then). The largest difference is my concept of "cache actions", which ClearCacheAdmin doesn't have. I'm not sure how useful that will actually be yet. I think if I can expand on the actions available by default, it will be pretty handy. With ProcessCacheControl, you can add custom cache actions / profiles through the API, that may be useful depending on the use case. Adding to that, ProcessCacheControl has permission checks on a per-action basis. ProcessCacheControl can be modified and executed through the API. In particular, you can modify the default action and execute any action programmatically.

Guys, just to give you an update: I still want and have to work on this module before I can release it on github. I am changing a big part of the rendering of the actions, so they work either in card or in table view. Sadly I hadn't much time in the past, because I changed my company to a GmbH, had to design a new logo and website texts, and all that legal stuff that comes with changing your company. And don't forget about my customers, who also want their work done. I hope to get some time in the next weeks, so maybe I can work after christmas on this, but no promises.

Hi Jens It looks great and is badly needed too. Did you want feedback to be provided privately or on this thread?

Announcement: I've created a new branch on github with the requested feature by @felix. Please can you and / or anybody else try this out and give some feedback. If everything is working as expected, I will push this to the master branch. Short introduction: You can specify how many and what ever params you want into an array that is called $config->wirmailsmtp. Every valid key of this array will override the key of the stored modules config setting. // example entry in site/config.php $config->wiremailsmtp = array( "smtp_host" => "smtp.example.com", "smtp_port" => 587, "smtp_ssl" => 0, "smtp_start_tls" => 1, "smtp_user" => "yourusersname", "smtp_password" => "youruserspassword", "extra_headers" => array("Organization" => "Horst Nogajski - Fotografie & Webdesign", "X-Header" => "Some Content") ); To see your resulting (merged) settings you can var_dump the output of the method getSettings(): // debug example in a template file $mail = wireMail(); echo "<pre>"; var_dump($mail->getSettings()); I tested it here myself and it seems to work fine. EDIT: I forgott to mention that I removed the required flags from the modules config settings for smtp_host and smtp_port. This way, both settings now may stay empty in the config screen, but can be set via the $config->wiremailsmtp array. The downside would be that the modules config screen isn't that robust anymore in regard of misconfiguration. Is this acceptable, or should there also be a required setting in the modules config screen? This is open for discussion. ?