Leaderboard

Here's my version: <?php // Cache all topics $template = $templates->get("topics"); $topics_children = $cache->get("all_topics", $template, function($pages) { return $pages->get("/topics/")->children(); }); //Topic1|Topic2 $search_topics = explode("|", $input->whitelist->topic); //Get Topics from cache foreach($topics_children as $topic) { $checked = (is_array($search_topics) && in_array($topic->title, $search_topics)) ? ' checked ' : ''; echo "<label for='{$topic->title}'><input type='checkbox' name='topic[]' $checked value='{$topic->title}' id='{$topic->title}' /> {$topic->title}</label></br>"; } //On my search template if($input->get('topic')) { $value = $sanitizer->selectorValue($input->get('topic')); $selector .= "topics=$value, "; $input->whitelist('topic', $value); } ?>

Alerting the user when their session expires is one of the features of pro UserActivity module.

In the blog post last week we looked at some of the two-factor authentication system upgrades, like the new “remember this computer” feature. This week I finished off the remaining parts, as well as released new versions of both the TfaTotp and TfaEmail modules. Auto-enable TFA support We now have auto-enable support (forced 2FA), which lets you setup two-factor authentication for users, without their input (if they haven’t enabled it already). This is a good way to add a lot of security for very little work. Currently, the module that supports this is the TfaEmail module. That’s because it’s a safe bet to assume the user has access to their email, even if they haven’t specifically setup 2FA. So email is a very good way to nudge people into 2FA, and people are already used to this, as many online services now do it. Considering that the computer can now be remembered, I think it’s unlikely you’ll get any complaints from users. Setting up auto-enable is really simple. Grab the latest version of the TfaEmail module and install it. Then go to your ProcessLogin module settings (Modules > Configure > ProcessLogin) and you’ll see an option there to select Email in the “Force two-factor authentication - Type” field. If you want to limit this to specific roles, then you can also do that here. If you don’t select any roles, then it applies to all roles. Once setup, any user logging into your admin will be asked to enter an authentication code sent to their email, and they’ll need that code to complete the login. Chances are they’ll also click that “remember this computer” checkbox so that they can skip the code on future logins. TfaEmail version 2 The new version of the TfaEmail module also lets you now configure what WireMail module you want it to use for sending authentication emails. If using multiple mail sending services, you’ll want your most reliable and fastest email sending service to handle these kinds of transactional emails. TfaTotp version 4 Once users understand the benefits of 2FA, chances are they’ll want to upgrade to TOTP, where they can use a dedicated authenticator app. The ProcessWire TfaTotp module got several upgrades this week. The biggest was the addition of a locally hosted QR code generator (QRCode for PHP by Kazuhiko Arase). No longer does it have to rely upon an external service to generate QR codes (previous versions used Google Charts for QR code generation). In addition, the TOTP TwoFactorAuth library has been updated to the latest version. Moving those modules to the core Speaking of those two modules (TfaEmail and TfaTotp), thanks for your input last week about their inclusion in the core. It sounds like most think it’s a good idea, so I think we’ll go that route. But I need a little more time to do that, so going to hold that update and the 3.0.160 version bump for next week. Coming next week: Useful new selector operators Next week I’ve also got a couple of special new text-matching operators being added to our selectors system that I think you are going to really like. They are operators that are especially useful to those building text search engines, and ones that I’ve found so useful this week that I wish we’d had them since the beginning. I’m excited to add those into 3.0.160 and tell you more about them next week. By the way, while 3.0.160 isn't officially the version on the dev branch yet, if you download the current dev branch version (3.0.159), all of the TFA updates mentioned above are present and ready to use.

I tried out the new $datetime->elapsedTimeStr() method, and found something strange... // https://processwire.com/blog/posts/pw-3.0.130/#new-datetime-gt-elapsedtimestr-method // https://processwire.com/api/ref/wire-date-time/elapsed-time-str/ $p = $pages->get(11297); $p->of(false); $start = $p->proj_timespan_from; $end = $p->proj_timespan_to; //echo "$start / $end <br>"; // unixtime $duration = $datetime->elapsedTimeStr($start, $end, true, $options = array("exclude" => ['seconds', 'minutes', 'hours', 'days'])); echo $duration; // shows: 161 weeks. Months and years are not shown :-( $duration shows: 161 weeks. Months and years are not shown / calculated. Is that by design? I would expect that if the $duration is over a year, it would show x years, y months, z weeks, with my excluded options...

@Kola - glad you figured it all out ? The key thing here is that it's not really the ASMSelect inputfield, but rather the Page Reference fieldtype that's behind it - because you have that set to store multiple values you need to use the add() method. Same would go for checkboxes etc.

Because I tend to be a silly billy often times ?. It's happening because RM is not letting its parent class know that it is handling the processing of its WireInputData Yes, it is. I'll make the changes in the repo eventually, but meanwhile....please open up InputfieldRuntimeMarkup.module for editing. Scroll down to the end of the file. Find the method ___processInput() and un-comment it. The method's body is intentionally blank, so no changes needed there. Save :-). That should do it.

Thanks Sergio, you've saved my day!

And this particular post it's the key to success ? Here's the solution: if ($input->get->forme_options) { $san_array = array(); foreach ($input->get->forme_options as $forma) { $san = $sanitizer->selectorValue($forma); $san_array[] = $san; $selector .= "forma_prodotto.title=$san, "; } $input->whitelist('forme_options', $san_array); } My Lord, that was hard! (at least for me :)). Thanks!

My bad, I misread it. Maybe this will help you:

Hi Kongondo, first of all many thanks for this useful module! My question is about the behaviour of RM fields on save. Usually, we fill the RM fields with some static html markup. After saving pages with RM fields, these fields always are anounced as "changed", but why? Is is possible to prevent this? Best regards, Thomas.

I think you can still store HTML in Editor.js. So I wonder if it might be feasible to add a new editor field alongside CKeditor ones then use a hook to copy the content over on page save... or something like that anyway!... I'll be looking to address the same issue if this module works out.

There was one problem, that the Hook was sometimes executed before the entry was saved to the database. So the blurhash query did not found the entry. And the second problem was an encoding issue with some characters int he blurhash. Strange... this undefinded offset did never happen in my side. But I will check if $calcHeight and $calcWidth works on my side and will change this in the repo

Another +1, this would be my default editor as there are so many issues with CKE. I was even contemplating moving to builtin markdown editor, but would be difficult to convince the clients. This would be great for new websites, but what about the existing sites poluted with CKE's html tags? I guess it would be tricky just to update the existing text/body field to a new type due to html vs json?

For a brief moment I was contemplating parsing HTML with regex but then StackOverflow taught me this: https://stackoverflow.com/a/1732454/1036672 My sides are now hurting ?

Hi Dean, Hopefully you've already found the answer, but you need to also visit Modules > Configure > LoginRegister and add those new user fields to "Registration form fields" so they display during registration.

Seems that things changed slightly ? This worked for me today: Translate file /wire/modules/Inputfield/InputfieldDatetime/types/InputfieldDatetimeText.php Set path: /wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js Search keys: datetime, date picker, monday, translate, sunday, german

We recently launched The Power Supply Shop, an e-commerce store built using a combination of ProcessWire and SnipCart. The site has in excess of 120,000 products and variations, making heavy use of page references as well as SnipCart's "any page can be a product" approach. The site pulls in its data from an external MS SQL database several times a day. At a glance, the site uses: ProCache - as well as WireCache for some heavy product listing pages (50k+) FormBuilder @adrian's Tracy Debugger A modified version of @Soma's Ajax Search @mtwebit's fantastic Tasker and DataSet modules. And that's about it on the module front. For other libraries we're only really using FancyBox.js for product galleries and Anchorific.js for guide pages. At present the site is geared towards the UK, but if and when this changes I'm looking forward to delving into multi-languages with ProcessWire, something I haven't really worked with yet!

Looks great! Love the design! Nice to see a webshop where some effort has obviously been put into making a custom design ?

This is not yet implemented, sorry. But it’s on my list and it will be the next feature to be added. @LostKobrakai @fruid Sorry for my stupidity, this is already implemented in a rudimentary way. You need to add the preinstalled field snipcart_item_custom_fields to your products template. This is a textarea where you can add custom configuration options for your product by using the data-item-custom*-* syntax described here: https://docs.snipcart.com/v2/configuration/custom-fields#product-custom-fields Sample code: data-item-custom1-name="Print label" data-item-custom1-required="true" data-item-custom2-name="Size" data-item-custom2-options="Small|Medium|Large" data-item-custom2-value="Medium" data-item-custom3-name="Gift" data-item-custom3-options="true|false" As I said - this is a rudimentary way to add options to your products. As this method only allows to select/change product options after they are added to the cart, I need to find a reliable way to generate those data-item-custom*-* tags from regular ProcessWire fields so they can be selected directly on the product detail page.

Try this... $wire->addHookBefore('ProcessPageAdd::execute', function(HookEvent $event) { // Get the id of the parent page the new page is being added under $parent_id = $event->input->get->int('parent_id'); // Return early if not the id of the parent page you want to target if($parent_id !== 1234) return; // The following line probably not strictly necessary because we will redirect in a moment anyway $event->replace = true; // Create the page $p = $event->pages->add('your-template-name', $parent_id, 'your-page-name'); // Make the page unpublished to begin with $p->addStatus(Page::statusUnpublished); // Save the unpublished status $p->save(); // Redirect to edit the page just created $event->session->redirect($p->editUrl); });

Just add another option to the selector, where you check for cases, where the start is before the searched date and the end is after the searched date. $selector = ""; // Start date inside $selector .= ", range=("; $selector .= "datefrom>=".$input->whitelist("datefrom"); $selector .= ", datefrom<=".$input->whitelist("dateto"); $selector .= ")"; // End date inside $selector .= ", range=("; $selector .= "dateto>=".$input->whitelist("datefrom"); $selector .= ", dateto<=".$input->whitelist("dateto"); $selector .= ")"; // range overspans searchrange $selector .= ", range=("; $selector .= "dateto>=".$input->whitelist("dateto"); $selector .= ", datefrom<=".$input->whitelist("datefrom"); $selector .= ")";