Leaderboard

There were lots of core updates this week, very much in the same theme as last week — major long term quality improvements for the core, but no shiny toys to play with… Just lots of good and solid foundational core improvements, and a few fixes too. It's mostly kind of technical stuff that's probably not that interesting to read about, so I'll keep this short, but for those interested here's the commit log. Thanks for reading and have a great weekend!

Hm, that's interesting - I didn't think about that ? I think it's not too late for that change and will make using RockFinder3 easier, so I just committed that change, thx!

@gmclelland UI Blocks is a front-end output strategy that we built at Solution Innovators. Not in the module directory yet due to a lack of good documentation. But I'm getting close to having that ready ?

Thank you guys, i cleared the cache in the modules list view and it works as espected now.

So.. after trial and error, and trial, and error, and more trial, and.. fails and fails and fails... stupidly tumbling around in the dark.. because my js skills / understanding are about as good as my russian skills (limited to "da" that is). But... yay! I discovered something brilliant. So.. just in case anyone's intereste in barba.js and the Instagram Basic Display API combo cocktail ?, (and perhaps isn't any properly js sufficient...), here goes how: I found out after confusingly and hopingly staring at the barba.js docs for any miracles, I finally discovered this https://barba.js.org/docs/advanced/strategies/#Cache : barba.init({ cacheIgnore: ['/instagram'], }); And that does the trick! But again, thank you @nbcommunication once again, for being such an awesome and so helpfu Processwirian ! ❤️ Have a great weekend! ? Jonatan

Just to clarify, are you do a Modules > Refresh? It also works fine for me. But. again, please don't use this technique for CSS tweaks - it will result in lots of unnecessary pain when the core version of the module is updated.

I tested it, and it look like its working, see my capture : - columns echo'd on frontend - ok - debug dumps - ok

You can disable autocomplete on input elements with the autocomplete attribute. You can modify built-in forms through hooks by looking up which Process module is creating the form and then hooking after it's buildForm method. In this case, it's ProcessPageAdd. This hook sets autocomplete="off" on both the title and the name input fields: // site/init.php wire()->addHookAfter('ProcessPageAdd::buildForm', function (HookEvent $e) { $form = $e->return; // disable autocomplete for the title field $title = $form->getChildByName('title'); $title->attr('autocomplete', 'off'); // disable autocomplete for the name field $pwPageName = $form->getChildByName('_pw_page_name'); $pwPageName->attr('autocomplete', 'off'); });

I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it. WayFathomAnalytics WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages. Links GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics? Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses. Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business. Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more

Not to keep a thread going, but will this eventually become available in the modules directory? I really like the approach you have taken!

What about ditching the "3" ? IIRC there wasn't an API variable for the first version anyway, was there? Wouldn't this be cleaner going forward?

Very good news for the weekend: RockFinder3 does now work again with the latest dev version of PW (thx to @adrian for making Ryan aware of the issue that also affected tracy!) ? v1.0.6 is up and running smoothly and ready for a long future ? $owners = $rockfinder3 ->find("template=person") ->addColumns(['title', 'age']) ->setName('owner'); // set name of target column db($rockfinder3 ->find("template=cat") ->addColumns(['title', 'owner']) ->join($owners) ->getSQL()); SELECT `pages`.`id` AS `id`, `_field_title_5ed16c868e555`.`data` AS `title`, GROUP_CONCAT(DISTINCT `_field_owner_5ed16c868e66d`.`data` ORDER BY `_field_owner_5ed16c868e66d`.`sort` SEPARATOR ',') AS `owner`, GROUP_CONCAT(DISTINCT `join_owner_5ed16c868ea01`.`title`) AS `owner:title`, GROUP_CONCAT(DISTINCT `join_owner_5ed16c868ea01`.`age`) AS `owner:age` FROM `pages` LEFT JOIN `field_title` AS `_field_title_5ed16c868e555` ON `_field_title_5ed16c868e555`.`pages_id` = `pages`.`id` LEFT JOIN `field_owner` AS `_field_owner_5ed16c868e66d` ON `_field_owner_5ed16c868e66d`.`pages_id` = `pages`.`id` LEFT JOIN ( SELECT `pages`.`id` AS `id`, `_field_title_5ed16c868de1f`.`data` AS `title`, `_field_age_5ed16c868dea8`.`data` AS `age` FROM `pages` LEFT JOIN `field_title` AS `_field_title_5ed16c868de1f` ON `_field_title_5ed16c868de1f`.`pages_id` = `pages`.`id` LEFT JOIN `field_age` AS `_field_age_5ed16c868dea8` ON `_field_age_5ed16c868dea8`.`pages_id` = `pages`.`id` WHERE (pages.templates_id=48) AND (pages.status<1024) GROUP BY pages.id ) AS `join_owner_5ed16c868ea01` ON `join_owner_5ed16c868ea01`.`id` = `_field_owner_5ed16c868e66d`.`data` WHERE (pages.templates_id=44) AND (pages.status<1024) GROUP BY pages.id PS: I decided to change the case of the API variable from $RockFinder3 to $rockfinder3 (all lowercase)!

is this correct folder ? my folder screenshot below

Yes maybe the cache. Try to clear the compiled files and your browser cache then refresh the module. What I did is, downloading your module from Github, installed it, dumped the var with TracyDebugger - which you should install in a hurry - and tada, it seem it worked ??

Yes, exactly what you did, copying the module from Wire to Site/modules then refresh and select the new module when asked. After a refresh : After a click on "InputfieldCommentsAdmin" link : Same thing for "FieldtypeComments" and the CSS should now load correctly. -------- Anyway, I suggest you to avoid this technique and to copy the CSS from the module and to paste it on your own principal main CSS file and tweak the CSS comments there. Once that done, you won't have to worry about keeping the module up-to-date.

Hi @jonatan, You would probably need to do something like: var resetPagination = new Promise(function (resolve, reject) { var xhr = new XMLHttpRequest(); xhr.open("GET", window.location.href); oReq.addEventListener(xhr, "load", function() { if (xhr.status === 0 || xhr.status >= 200 && xhr.status < 300 || xhr.status === 304) { resolve(xhr); } else { reject(); } }); oReq.addEventListener(xhr, "error", function() { reject(); }); oReq.addEventListener(xhr, "timeout", function() { reject() }); xhr.send(); }); resetPagination.then(function() { instagram.init(); }, function() { // Error }); If I remember correctly, this kind of plain Javascript request doesn't actually register as an ajax request, so $config->ajax returns false, and the pagination will be reset. I'm not sure this is the best way to go though - I'd probably be trying to store the requested data in an array/object and then just pull it from there when the page changes e.g. var requests = {}, var items = []; // On page change var page = "page" + pageNum; // whereever you get this info from if(page in requests) { items = requests[page]; } else { items = "an AJAX request to get the next page of items"; requests[page] = items; } It will probably require a bit of reworking of your code, but it's a far better way to go. You shouldn't have to request the data more than once - store it! Hope that helps, Chris

Oh ok, I guess then it's an issue of simply cached install of the module? Actually I don't understand how this part works very well

Thank you so much, @MoritzLost, that worked - and I've learned again something...

Just as I was about to call it a night, here it is: $secureFile = $pages->get((int) $input->urlSegment1)->filesSecure->findOne("basename=$input->urlSegment2"); $options = array( 'forceDownload' => false ); if($secureFile) $secureFile->download($options); else throw new Wire404Exception();

Firstly, are you sure you need to modify the module for "style editing"? In case you haven't read already: https://processwire.com/docs/modules/guides/comments/ Secondly, if you do find you need to modify, I would consider upgrading to the very latest dev as there have been some major changes to the comments field and an important bug fix. Consider those before worrying about why the approach you are taking isn't working yet.

ProcessWire 3.0.157 on the development branch continues the trend of core refactoring that’s been happening quite a bit in 2020. Rather than doing a rewrite every few years (like some CMS projects) we instead refactor parts as we go, constantly improving and optimizing the core. This works because the core design/architecture is right where it needs to be, even 10 years in. But there’s always still bits of legacy code, and code that can be improved. So in the context of ProcessWire, refactoring means incrementally rewriting code on the inside, without changing its behavior on the outside (other than making it faster and/or more secure). This has been happening regularly over the last 10 years, and will likewise continue happening over the next 10 years and likely beyond. This week the code behind ProcessWire’s core Database and PageFinder classes got a major refactoring. This is some of the most used code in PW, as it handles everything involved in taking a selector and converting it to a database query. But it’s always been a little bit of a pain point for me because it had to build queries in a way that I thought wasn’t ideal, in order to make it possible for lots of different modular parts (mostly Fieldtype modules) to contribute to the query and for PageFinder to put it all together. It was fast and secure, but still one of those parts that felt like a little too much duct tape to me. But considering how crucial the code is, I’ve always been reluctant to make major changes, since it all worked just fine. Spending lots of years thinking about it (on and off), a desire to work out any pain points, and having better tools available (like Phpstorm and Tracy) made it possible to finally massage out this pain point. Some work still remains to be done, but it’s mostly there and I’m feeling good about it. Stuff like this is key for the maintenance and longevity of the core, and involved a lot of time and effort, but makes very little difference to users, even if it makes a lot of difference to me in maintaining the core. It would make a boring blog post for sure—lots of work and changes, but no new toys to show for it. Nevertheless, it has that feeling of a good house cleaning, even if you can't see it from the outside. The scope of changes here means that there may actually be new bugs to work out, so to be on the safe side, consider 3.0.157 to be a little more “beta” than the dev branches usually are. Though I’m running it here on processwire.com and it’s working well. Beyond the fairly major updates to the Database classes, there are also a few new Sanitizer convenience methods that are primarily variations on existing ones, but useful ones for sure. Thanks for reading and have a great weekend!

Adding some code to expand on my post above. In /site/ready.php: // Forgot password: add verification code as a URL parameter $wire->addHookBefore('ProcessForgotPassword::renderEmailBody', function(HookEvent $event) { $url = $event->arguments(0); $verification_code = urlencode($event->arguments(1)); $url .= "&code=$verification_code"; $event->arguments(0, $url); }); // Forgot password: pre-fill verify field from URL parameter $wire->addHookBefore('ProcessForgotPassword::renderForm', function(HookEvent $event) { $form = $event->arguments(0); $form_name = $event->arguments(1); if($form_name !== 'step3') return; $verify_field = $form->getChildByName('verify'); if(!$verify_field) return; $code = $event->wire('input')->get('code'); if(!$code) return; $verify_field->description = 'Please type or paste in the code you received in your email if it is not already shown below.'; $verify_field->value = urldecode($code); }); I just set this up on a site and it seems to be working well.

There isn't, because they are a one person, who is busy working hard on Padloper at the moment to make sure it's a great solution when it's ready to be released. And probably has other things going on, too. Estimated timescales have been mentioned a few times, but the thing with estimates is that they're not concrete dates, and nor should they be. I trust that what is being built is a great module. As it is a commercial offering, I also trust that the support will be there, if or when it is needed. I've also started the groundwork for a commerce project - I had planned to use Snipcart, but Padloper might be better - I won't know until it's released and I'm happy to wait until it is to make that choice.

This is my standard setup: FormBuilder FrontEndEditLightbox MarkupSimpleNavigation MarkupSitemapXML ProcessWireUpgrade TracyDebugger AdminOnSteroids ProFields Process Dashboard SeoMaestro

@ryan released a new version (1.0.8) of this module a few days ago. Thank you! It works perfectly fine as previous versions did - even with the most recent DEV version of ProcessWire. There are also some new features included. Grab your copy now from the modules directory or via the upgrade module. Have fun and stay safe!

Looks to me (untested) like you shouldn't have images.description but rather description only in your selector, since you're already operating on the images themselves, and images themselves have no template (you have already limited the parent page in your $pages->find call to that). $match->images->find("description~=$keywords"); should be enough.

Thanks for all your suggestions. Here is what I use right now in my ready.php $wire->addHookAfter('AdminTheme::getExtraMarkup', function (HookEvent $event) { $parts = $event->return; $parts['head'] .= '<link rel="stylesheet" href="' . $this->config->urls->templates . 'admin/admin.css">'; $parts['head'] .= '<script src="' . $this->config->urls->templates . 'admin/admin.js"></script>'; $event->return = $parts; }); I don't want to rely on another module like AoS or AdminCustomFiles, because I think adding another module just to add styles and JavaScript is overkill and bloat. Instead I want to add the assets in my own modules, or in ready.php. I still think that it would be good in the core, and the core could still be lean. There are already methods there to prepend or append assets, but they don't work correctly because of the init order. Mainly the problem is that core modules should be loaded first with their assets like jQuery and CSS, etc, and then I should be able to add my assets after them to override them. I know it might be a specific case, where you want to alter default behavior and styles of the admin, but it is something I often need. In most cases the actual behaviour $config->styles->add($config->urls->templates . "admin/admin.css"); is just fine, if you are not trying to override some styles

Yet another solution: use AdminOnSteroids See the bottom of this screenshot: https://camo.githubusercontent.com/4adc7e92ce6a8323b0d29dcd8b888a48e7eb3820/68747470733a2f2f726f6c616e64746f74682e68752f7069632f616f732f616f733136342e706e67

I use the following method with success, in your module: public function init() { // add a hook after each page is rendered and modify the output $this->addHookAfter('Page::render', $this, 'page_after_render'); } public function page_after_render($event) { /** @var Page $page */ $page = $event->object; if( $page->template =='admin' ){ $head_include ='<link rel="stylesheet" type="text/css" href="PATH/TO/YOUR/CSS" /> '; $replace = array( '</head>' => $head_include .'</head>' ); $event->return = str_replace( array_keys( $replace ), array_values( $replace ), $event->return ); } } Pretty simple and $replace array can be extended as needed.

Is there a field datefield named "date" in that page? If not you either need to create it or use one of these, depending on your usecase: "created" or "modified".