Leaderboard

After a previous request for Webp support (6 years ago, times flies…) that Horst and Ryan kindly introduced in PW 3.0.132, I'm back with another request for a new image file format, AVIF, which has landed in almost all browsers. I'm actually surprised no one here in the PW community has been asking for AVIF support in ProcessWire as it seems to be provide much more consistent gains in compression and greater relative quality over Webp, and of course over good old JPEG. My experience using it definitely confirms this. I've been using Cloudinary to serve AVIF images to the browsers that support it, but of course I'd rather not use a third-party service, and use it natively in ProcessWire. Imagemagick supports AVIF if I'm not mistaken. Anyone else is interested?

This week I've been working on something a little different: developing a new site profile in ProcessWire. Actually, I should probably call it an application profile rather than a site profile, as it's not a website profile. Instead it's a profile for an invoicing application in ProcessWire. Though you would install and run it on a web server, but it would be an independent application rather than part of a website... perhaps something you run in a subdirectory, subdomain, or even localhost. This is something I've been wanting to build for awhile—ever since the invoice service I use raised their rates beyond my budget. So I thought I'd build a replacement that I could use, as well as share for others that might have a similar need. I think it might also be a pretty decent PW profile example in general, too. I'd originally considered building it as a Process module but decided not to for a few reasons. Though the biggest one is that a site profile enables the greatest potential for customization and expansion according to each person's needs. Since you can expand upon it by adding your own fields and templates, or editing existing ones, most can really tailor it to their own needs a lot more easily than they could if it were a Process module. Likewise, since the actual invoices (and invoice emails) are rendered from front-end pages, you can customize the look and feel of them to match your brand very easily. (This is something I always wished I could do with the invoice service I've been using previously) This invoice profile requires nothing other than the ProcessWire core. It has no 3rd party or Pro module dependencies. I've got it largely functional at this stage, though will be putting a couple more weeks work into it before releasing it. I'd like to build in the option for clients to pay an invoice with a credit card (via Stripe) for instance. Below are a few screenshots of the work in progress. First is the page-list which shows the current invoices in the system and their status. (click image to view larger) As you can see, there are also pages for Clients and Settings. The client pages contain all the information about each client that invoices can be created for. The Settings page is where you can edit your own company information, logo and billing preferences. Next is the invoice editor. Here we have a repeater for each line item in the invoice. We also have a repeater for payments. All of the totals add up automatically as you type (Javascript added via hooks). They are also calculated automatically at the server side, so that everything stays consistent whether working with the API or in the page editor. (click image to view larger) At the bottom of the invoice editor you'll see a collapsed input for "Invoice action". This is where you can select actions to apply to the invoice. The two we currently have are "Email invoice to client" and "Email invoice to another address". Next up is what we see when viewing the invoice on the front-end. This is just the output of a template file but it is optimized for printing, saving to PDF and sending through email. I've kept it intentionally simple but of course the logo would be replaced with your own and all markup/styles are fully under your control. (click image to view larger) What I plan to add next are payment options, enabling a client to pay by credit card right from the invoice URL or email. What do you think, is this type of PW profile useful to you or someone you know? I've initially built it towards my own client invoicing needs, but I'm curious what other features you would like it to have? Or do you think it's better to keep it simple so that people can more easily take it in different directions? Thanks for your feedback. Have a great weekend!

In Test A your PHP Social Stream code is loading it's own copy of jQuery. At about line 974 you have: <!-- PHP Social Stream By Axent Media --> <link href="https://www.ncoinc.org/site/templates/social-stream/public/css/colorbox.css" rel="stylesheet" type="text/css" /> <link href="https://www.ncoinc.org/site/templates/social-stream/public/css/styles.css" rel="stylesheet" type="text/css" /> <script type="text/javascript" src="https://www.ncoinc.org/site/templates/social-stream/public/js/jquery.min.js"></script> that's as well as the version of jQuery you're loading at the bottom of the page. Obviously it's not good to be loading two versions of jQuery. In Test B the Hannah code isn't loading its own version of jQuery. I'm guessing the plugin code is looking for the presence of jQuery in the markup and finds it in the second but not the first - perhaps due to the way the page is being built. The first thing I'd try would be to move loading jQuery into the HEAD section of the site rather than leaving it until last. Techincally that's going to slow down your rendering but means jQuery will be loaded early if you want to add scripts inline. Of course the best solution is not to use jQuery or include social media widgets ?

Hey @flydev ?? I see that your style has the same issues that I had to tackle when building the rock style: First, the notices have some (in my opinion) unnecessary spacing: Second, the content tab should not have margin-left: I just tried and when adding this line on top of your LESS those issues (and maybe others) are gone: @import "../../../../wire/modules/AdminTheme/AdminThemeUikit/uikit-pw/styles/rock.less"; And finally one thing that is not related to the rock style: Tooltips are not the best in terms of contrast ? PS: Installation worked like a charm ?

Sure, RockFrontend just injects a CSS variable "rf-grow" to the root element and updates it on window resize. Then you can use regular (and easy to read and understand) CSS to define min/max values with fluid behaviour: https://github.com/baumrock/RockFrontend/blob/bcec0efcfba2036b26997ac7f2648300e978ee82/RockFrontend.js#L29-L48 <video style="width: calc(200px + 300px * var(--rf-grow))">...</video> That means: Min width = 200px, Max width = 500px, fluid in between ? That's all the magic! That's outdated as of 11/2022 - now RockFrontend does everything with CSS only (and some math / calc) ?

Looks a lot nicer and cleaner ? Thx for giving it a try!

Quite easy ? (see: https://github.com/baumrock/AdminStyleHello/issues/1#issue-1401993078) https://github.com/flydev-fr/AdminStyleDark/tree/dev

Might be worth adding a prerequisite to the module requirements - I still had a few sites on PHP 7 and the version of composer you include expects PHP 8 at minimum. Just letting you know.

@bernhard Not really. This sort of thing would be simple on some fields but very difficult on others. For instance, text fields, numbers, etc... very simple. But for any field that stores data beyond the field_* table (Repeaters, Files/images, PageTable, etc.) it would be difficult to achieve and to maintain. The only way to do it reliably across all Fieldtypes would be is if each Fieldtype implemented the ability on its own (through some base Fieldtype provided interface, which we may add at some point). That's because individual Fieldtype modules are the the only authority on how and where their data is stored. Granted, the vast majority of Fieldtypes just store data in their field_* table, keeping it simple, but it's those more complex ones (repeaters, files, etc.) that are the primary obstacle to some undo or version feature that works the same across all fields. It's one of the reasons I gave up on developing the Snapshots module, which I spent weeks on before realizing such features are not sustainable for complex Fieldtypes until it becomes part of the Fieldtype interface.

Hey @flydev ?? no, sorry, your way of doing it is outdated ? Just kidding... I just created 2 PRs which make it a lot easier to create AdminStyles (because I realised that it's harder than it could/should be to create such AdminStyle modules, thx for that!): https://github.com/ryancramerdesign/Less/pull/2 https://github.com/processwire/processwire/pull/245 And a new module that shows the new way of creating admin styles for ProcessWire ? https://github.com/baumrock/AdminStyleHello What do you think?

@bernhard could you take a look at https://github.com/flydev-fr/AdminStyleDark Is this the right way to do it?

You can import the attached file into your IDE. See instructions here https://www.jetbrains.com/help/phpstorm/sharing-your-ide-settings.html#import-settings-from-a-zip-archive I don't have much time atm and so I can not provide full instructions and the file not in a repo. Please note, that if you use settings sync, the import will not work and you have to put the "template" folder of the zip file into your PHPStorm settings folder which is depending on your OS somewhat like C:\Users\username\AppData\Roaming\JetBrains\PhpStorm2022.2 (Windows) paste it here! settings.zip

Hey @BrendonKoz no worries we are in DevTalk ? And I have had such a great idea yesterday, I almost can't believe it myself ? It solves all those weird scaling issues and makes it possible to scale any css rule that has a numeric value, like font-size, border, padding/margin, border-radius etc... It's so great and mighty that I have to do a video about that!! And it even comes with a helper to write values in PX that will automatically be converted to REM units ? Sneak Peak: /* default viewport settings: min=400, max=1440 */ /* all min/max values will be fluid in between! */ .fluid-box { /* font size 20px@400 30px@1440 */ /* px will be converted to REM automatically! */ font-size: rfGrow(20pxrem, 30pxrem); /* border-width 2px@400 10px@1440 (PX-->REM) */ border: rfGrow(2pxrem, 10pxrem) solid red; /* border-radius 5px@400 20px@1440 (PX) */ border-radius: rfGrow(5px, 20px); } Want to customize min and max width setting? Easy ? $rockfrontend->growMin('800'); $rockfrontend->growMax('1200'); Here is a demo with slightly different values: I'm loving it ?

Ryan, This looks excellent! As always, ProcessWire just does it! I've been using Pancake for several years, and it has a lot of the features you're developing. I've been happy with it. But I'd MUCH prefer to do invoicing with ProcessWire, so my invoicing would be the same framework as all my web apps. As always, thanks for your amazing work!

@ryan auto-reload and limit-save are incredible features. I never thought to buy ProDevTools but will do so for my next project because those two additions are great. Thank you.

@Boost Typically your _main.php would contain just the regions that would be common among all templates. Usually this is desirable because most websites have a common theme behind them. But if your template files are so different that nothing in <body>...</body> is the same, then maybe your _main.php is just this: <html lang="en"> <head id="html-head"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title><?=$page->title?></title> <!-- plus any other common head output --> </head> <body id="html-body"> <!-- any common body stuff, or even blank if none --> </body> </html> Then template file "basic-page.php" might look like this: <body id="html-body"> <div class="some-container-class"> <h1><?=$page->title?></h1> <?=$page->body?> </div> </body> and template file "gallery.php" might look like this: <body id="html-body"> <h1>Photo gallery: <?=$page->title?></h1> <ul class="gallery"> <?php foreach($page->images as $image): ?> <li><img src="<?=$image->url?>" alt="<?=$image->description?>" /> <?php endforeach; ?> </ul> </body> <!-- example of adding some JS and CSS files to the document head --> <script src="<?=$urls->templates?>scripts/gallery.js" pw-append="html-head"></script> <link rel="stylesheet" href="<?=$urls()->templates?>styles/gallery.css" pw-append="html-head"> <!-- or this does the same as the above with different syntax --> <head id="html-head" pw-append> <script src="<?=$urls->templates?>scripts/gallery.js"></script> <link rel="stylesheet" href="<?=$urls()->templates?>styles/gallery.css"> </head> I personally wouldn't create separate main template files like that and instead would just use a simple enough _main.php to accommodate anything I want to do with it. You certainly could use direct output too, and I'm guessing maybe half of PW sites do this. But consider the case above where we needed to add script/link tags to the document <head> from our template file. This is where direct output becomes more limiting, unless you want to start adding template-specific logic in other include files, like whichever one outputs your <head>. Either that, or you end up needing your template file(s) to each output an entire HTML document. So markup regions are really convenient in part because you can output directly (like direct output), but can also manipulate markup that's already been output, or will be output later.

Hi, this is an easy way to have beautiful icons in the languages switcher: <?php foreach ($languages as $language) { if (!$page->viewable($language)) continue; // is page viewable in this language? if ($language->id == $user->language->id) { echo "<span style='padding:3px;border-bottom:1px solid #333'> "; } else { echo "<span style='padding:3px'> "; } $url = $page->localUrl($language); $hreflang = $homepage->getLanguageValue($language, 'name'); $lan = $language->title; $it = '<img src="' . $config->urls->templates . 'images/italy.png" style="width:30px"/>'; $en = '<img src="' . $config->urls->templates . 'images/gb.png" style="width:30px"/>'; if ($lan == 'IT') { echo "<a hreflang='$hreflang' href='$url' >" . $it . "</a></span>"; } else { echo "<a hreflang='$hreflang' href='$url'>" . $en . "</a></span>"; }; } ?> Bye!

Agreed, I have requested this: https://github.com/processwire/processwire-requests/issues/455 I don't want to add a text formatter or a hook to achieve this as it is such a big optimisation for every site.

Hi @Peter Falkenberg Brown ? Yup, on the template on which you want the new children of it that are created to skip the name field page you have to go to Family > Allowed template(s) for children and select the templates which should be allowed for the children of it. Now below it a new option "Name format for children" should appear. If you enter "title" (without quotation marks) here the new children created for this page will skip the "name field part" and automatically be named after the title field of the page once saved ? Hope that helps ? Best, Jonatan.