Leaderboard

Hope you guys are having a great week. I'll keep this week's update short since everything I'm working on is in-progress rather than ready to post. But I can tell you about a few things you'll likely see in next week's post: First is that I've got multi-page/paginated form support just about ready to release in FormBuilder. What this means is that you can take forms (especially long forms) and break them up into multiple paginations. This makes for multi-part forms that are more digestible and easy to use for users. The end of each pagination has "Next" and "Prev" buttons for navigation between them. FormBuilder validates each pagination independently as it is submitted so that any errors are taken care of as the user proceeds rather than all at the end. And these are true paginated forms, rather than a JS manipulation of existing forms. More on this next week. I'm also working here on a new Inputfield module called InputfieldToggle. It's an alternative to the core InputfieldCheckbox and the intention here is to make it a selectable alternative for FieldtypeCheckbox fields. Unlike InputfieldCheckbox, it is presented as two radio buttons for "on" and "off" states. (It's also possible to have a "no selection" state distinct from the "no" state, where supported). It comes predefined with several toggle types (Yes/No, On/Off, True/False, Enabled/Disabled), along with the ability to specify your own (multi-language too of course). Like a checkbox, because it is a toggle, it holds a value of either true (1) or false (0). There is also null for no selection. While this is a relatively simple Inputfield, it answers a common need (at least in my experience) and often can provide a better experience than a standard checkbox, depending on the input need. Not to mention, it's a lot more efficient than using an Options or Page field to accomplish the same thing. In addition to sites and apps running in ProcessWire, I think this particular Inputfield has a lot of potential use in the core and its administrative forms, so I might include it in the core, though not yet certain. I'm already using it quite a bit in forms I'm developing for clients in FormBuilder, where in many cases I find it a better fit than InputfieldCheckbox. Lastly, there are some nice UI enhancements just about ready for manipulating column widths of fields in ProcessWire. It makes it a much simpler and quicker job than it currently is, so I'll have more on that next week too. Have a great weekend!

Please do – the core would definitely benefit from this ?

To complement what @teppo said, here's a post by Adam Wathan, one of the creators of Tailwind CSS, that made me want to test the framework. I was skeptical at first but after I built my first project using it, I was hooked. https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

Tailwind is utility-first framework. The key difference between something like Uikit and Tailwind is that latter has none of the typical CSS framework components built-in. For an example, here's an example from the docs for creating a "button component": <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"> Button </button> Colors and sizes (such as the "2" in "py-2" etc.) are configurable, so you can have as many or as few of them as you want, and the names can pretty much be whatever you want them to be (py-thon). Either way you're always building your UI using really simple (the word "atomic" comes to mind) rules. While Uikit has some similar utility classes (and so does Bootstrap), Tailwind has a massive number of them, even without counting the pseudo states (bg-blue hover:bg-blue-dark), responsive classes (p-6 md:p-8 lg:p-10), etc. You can still create your own "custom" components, so that when you add some class – such as "btn" – to an element, you actually get the same thing you would with the rules in the example above. Typically this is done by defining the class in SCSS: .btn { @apply font-bold py-2 px-4 rounded bg-blue-500 text-white; } .btn:hover { @apply bg-blue-700; } Technically that this is something you should only do if you really have to repeat the same string of classes multiple times, though ? Personally one thing I've always struggled with "traditional" CSS frameworks are the components they come with. While they often look quite nice, I've almost never had the chance to actually use them as-is (either there's a predefined PSD layout or something like that, or the client demands changes, or the component is just plain bad) and thus I've basically ended up designing my own component library on top of the one provided by the framework. In most of my projects I've only used a framework like Foundation for the grid implementation. That's where Tailwind comes in: you can build exactly the components you need, BUT you still get certain benefits of a framework, such as globally defined fonts, colours, spacings, etc. I've struggled with this a bit, and I have to agree that to me personally the utility class approach often looks really ugly, and the shortcut class names etc. are hard to decipher. I'm not yet at the point where I can just glance over an element and instantly see what it is or how it's styled. That being said, I don't really think that this is a major issue for most projects: the size of your HTML is unlikely to become a real bottleneck. ... and if it does, you can always use the extracting components approach mentioned above. Use Tailwind for prototyping, and then convert the combinations you use often to custom components (or custom utility classes) ?

I wouldn't call it a manifesto but anyway... let's talk about my workflow. TL;DR I build 90% from scratch. Every time. Each and every project. I don't use frameworks of any flavour.* * except from some JS stuff - see below Long version My boilerplate for new projects: SCSS Skeleton (my personal collection of SCSS Magic) JS Skeleton (my personal collection of JS Magic) HTML/Kit files depending on templates and elements the project needs (inspired by http://bradfrost.com/blog/post/atomic-web-design/) just an empty folder would work totally fine as well Tools I use and need: git Prepros/CodeKit (or ProCache ?) Tools that may be added later (if absolutely necessary): Lazysizes SVGinline jQuery for Slider scripts (slick, OwlCarousel) MixItUp Tools I never use (because I'm too old for that - I guess) Grunt, Gulp, Bower, Webpack, Parcel, ... you get the idea Benefits Projects are portable Projects run everywhere Every part of project can be changed without affecting other things (most of the time) No need for a special setup (at least for the compiled files) Small(est) file sizes and therefore fast websites (in most cases) Downsides Working with others means I have to trust them and their capability to write good CSS/SCSS You have to think at least twice for each step, every time It takes much more time to build everything from scratch It's much more expensive at first Clients often don't understand the benefits and sometimes WANT a Bootstrap website ? FAQ What if you work with others? As mentioned before I have to trust others that they are capable of writing good CSS/SCSS and therefore I tend to work only with very good people I really trust. Is it worth it? Yes! Why? When stuff breaks or needs to be changed, I know where to look, what to change and can do my stuff without the need to take care of any version upgrades, incompatibilities in or with newer version, I don't need a special setup or whatever. AND... if I want to I can still add whatever is needed. Try it the other way around. That's much harder. Are there exceptions? Of course. Backend stuff, admin interfaces and things like - ProcessWire admin is the perfect example. I wouldn't build something like that from scratch. I guess that's my manifesto.

I'm not really sure if this will lead you to something or nothing, but have you tried using a compatible jquery version in the FE? The PW BE uses jquery 1.11.1 with a migrate version 1.2.1 but in my testing jquery ver 2.2.4 worked too. It works for me using something like the following: echo "<div edit='",$input->get->id,".images' >","<a>dbl-click to edit</a></div>"; $scripts = "<script type='text/javascript'>" . "$(document).on('pw-modal-closed', '.pw-edit-modal', function() {" . "var saveButton = document.getElementById('button_save');" . "saveButton.click();" . "});" . "</script>"; $jquery_version = "2.2.4"; Then in my main template I add that jquery variable because for regular FE pages, I use another jquery version. <script>window.jQuery || document.write('<script src="<?php echo $config->urls->skin, "js/jquery-{$jquery_version}.min.js"; ?>"><\/script>')</script>

Wow, just found their resources page ? Might be worth a look for someone else too: https://tailwindcss.com/resources

@bernhard Making it hookable should be fine. But I'd like to better understand what you mean about it not working in the admin, and the url and filename methods never getting called? Are you using the core files/images field? Those methods/properties are the ones used for anything asking for the filename or url of a file, whether on the front-end or in the admin. For me at least, it works the same in the admin/page editor as it does on the front-end, just tested again to confirm—editing a page downloads the images, and they appear in the images field in the page editor. So I'm not sure I understand what you mean? Also, hooking setFilename() would make it less on-demand, as it would download any images in the field rather than only those that were specifically requested. Can you think of anything different about your environment that might account for it not working?

Additional side note: It seems my post confused a few of us. Therefore a few more details about my workflow. Clarification The above mentioned workflow does not involve ProcessWire. This workflow applies only to the part of creating HTML, CSS and JS for a project in its static version. You can call it a prototype, a template library, a loose collection of web-related documents, or however. This step is done way before I fire up ProcessWire (or give the files to another developer in case of Typo3, the CMS we don't name here or whatever). Each time I start a new client project for a website I already have in some kind a full-featured, defined and approved design - either made in Adobe PS, IS, XD, Sketch, Figma or any tool you can imagine - most of the time it's not my part to be honest. I can then work out each and every detail, plan out the things that were needed, look for repetitive elements and their modifications and states. The result of that (my work) needs to get an approval by the designer and the client - afterwards I create a new ProcessWire instance and migrate everything in template files and smaller bits I will need later on. With this overall approach I have had enough time to know how to structure the data and content in ProcessWire which makes things in it super easy and super fast most of the time. Hope this helps.

What the f*ck JavaScript? A list of funny and tricky JavaScript examples Some really odd stuff there... worth scanning through. I chuckled more than once... "b" + "a" + +"a" + "a"; // -> 'baNaNa' NaN === NaN; // -> false (![] + [])[+[]] + (![] + [])[+!+[]] + ([![]] + [][[]])[+!+[] + [+[]]] + (![] + [])[!+[] + !+[]]; // -> 'fail' typeof NaN; // -> 'number' (It ain't new, so sorry if this has been posted previously here)

OMG, my dream come true! ???I will use for sure multi form pages! And I will be able remove pages used for a simple yes/no! Thanks so so so much!

it's probably because add() just adds, it doesn't save().

+1 ?

After digging through several PW forum threads, I think the following approach might work: Create each of the 200 pages via API as the user it will be later assigned to (or create as superuser, and later change the owner) Install this module

Paginated forms: Looking > Forward > To > This > Alot. Thank-you!

No problem! When I have some time here I'm planning to build a site profile using Tailwind CSS so more people can see how it can be integrated with PW. Using both the CDN version, which gzipped is around 60kb and using brotli compression goes down to less than 20kb and the webpack installation I mentioned. :)