Leaderboard

I hope that you all are having a good week and staying healthy. I’ve been very much focused on preparing a new ProcessWire-powered client’s website for launch, hopefully sometime next week. This is a site that’s already pretty well established with the search engines and such, so I’ve been going through all of the pre-launch QA in terms of optimization, SEO accessibility, mobile testing, getting the multi-language translators everything they need to translate, adding ProCache to the picture, and so on. For me this is one of the most fun parts of development, with relentless optimization and having it all come together… but also one of the most time intensive. This is where all the little details surface, things that need improvement become more apparent, and new ideas keep popping up. It’s also where lots of the bugs are discovered and fixed, and where I sometimes have to slap myself on the head for missing one thing or another, but then of course taking care of it. So that’s been most of this week, and I think likely at least half of next week too. But then it’s back to work on the core and modules, covering issue reports and more. I’ve actually been at work on some parts of the core and ProCache this week as well, but not to the point of finishing anything major. So you’ll see some updates on the core this week, and there’s also lots of stuff pending that’s not yet committed, and it’s all work in progress, so stuff to review later. With kids at home I’m still moving at a little slower pace than usual, but starting to get the hang of it, doing well and building momentum. While I don’t have much new to offer in this update, thanks for reading anyway, and I hope that you have a great weekend!

So here's a thing I've been chewing on for a while now.. And although I kind of have a handle on it at this point, I'd still love to understand what is actually happening here ? Please bear with me.. Last year I did a project for a client in Lübeck, Germany, and implemented a full text search on $page->body and $page->summary not too different from @ryan's default site frontend search functionality. Got it all to work nicely without too much hassle, client was already filling up the site with content, and then one day I decided to test the frontend search by looking for pages with "Lübeck" in them. Which threw out 3 matches in more than 50 pages. Naturally, with the site being in Lübeck, that number seemed a little off, so I checked manually and realized there were lots of pages missing from the results. So I thought ok something's broken about my search. Half a day of testing later, and ending up using Firefox's Ctrl+F search with "Match Diacritics" + "Highlight All" on the frontend, i realized that not all ü's were the same across the site. Some would get highlighted (those that PW's search would pick up), and some wouldn't. // try to CTRL+F this page and search for one of these ü != ü Talking to the client it turned out that he had copy-pasted large chunks of the content from PDF files. He was working on a Mac, so I did some research and found a bunch of information on all sorts of weird diacritics problems when doing exactly that ? These are in german but I think the basic idea should come across https://blog.k-webs.ch/2017-02-verschobene-punkte-ueber-umlauten.html https://www.macuser.de/threads/falsche-umlautdarstellung-ue-punkte-versetzt.748967/ So it turned out some of the buggers were actual ü's, and some were actual u's with a "trema" attached to them. Something a little bit like this // but not quite u¨ Now the part where this gets even more confusing is, on the frontend side they don't look the same across different OS's / browsers / what have you. Chrome on apple seems to handle them completely different from FF on Windows 7 for instance, so the client couldn't even understand what the problem was because he didn't see it. Also please note that during that particular project all other Umlaute / Diacritics were fine, äs, ös, uppercase, lowercase,, everything. Just the little ü's were acting up. So we sat down and started out search & replacing them. There was not a lot of time, aaand well I was new to PW ? ... stay tuned for Part II where we're doing a project with over 200 international artists with all sorts of funky diacritics in bandinfos *all coming from PDF Files* ?

@psy, in theory you don't need any sort of special module to put runtime markup into a field. Instead just add a Markup field to the form and then hook before the form is rendered to put whatever markup you want into it. Having said that, there are some oddities with Markup fields in FormBuilder. I raised some questions that Ryan answered here: But I still had some other problems (I can't remember exactly what they were now) that I ended up resolving by making a clone of the core InputfieldMarkup module with some minor changes. I've attached the resulting InputfieldCustomMarkup module. If you install this module and enable it for use in FormBuilder then you can use it the same as a Markup field but without the snags. InputfieldCustomMarkup.zip

See my signature ?

Hey @psy I'd create a custom runtime module, it's not too hard: 1) Create the fieldtype: 2) Create the inputfield: RockMarkup is deprecated because I don't plan to use it as base module for other Fieldtypes in the future. I think it makes things more complicated and that's not worth it. Building custom fieldtypes + inputfields is easy once you know how things work. Especially runtime fields are easy because you don't need all the DB related parts. If you need any help just ask.

Hey, I would do a type check on the return of banner->getRandom(). You do not check if there is always at least one image available. Or just temporary try this for a while and see if it behaves the same with the log filling: $random = $page->getUnformatted("banner")->findRandom(1); if(0 < count($random)) { $thumb = $random->first()->size(200, 200); echo "<a href='$thumb->url'>"; echo "<img src='$thumb->url' alt='$thumb->description' />"; echo "</a>"; }

@SamC it's really as simple as that: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks Update 2022: $wire->addHookAfter('Pages::saved', function(HookEvent $event) { $page = $event->arguments('page'); bd('page saved'); bd($event, 'event'); bd($event->object, 'event->object'); bd($event->arguments(), 'event->arguments'); }); in the beginning it can be a little confusing when to use event->object, event->arguments and event->return but with the help of tracy you can quickly bring light into the dark: add the code above to the tracy console, set the radio on the right to load it on "ready" (same as placing the code in the site/ready.php file) and save any page: $event->arguments('page') is the same as using $event->arguments(0) that you will see very often and in the tracy dump you see that 0 is simply the key for the first argument in that hookevent. you can also collapse the "data" property of the hookevent and you would see the same: You can also use your IDE to quickly find what the HookEvent is returning/containing in which hook. Let's take the common saveReady hook as an example: We know that the hook is attached as Pages::saveReady (eg because we have read that somewhere) That means that the hook is part of the "Pages" class, which is located at "/wire/core/Pages.php" - that's easy to find out using CTRL+P in VSCode: Searching for "___saveReady" lets us find the corresponding method: Now we see, that we have ONE "arguments", being Page $page - this means $event->arguments(0) would return the page being ready for saving $event->object would be the class, here "Pages" $event->return is the return value of that method, here $data (line 1739) Edit: There's some additional explanations in this post: https://processwire.com/talk/topic/27248-pagestrashtemplatefoo-vs-pagestemplatefootrash/?do=findComment&comment=224659 #search afraid of hooks

Hi @Andi Interesting, thx for sharing ? I've had a similar strang issue lately where utf8 encoded whitespaces where an issue. Why don't you put that code in a saveReady hook so that it is done automatically on every page save? Even better would be a little module so that you can share it with us ? // info snippet class Classname extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return [ 'title' => 'Classname', 'version' => '0.0.1', 'summary' => 'Your module description', 'autoload' => true, 'singular' => false, 'icon' => 'smile-o', 'requires' => [], 'installs' => [], ]; } public function init() { $this->addHookAfter("Pages::saveReady", $this, "replaceBadUmlauts"); } public function replaceBadUmlauts(HookEvent $event) { $page = $event->arguments(0); $bad = array("ü","ö","ä","Ü","Ä","Ö"); $good = array("ü","ö","ä","Ü","Ä","Ö"); $page->summary = str_replace($bad, $good, $page->summary); } /** * Config inputfields * @param InputfieldWrapper $inputfields */ public function getModuleConfigInputfields($inputfields) { return $inputfields; } } In the module config you could add an asm field to select the fields where the replace should happen

Encountered this issue too. The following change to InputfieldRuntimeMarkup appears to have fixed the missing utilities class: <?php public function init() { // parent::init(); // get the helper class (included in FieldtypeRuntimeMarkup.module file) $this->classLoader->loadClass('FieldtypeRuntimeMarkup'); // add this line to ensure the RuntimeMarkupUtilities class is available $this->rtmUtilities = new RuntimeMarkupUtilities(); } Can now install, uninstall, create & delete fields, etc without problems. I needed this module for a FormBuilder form but sadly the module's configurable fields aren't available in FormBuilder ?

Thanks, I should have tested that. Fixed now in v0.1.1 Good idea, I've added this in v0.1.1

Stripping off empty paragraphs can be harder than it may sound: As requested by @netcarver I put it into a textformatter module: https://github.com/BernhardBaumrock/TextformatterRemoveEmptyParagraphs https://modules.processwire.com/modules/textformatter-remove-empty-paragraphs/ TextformatterRemoveEmptyParagraphs ProcessWire Textformatter to remove empty paragraphs from CKE fields Removes empty paragraphs from a html string. A paragraph is considered to be empty if it only contains one or more of the following: regular whitespace UTF-8 encoded whitespace all variants of <br/> PS: I'm actually not sure if that makes sense as Textformatter at all. IMHO this should be done on processInput, so it's more a sanitization than a textformatter... @netcarver what do you think, as you requested this... ?

I really have a Shopify class implemented, but basically you can do this as simple as: // https://shopify.dev/tutorials/authenticate-a-private-app-with-shopify-admin $key = "yourkeyhere"; $pass = "yourpasswordhere"; $store = "yourstorename"; $data = array( "since_id" => "632910392", // Retrieve all products CREATED after the specified product (by ID) "fields" => "id,images,title", // include only this attributes in the response ); // Is better to use try/catch here $http = new WireHttp(); $response = $http->getJSON("https://{$key}:{$pass}@{$store}.myshopify.com/admin/api/2020-01/products.json", true, $data); // True to get an array, False for object $products = $response["products"]; if (count($products) > 0) { foreach ($products as $product) { echo $product["title"]; // direct output or save to a custom array to use in views, etc. } } // use the id field for the Buy Button js code in order to have the cart/checkout in your site

@tpr I don't remember if I have posted this already some time ago... The option "disable all admin animations" practically makes the vec-dialogs unusable. The dialog will appear, but won't disappear when you choose either of the options. You then have no choice than to hard-reload the page. Maybe a word of caution would be nice in the settings. I stumbled over this a long time ago, and recently forget how to fix it.

Hi, I've added an addInlineImage() method to https://github.com/chriswthomson/WireMailMailgun <?php $img = $pages->get(1)->images->getRandom(); // An example $customFilename = "test.$img->ext"; // Don't want to use the basename for this example $mg = $mail->new(); $mg->to("your@email.com") ->subject("Test Inline Image") ->bodyHTML("<p>Testing, 123, is there an image for you to see?</p><img src='cid:$customFilename'>") ->addInlineImage($img->filename, $customFilename) // Second argument is optional ->send(); If the image isn't referenced in the HTML it just appears as a standard attachment from what I can see. Cheers, Chris

this is not possible with no existing system on the web..... Actually I believe @JRW-910 was referring to the users not having to know any coding. Please correct me if I'm wrong, though In addition to what @mr-fan said above, I'd suggest taking a closer look at the devns branch of ProcessWire. This is the future 3.0 version, still in development, and among other features it includes a kind of a front-end editing support. Perhaps not exactly what you were looking for, but this could come in handy anyway. Other than that, Fredi provides front-end editing support right out of the box, and you can always embed admin views into the front-end by applying "&modal=1" to the URL of the edit view. This is all good to know in case you don't actually require a fully customised front-end editing experience, but would rather use the one ProcessWire provides out of the box. If it is a fully customised front-end editing feature you're looking for, that's relatively easy to achieve via the API. ProcessWire is awesome for this kind of stuff, but again: unless you really need a fully custom solution, I would suggest looking into the existing solutions first. For an example the FrontendUser module mentioned above is definitely a viable solution for the user registration part For managing permissions ProcessWire makes use of a simple role-based approach, but if you need something more specific, here are a couple of alternatives: Dynamic Roles provides a very flexible method of defining new "dynamic roles" in addition to the real ones based on various factors. There's very little in terms of permissions you can't achieve with this module. User Groups allows you to define page-specific or branch-specific permissions, and adds the new concept of "user groups" for grouping users together, regardless of roles they might have. Page Edit Per User does what the name says: assign edit access to individual users on a per-page basis. This module is a bit older already, so not entirely sure how it works with the latest versions of ProcessWire, but it's also a relatively simple one, so if it doesn't work it's easy to cook up something similar.