Leaderboard

--- Please use RockFinder3 ---

I am back again with another crazy module that might help someone. This time I am using the native Tfa class to add FIDO/U2F support. this includes Yubikeys ? Sadly I cant seem to find a way to do multiple keys at once. and it seems you can only have one Tfa method at a time so not ideal but it was a fun challenge to code and maybe someone will a use for it Github: https://github.com/adamxp12/Processwire-TfaU2F ProcessWire Modules: https://modules.processwire.com/modules/tfa-u2-f/ The code is not the neatest and has limited comments but if you understand the Tfa class it should be quite easy to break apart. And here is a demo of signing in using the Yubikey as the 2nd factor

Memorizing classes will always be needed. If you take a pre-build framework or your own classes. The big productivity improvement is not in writing CSS using @apply and tailwind classes, but in writing just html and adding tailwind classes directly to the markup. So you need the backing css to already exist. Once you have to switch to a css file you're already loosing on the productivity gains. If you're using properly separated templates there might even be no need to later move the utilities to custom classes and `@apply` as everything's already in one place - the template of a component. Having the utilities out of the box is exactly the selling point of tailwind. Sass/less don't give you classes you can put in your markup - they're pre-processors. It also doesn't want to be a contender to e.g. uikit or bootstrap because they require so much work to be bent to custom design. Building your own components is expected, as custom design most often does require that anyways. There's however some work on a component library being done, which is build on top of tailwinds utility classes; and which will probably be easier to customize than e.g. bootstrap. If you have your own custom utilities library tailwind probably won't be of much benefit. If not however it' a great way to get started quickly on a existing, well documented, well adopted framework. Tailwind by default comes with 9 shades of each color, where afaik 4 are accessable colors on black and 5 are accessable on white background. And you can still edit them, those are just defaults. The message is not "you should not use more than (those) x colors/shades". The message is that a well managed design system must use a fixed set of colors, which is different to each person on the team just adding a new shade each and every time they add something to their codebase. The latter most often being the reason for the exploding number in color or text-size variations. It's about consistency and less about absolute numbers. Imho the need for all those customization variables of frameworks like uikit/bootstrap and the lock-in to a certain preprocessor already show how "inflexible" those solutions really are. I've not yet used any of those frameworks, where I didn't hit a brick wall at some point trying to skin a component to a custom design, because some aspect of a component wasn't customizable (either markup expectations or missing a "configuration variable"). To me tailwind css is neither an alternative to writing css, as the building blocks are way more cohesive and well rounded as well as "higher level" than css 1 – but also not for frameworks, which often impose quite an amount of markup constraints and understandably a certain kind of style, which can be problematic when implementing a custom design. [1] Take for example .truncate. There's no single css rule for truncating text properly. It's overflow: hidden; text-overflow: ellipsis; white-space: nowrap Same for e.g. .rounded-t. It applied rounded borders to both top edges, instead of css, which requires you to set it for each edge explicitly. This is more in line in how a designer would think about a design than how css needs it to be implemented. Nobody will say "make the top left and top right edge rounded". People say "make the top edges round" or "truncate that line".

$page->template->altFilename; $page->template->filename;

A couple of hooks for /site/ready.php: $wire->addHookAfter('ProcessPageEdit::buildFormContent', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->return; // Maybe return early if page does not use a particular template /* @var ProcessPageEdit $ppe */ $ppe = $event->object; /* @var Page $page */ $page = $ppe->getPage(); if($page->template != 'basic_page') return; // Add checkbox field /* @var InputfieldCheckbox $f */ $f = $event->wire('modules')->InputfieldCheckbox; $f->name = 'notify'; $f->label = 'Notify users about changes'; $form->add($f); }); $wire->addHookAfter('ProcessPageEdit::processInput', function(HookEvent $event) { /* @var InputfieldWrapper $form */ $form = $event->arguments(0); // We only care about the top-level form $level = $event->arguments(1); if($level) return; // Get the notify field $notify = $form->getChildByName('notify'); // Return early if notify field doesn't exist or isn't checked if(!$notify || !$notify->value) return; // Now send the email notification... // Your code here });

https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ After reading this article highlighting the utility-first approach, a couple of things popped into my mind: This utility-first approach is mainly for large frameworks and/or for pre-made high-level component libraries where spending the time on all the extra work this approach introduces is worth it. For the frontend of brochure sites and even for classic retail webshops strictly sticking to this approach can be overkill and limiting in terms of "custom design", even though it is supposed to be able to deliver some sort of freedom in customization. If there is only one or two developers working on a not so big website, the advantages of this atomic utility-first approach fade away. My issues with this atomic style utility-first approach: - Memorizing the classes takes a lot of time as one has to learn a brand new language, translating a lot, eg: .flex-no-wrap means flex-wrap: nowrap; .flex-wrap-reverse means flex-wrap: wrap-reverse; .min-h-full means min-height: 100%; .min-h-screen means min-height: 100vh; And the list goes on... One has to spend quite a lot of time using the library in order to learn all this mapping. - Even though the CSS library is there, one has to start from scratch in terms of implementing "building blocks"/"components" for the site. Not having pre-made high-level components means that there is no help in this regard, it's very much like building the frontend based on SASS/LESS only (except for the utilities out-of-the-box, of course, but still...) - The approach of limiting text sizes, colors and similar to a few can be limiting for custom frontend design. By only using statistics to judge a particular design is short-sighted, I think. The Author lists some stats on popular massive sites out there, listing data like: Stripe: 189 text colors, 90 background colors, 35 font sizes purely based on some simple counting of the number of property values being used. By not knowing why those colors are used, stats do not mean too much, see for example: https://stripe.com/blog/connect-front-end-experience Being armed with some experience in working with colors one knows that – for example – bright text on dark background looks thinner than dark text on bright background and for this reason the trick of making bright text on dark background just a tiny bit brighter than its counterpart on bright background can be used to make text more readable. Also, properly matching colors is not always possible by picking colors form a small color palette, as our brain can observe them differently depending on the context. I understand that using hundreds of colors is most probably unnecessary, but relying on a fixed number of a few dozen can be limiting at times. The Author also states: "I don't think you should build things out of utilities only." and I agree ? For small and mid-range frontend projects I think UIkit 3 is a better choice as it provides high-level components based on low-level ones which can be mixed in lots of clever ways. I usually add the BEM-like approach to my code too, so that any deviation from the otherwise LESS customized UIkit can be applied in a maintainable manner.

@thetuningspoon mind testing with attached PagerNav.php? Possibly not perfect, but it's not clear to me how pagination should be presented on edge cases... PagerNav.php

Here is my first processwire module (beta). https://github.com/theo222/ImagePickerField A lot of "first times". First time Github, Markdown and of course PW Modules. So be gentle please. I hope it works.

Yes that would be ideal. I could also just save JSON into a string field to lower the dependencies on other modules. I had not thought about doing this actually Food for thought... I will experiment tomorrow I think. I wanted to get a proof of concept working to start with as I had coded a ton of it then realised the settings get locked out once you enable Tfa and then found out that only the Tfa_code field is sent to the validate function. had to get creative with some session variables to get it working but now it works somewhat I feel like I can improve/expand

This is most likely because the module is still waiting for approval ?

Yes! Fantastic! This module is currently top of my list of modules to develop for Processwire - thanks so much for doing it for us! Will test with Yubikeys as soon as possible, and shorten my to-do list.

You can get UIKit purged down to ~25 - 40KB.

I did not see an option to submit to the Tfa module category @ryan Not sure if you want to manually add it into there?

Thanks @Robin S ! I won't add useless Checkboxes anymore to my templates! :D

Some more info on what I am talking about: https://github.com/Imagick/imagick#openmp https://stackoverflow.com/questions/8413868/imagemagick-thumbnailimage-maximum-execution-time-of-30-seconds-exceeded http://www.daniloaz.com/en/high-cpu-load-when-converting-images-with-imagemagick/ https://www.imagemagick.org/discourse-server/viewtopic.php?t=16453&start=15#p71389 It is interesting because the maintainer of php Imagick suggests images shouldn't even be processed inside a webserver due to these threading issues: https://github.com/Imagick/imagick/issues/263 The only thing that has worked for me so far in my setup (Homebrew installed imagemagick and pecl installed imagick) is adding: \Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1); to my site config.

Hey @ryan just hit this again and done some more research, from what I can tell there are longstanding problems on mac with the combination of apache threads, imagemagick, and the parallelization library openmp that magick uses. I am fairly certain installing imagemagick with the flag --disable-openmp should fix things. My problem is that in my setup imagemagick is installed via Homebrew and since it is a core formula I can't provide options on install anymore. I don't want to deal with installing a binary etc, this is pretty frustating since now I might need to create and maintain a tap of imagemagick with openmp disabled just to fix this.

as discussed yesterday this wasn't the last Wireabend-Bier (perfect wording @marcus!) in Berlin. I am looking forward to meet more of you in the future with another beer ?

I don't know yet. I've had a glance at firebase for maybe 3 minutes. From what I've seen documents have several fields just like pw pages have several fields. Only difference is that pw has a defined set of fields (defined in templates) whereas firebase documents can hold any kind of key-value-pairs. That's what makes firebase complicated to use (what they told me - maybe there are already ways to handle this better and they/we just don't know about it yet). I guess this would be firebase because they integrate everything with it (mobile app, other services etc). But I thought of even not storing data in PW at all. The more I do in the backend the more I'm using ProcessModules for many things. I think it should be quite easy to write an own process module that just provides an interface for the input (several fields) that sends that data to firebase on submit (via processInput, error handling built in).

What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead. The general rule of thumb is to always sanitize user input ? That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.

From past experience working with lat/lng coordinates, I suggest using a decimal field for these. Float fields only have a precision of 6 figures which is often not sufficient for a lat/lng value.

I think RobinS is doing something similar to your project. You may want to read how he is going about it.

Here's a little text formatter module that redirects all external links found in a textarea (e.g. for hit counting) to a given URL. TextformatterExternalRedirect GitHub repo As TextFormatters do, this module modifies the contents of the textarea (HTML) at rendering time. It prepends the given URL to the link address for external links (http and https), optionally makes sure that the link is opened in a new window and allows you to add css classes to such links. All options can be configured in the module's configuration settings. Usage: Download the zip archive and extract it to site/modules, the rename the top folder to TextformatterExternalRedirect Go to the backend and select "Modules" -> "Refresh", then click "Install" for "External Link Redirect" Click "Settings" and configure the module Go into the field configuration for the field(s) you want this formatter to apply to and add it from the dropdown Done, now any external links in the configured fields will have the configured settings applied Feel free to leave feedback and post and questions you have here.

Something that I found useful recently... Users can type a date/time directly into a Datetime field, which can often be faster than using the separate controls in the datetime picker. But the problem is that there's nothing built into the Datetime inputfield to let users know what the expected input format is for the date/time. You could enter the input format in the description or notes for the field, but you'd have to do this separately for every Datetime field and remember to update it if the input format changes for any reason. Instead, you can use a hook to automatically show the current input format in the notes for all Datetime fields: $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->notes = 'Input format: ' . date($datetime_input_format, $ts); }); Or as the title tooltip if you prefer (you have to add the title to wrapper because a title on the input itself gets wiped out by the JS datepicker): $wire->addHookBefore('InputfieldDatetime::render', function(HookEvent $event) { /* @var InputfieldDatetime $inputfield */ $inputfield = $event->object; $datetime_input_format = $inputfield->dateInputFormat; if($inputfield->timeInputFormat) $datetime_input_format .= ' ' . $inputfield->timeInputFormat; $ts = strtotime('2016-04-08 5:10:02 PM'); $inputfield->wrapAttr('title', 'Input format: ' . date($datetime_input_format, $ts)); });

You can set more advanced labels in a Page Reference field by using a hook. Not sure if there's a better way but here's how I do it. In your Page Reference field settings, choose "Custom format" for the "Label field" setting, and in the "Custom page label format" enter anything you want so long as it is unique to that field, e.g. pwrocks Then in /site/ready.php $wire->addHookAfter('Page::getMarkup', function(HookEvent $event) { $page = $event->object; // Each page that appears in the Page Reference field $key = $event->arguments(0); if($key !== 'pwrocks') return; // the label format specified for the Page Reference field // Now build whatever string you want to show using $page, $page->getForPage(), etc $string = 'Your string here'; $event->return = $string; });

In addition to @MindFull: you will find the css for the ckeditor here: wire/modules/Inputfield/InputfieldCKEditor/contents.css. Find the css for .figure and change to this: figure { display: table; /*width: 1px;*/ margin: 1em 0; } if css for .img is only to width: 100% change to: img { max-width: 100%; } change the css for the .figure.align-center as follows: img.align_center, img.align-center, figure.align_center, figure.align-center { /* RCD display: block; */ display: table !important; margin-left: auto; margin-right: auto; } Now you can see in ckEditor image and capturetext (checked title) in the middle. For fontend you must add in your css: img.align_center, img.align-center, figure.align_center, figure.align-center { float: unset !important; display: table !important; margin-left: auto; margin-right: auto; margin-bottom: 10px; } In most cases, the definition of position left and right is wrong in the frontend, so copy the css for all the "alligns" from content.css to your style. best regards

Hi everyone, I made a walkthrough of a web app I built using ProcessWire for the Tenova Group mining company. They needed an intranet application to keep track of their daily plant operations. I designed and developed a ProcessWire solution that would allow registered employees at Tenova HYL to record events regularly in an event log. Storing all of the events in this manner would allow registered users to find the events they're looking for using keyword search, date filters as well as filters based on other criteria. Each event also allows the user to upload supporting files for download, such as Word documents and PDFs, as well as upload relevant images to be displayed in a modal window. A high-performing, powerful solution using the ProcessWire CMS. Read about the project here in my portfolio. See the video here: Tina Holly tinaciousdesign.com