Leaderboard

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

Opened an issue for this here: https://github.com/processwire/processwire-issues/issues/1083. It's great that http to https redirects are finally in place (assuming that this was intentional), but it appears that it's going to be an issue for the core.

I believe the directory itself is the issue, it is "broken" at the moment. Broken because it forwards HTTP to HTTPS and this causes the check to fail, because the non-HTTPS url is hardcoded in the config file. Edit: So this is happening on all sites since yesterday. I tracked down the issue to the non-SSL service URL in the wire/config.php file. You can fix it by changing the $config->moduelServiceURL in your site/config.php like this: $config->moduleServiceURL = 'https://modules.processwire.com/export-json/';

You want to write that line: $mobile_menu = $homepage->children; in one of a few different ways, e.g.: $mobile_menu->add($homepage->children); // or, though no need to create a new PageArray beforehand in this case: $mobile_menu = $homepage->children->makeCopy(); to avoid any caching issues and avoid changing "builtin" PageArrays. If you directly assign $homepage->children, $mobile_menu points to the already loaded instance of the children PageArray of $homepage and your new, empty PageArray gets discarded. Repeated calls to $pages->get(1) are cached and return the page object already in memory. I can only guess since you didn't post that part of the code, but it looks like you may have inadvertently manipulated $homepage->children when you built your main navigation. Make sure to use add() or makeCopy() in that part too.

Definitely an interesting topic! We've developed a few PWA's for our clients recently, and I'd say that they've been very well received — but, to be fair, they've been a) services for existing members and b) basically apps that wouldn't work (well) as regular websites, so that option was out of the question. When it comes to native vs. PWA, in our case PWA seems like the obvious choice: easy to use and efficient to maintain, upgrades are effortless, and obviously the web platform is "our thing" (more than native anyway) ? Some "random" websites (news sites, blogs, etc.) are now offering the option to install, but to me that feels a bit weird: unless it's a service I'm going to use regularly and there's a clear benefit for me in installing it, I don't really see the point. In fact it can also be a little intimidating: why do I need to install this service to use it? Again I think it boils down to the question of "would it work as a regular website": if the answer is "yes", then perhaps it should just be that ?‍♂️ (Sorry to hijack the thread, by the way!)

If you have the Version Control module installed it might be the issue linked to below, which has been fixed in an update to the module:

Hi, With the deprecation of Instagram's API and therefore the end of the Instagram Feed module, I've developed a replacement module which uses the Instagram Basic Display API: https://github.com/nbcommunication/InstagramBasicDisplayApi To use this module you'll need: ProcessWire >= 2.7 A Facebook Developer account Access to the Instagram user account you wish to use Prior to installation, you'll need to create a Facebook app. The app you will create uses the User Token Generator for authentication - it does not need to be submitted for App Review (and therefore stays in Development mode). The README contains full instructions on how to create and set up the app and also how to use the module. The primary reason for this module's development was to retain functionality on existing websites that use the Instagram Feed module. To assist with upgrading, this module replicates some methods provided by Instagram Feed. I've already upgraded a couple of sites and it was quick and painless ? Cheers, Chris

No, it's not in the directory. You should really take a look at @netcarver's awesome: https://pwgeeks.com/ - just type "cache" in there and you'll find some other cache related tools. Thanks for the rundown of differences - that will be really helpful.

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.

These things usually go in ready.php I do all sorts of manipulation to forms from ready.php Example with link to privacy policy: $wire->addHookBefore('FormBuilderProcessor::renderReady', function($event) { $form = $event->arguments(0); $agree = $form->getChildByName('datenschutz');// get the field if(!$agree) return; $gdpr_page = wire('pages')->get(2096)->url;// URL to privacy policy $agree->appendMarkup = "<div class='ds-zusatz'><p> <strong>Ich stimme zu</strong>, dass meine Angaben aus dem Formular zur Beantwortung meiner Anfrage erhoben und verarbeitet werden.<br><strong>Hinweis:</strong> Sie können Ihre Einwilligung für die Zukunft jederzeit per E-Mail widerrufen. <br>Detaillierte Informationen zum Umgang mit Nutzerdaten finden Sie in unserer <a href='$gdpr_page'>Datenschutzerklärung</a></p></div>"; });

I'd install Tracy so you get a full debug trace so you can see what module is causing the issue with the setModuleConfigData() method. You could probably also just make sure all modules are up to date because I expect you're running an old version of a module where this has already been fixed.

Cheers! I am storing magazine style story credits (role, name, website url etc) in the Table. I feel that since Table only accepts text based fields this is an ok candidate for indexing. Can try to hack away at your module myself for now, no rush. Yeah I originally was thinking I wanted to use a client side library like to handle the search itself (fuzzy style to handle mis-spellings eg https://rawgit.com/farzher/fuzzysort/master/test.html ), but now I am thinking that is overboard and probably confusing. Will most likely stick with your module / pw search, and just do client side querying / rendering. Cheers!

Thanks @Mikie! I'll definitely look into the table part. There's no built-in way to get the entire index at the moment, but it might make sense to have one -- though what you're doing sounds like a perfectly good way to solve this for the time being. Anyway, I'll look into this as well. Just for the record, the renderResultsJSON method was added primarily to solve client side search needs (but I'm guessing that's not exactly what you're after) ?

Hi Adrian, thanks for clearing this out! No problem, if your module is intended for restricting to one branch, then we will suggest our client to use it that way. Greeting, Thomas.

I Just created a field using file type. In supported extensions I putted mp4 and mp3, and it worked well. Thank you, btw...

I wanted to write a bit of an update since this project was so well received last year. The Architekturführer has now been online for about nine months, and we have been getting mostly positive feedback. Thankfully, I was able to resolve all issues with Google's indexing of the page. The site's SEO is actually pretty solid now, being one of the first results when searching for "Architekturführer" (at least from within Cologne). We have also added some new content and restructured some pages. The homepage, for example, now features only selected projects. An iconic new entry that everyone who's been to Cologne in recent years will recognize is the Rheinboulevard Deutz. There's also an entirely new section for architecture-themed walks (Spaziergänge) that you can take in different areas of the city. If you come to visit for a day, make sure to check those out ? Finally, we got some traffic through word of mouth and a couple of architecture news sites, the visitor numbers are steadily rising each month. The only thing I find a bit lacking is that the number of PWA installations are very low. It seems the whole PWA concept has not really come through yet, or maybe it's just not that much of an added benefit compard to the normal site. I'm interested to see how PWAs will fare against native apps in the future, once they become more widely adopted.

Have given Media Library a look?

Thanks - from what I can tell, the backup is being created successfully - it's just not linked to. The new version just committed now returns this with the restore link included and the error color changed to match the PW uikit color and also make links white and underlined so they are visible. You mentioned above that the restore didn't work though, so please test the new version and let me know.

Well set() sets a property to the data property which is PW specific. I think it's mostly used to make it distinct data for a module or object and set data to a WireData module which is used to save data to DB like module/class configurations, change tracking etc. Defining a property directly in the class body makes it just a normal class property which PW doesn't threat special and it won't be in the data array. protected $foo = "bar"; // standard class property - and then set foo using set() $this->set("foo", "baz"); // set data array only $this->foo = "bar2"; // set the class property - You'll end with two "foo" which are not the same $this->foo // bar2 $this->get("foo") // baz (from data array) But If you don't set a class property and only use data array or set(key, value) to define a PW data property $this->set("foo" , "bar"); $this->foo = "bar2"; is the same "foo" Just look a the WireData class