Leaderboard

Haven't used it yet but I think this is something you can control in the module’s (or even in the field’s?) settings with the pastefilter whitelist:

I'd try to purge cache and cookies first.

Hi @kongondo thx for your kind words ? Yeah it took quite long and it was really not easy to put everything that I know in a 20min talk. Obviously. That's why it took 60 ? But yeah, I wrote down all that I love about PW over some weeks and then tried to wrap everything up and tried start from scratch so that everybody understands what I'm talking about, but then also show how much power it has under the hood. Regarding the checks: We had technicians for that ?? But thx for the kudos ? Thx for the feedback! I had one guy that gave me the feedback that he found the git thing confusing. But we currently stand at 3 who said they liked it ? For me it was a good way to make sure that everything works as expected and even if I forget something I don't end up in disaster trying to find a silly bug that I introduced somewhere... Also that way I can put it on github for everybody to inspect. Same here. I never really saw the benefit. It always felt as something new to learn, with a different syntax than the one I knew for something that PHP itself can do really well. And I didn't see a lot of benefit in using {{ foo }} instead of <?= $foo ?> either. That totally changed when I saw things like this: <ul> <li n:foreach="$page->children() as $child"> {$child->title} <a n:if="$child->editable()" href="{$child->editUrl()}">edit</a> </li> </ul> I didn't mention any performance issues. But I'm not using it on any huge projects so far. Though latte states that it's extremely fast because it compiles to pure PHP (you can inspect those files in /site/assets/cache/Latte when using RockFrontend). Same here again. I was never a fan of docker (though I'm getting to know it better and start liking it I guess). I'm using it on a MacBook Air at the moment. I'm not on Windows any more. Just like docker I've never really liked mac either, but I had to use a macbook in the agency I was working and despite the hassle that came with switching keyboard layout etc. it was actually a really good experience. I fell in love with the absolutely zero noise level. No fans at all. Never. Not the slightest noise unless it has to output some audio. Really great. Also battery life is great. It's a new experience for me to just grab the device without really thinking about if the battery will last long enough in meetings. It will. DDEV was also one of the things that I "had to use" in the agency. And it's an absolutely brilliant tool so I'm still using it every day and it has helped me so much in some projects that would have been a lot of pain in the days when I was using laragon on windows. For example I'm working on a project where I need to transform PDFs in JPGs for quick and efficient previews and that's very easy to do on unix with poppler-utils. A single line of code. But on laragon+win that did not work, so I had to work around that or develop on the live system and then copy+paste things over to local to then push it back to git... Now on DDEV I can simply install poppler-utils in the web container and everything locally works just like on production. I've been using DDEV on Windows in my first month at the agency. It worked very well first, but then it got reeeeeeally slow. Not sure what was the reason though. It was a quite weak device compared to my macbook (8GB instead of 16GB ram) and with all the virtualisation that might have been too little after all. But I have the feeling that something else was going on. I've had one issue on mac as well where it was causing high cpu all the time. That went away after an update, so maybe something similar was happening on windows as well. But afterall I'm enjoying the unix system on my mac now and I found alternatives for all my programs that I've been using on windows (the only one that I'm still missing is "search everything" - so if anyone has a mac alternative for that, please let me know!). That's saving a page... fast enough for my taste ?

I have the need to change the text colors in a TinyMCE field. There seems to be a plugin available for this case: https://www.tiny.cloud/docs-4x/plugins/textcolor/ But in the field settings this plugin option is missing: What could be a workaround for this? SOLVED: The documentation link was for version 4... in the current version 6 you have to insert the "forecolor" setting into the toolbar. That's it!

What @flydev said. A slightly different alternative to the above is to store the order values in a hidden input as a CSV. In that case, you don't need to touch window.location.href. You would use the values in the CSV to access the GET params sequentially.

@bernhard Very late comments here. I'd started watching but things got in the way and I didn't finish. I've just finished watching. A-M-A-Z-I-N-G! Thoroughly enjoyed this one. Thanks for sharing and thanks for representing ProcessWire. It looks like a lot of thought went into the presentation. It was also interesting to hear about your background. I am guessing this perhaps explains why your work/modules are always so polished and of high quality!! I suppose you don't get into a helicopter without meticulously checking everything works as it should ?. I liked the way you showed the basics first and gradually moved into the more advanced topics. I also liked the way you used git history. I have learnt some new things as well and my interest is piqued. I have never been a fun of PHP template engines but that latte stuff you showed got me really interested. That is a lot like 'modern-js' like you said! Have you noticed any performance issues with latte? I was also very impressed with ddev. I know you have mentioned it before but the 'docker' bit is what has put me off in the past. For some reason, docker was either slow on my machine (a Windows thing maybe?) or just wouldn't work. I am very curious about ddev now. Do you still use a Windows machine? How's ddev in terms of performance? Anyway, great stuff and thanks again for sharing!

Looks like a perfect application for LazyCron. A quick and dirty snippet of code you can place in site/ready.php (or inside a template's PHP file, just make sure that a page with that template is viewed regularly): <?php namespace ProcessWire; // Add daily hook to clean up incomplete, stale pages wire()->addHook('LazyCron::everyDay', null, function(HookEvent $event) { $ts = time() - 86400; // 24 hours ago // Find matching pages, adapt selector however you want (e.g. limit to certain templates or parents) $stalePages = $pages->find("created<$ts, title=''"); foreach($stalePages as $stalePage) { $pages->trash($stalePage); } });

Change Default Language to be None-English | Walk Trough When you start a new (single) language site and the default language shouldn't be English, you can change it this way: Go to the modules core section: Select the Language ones by the filter function: We have four language related modules here, but for a single language site in none english, we only need the base module, named "Languages Support". So go on and install it. After that, you can leave it, ... ... and switch to the newly created Language section under SETUP: Select the default language Enter your new language name or its Shortcut and save the page. I will use DE for a single language site in german here as example: Now I go to the ProcessWire online modules directory, down to the subsection for language packs and select and download my desired (german) one: After downloading a lang pack as ZIP, I go back into my SETUP > LANGUAGES > default language page in admin, select the downloaded lang pack ZIP and install it: After the ZIP is uploaded, the files are extracted and installed, most of my screen is already in the new default language. To get all fully switched, we save and leave that page, ... ... and completely logout from the admin. Now, of course, we directly login back, ... ... and see, that now also the cached parts of the admin have switched to the new default language. ? That was it for a single language site in none english. If you want to have a multi language site, just add more languages to the SETUP > LANGUAGES section. When using a multi language site, I think you also want to use multi language input fields, and maybe different page names for your language page pendents. If so, you need to go into MODULES > CORE > filter LANGUAGE and install what you need or want to use of it, (if not already done). Thanks for reading and happy coding, ?

Hello PW Gurus. It´s been a while since i posted here. I am in the process of deciding to update to 3.0.217 from 3.0.213 and have a question. I was using the latests standalone version of the TinyMCE module (6.1.5) with my PW 3.0.213 install. And now the TinyMCE module is in the core with PW 3.0.217 dev as i understand. Should i remove the standalone TinyMCE module before upgrading to 3.0.217 dev or after ? or at all? Does it make any difference ? Hope it make sense, otherwise ask me for more info. Thanks in advanced.

@flydev I'll start with 8 and see where it get's me tomorrow. ? @WillyC I'll give it a try but first I have to bring the whole darn thing back to my dev Server. disabling the mods on production is something I wouldn't dare to. No idea if they may loose some settings and both are crucial for the site.

That's correct. I oftentimes have non-developers set as the Superuser role, but I wouldn't want them to see the Tracy Debugger bar. Edit: I should reword my explanation as my usage of Development and Production is confusing within the context of Tracy Debugger.

@ttttim Is it possible that new version of Safari is swapping around stuff in the useragent string? You might try setting $config->sessionFingerprint = false; temporarily in your /site/config.php file, just to see if that's the source of it. I would also try logging in from a new "Private" window in Safari, to see if might be cache/cookies like Bernhard mentioned.

@bernhard The Pastefilter may be good for this specific case, since you are wanting to filter pasted content. But also have a look at the valid_elements and/or invalid_elements options, which give you control over what tags and attributes are supported in the input.

FieldtypeColor always stores the value as 32-bit (int) in the database (page field). If we are talking about InputfieldColor, the transmitted value is either a 24- or 32-bit colour hexcode, which depends on the selected inputType as described above. I assume you want to use the input field as a configuration field for your module. In this case, the transmitted value of the input field is relevant. Module configuration data is always stored as a json encoded string in the database.

Normally copies of core modules inside the site modules’ folder take precedence, so in your case the core TinyMCE module should just be ignored.

I installed a setup with 10.6.11-MariaDB, Duplicator v1.4.21 and did a backup/restore from a utf8mb4 => utf8(mb3). It went good, no problem so far. For information, utf8mb3 is an alias of utf8 on MySQL where on MariaDB is spelled utf8mb3 for less confusion I want to say. So utf8mb3 == utf8 (Will be deprecated soon after MySQL 8 ). Also, you should check what @dragan suggested, and I was wondering if your setup is a multilanguage setup ? It could be a hook or even a module maybe. You could also try to spot the issue by exporting the distant bugged database and importing it on your local dev setting the same charset (utf8/utf8mb3) and see his behavior. Checking/diff the .sql distant/local files with, for example, Beyond Compare (trial test is ok) or MySQL Workbench

Check if you have the same "advanced" settings in both sites: $config->advanced = true; Can you open page id 3 (that's Admin > Pages) directly? https://mysite.com/admin/page/edit/?id=3 What do you see in the settings tab? It should look like this, if you have advanced mode activated: Normally, you shouldn't have to play around with these settings on a default admin (system) page. Also... seems obvious to check first, but perhaps you have some hooks or your own custom module installed that interferes with normal behavior?

So far I found no strange differences. But that will take some time as the pages are quite different regarding their content. ProcessWire Version is 3.0.184 What I found in my exeptions Protocol is: Template changes are disallowed on page 3 because it has system statusIn /wire/core/Page.php line 2000 And thats the setTemplate function protected function setTemplate($tpl) { if(!is_object($tpl)) $tpl = $this->wire()->templates->get($tpl); if(!$tpl instanceof Template) throw new WireException("Invalid value sent to Page::setTemplate"); if($this->template && $this->template->id != $tpl->id && $this->isLoaded) { if($this->settings['status'] & Page::statusSystem) { throw new WireException("Template changes are disallowed on page $this->id because it has system status"); } if(is_null($this->templatePrevious)) $this->templatePrevious = $this->template; $this->trackChange('template', $this->template, $tpl); } if($tpl->sortfield) $this->settings['sortfield'] = $tpl->sortfield; $this->template = $tpl; return $this; } But I've absolutely no idea why Processwire would try to set a template when opening the admin branch of the site tree.

I think it should work as the difference reside on utf8mb3 use a maximum of 3 bytes and utf8mb4, 4 bytes which is not really important on your issue (supposing it only..) I will test an utf8 export and restoring it on a mb3 db in less than a hour with Duplicator v1.4.26. Will report result here. Yes ok, you should just have to compare the `pages` table with your dev one to spot something. If you find something, please, keep us updated ? PS: @torf which version of ProcessWire we are working on ?

Hi, With javascript you can achieve it easily. The idea is to add an event listener to each input and re-order an array when the user change an input: <form id="form"> <label for="filter1">filter 1 :</label> <input type="text" id="filter1" name="filter1"><br> <label for="filter2">filter 2 :</label> <input type="text" id="filter2" name="filter2"><br> <label for="filter3">filter 3 :</label> <input type="text" id="filter3" name="filter3"><br> <button type="submit" name="submit">Send ☑️</button> </form> <script> // get form and all input const form = document.querySelector('#form'); const filter1_field = document.querySelector('#filter1'); const filter2_field = document.querySelector('#filter2'); const filter3_field = document.querySelector('#filter3'); // array to store the order of the input const order = []; // listen for input fields change to update the order array filter1_field.addEventListener('input', () => updateOrderArray('filter1')); filter2_field.addEventListener('input', () => updateOrderArray('filter2')); filter3_field.addEventListener('input', () => updateOrderArray('filter3')); // update the order array function updateOrderArray(fieldName) { if (!order.includes(fieldName)) { order.push(fieldName); } } form.addEventListener('submit', (event) => { event.preventDefault(); const baseUrl = 'https://example.test/form.php'; // L'URL de base // build the url with the GET parameters in the order specified by the order array let url = baseUrl; order.forEach((fieldName, index) => { const value = encodeURIComponent(document.querySelector(`#${fieldName}`).value); url += `${index === 0 ? '?' : '&'}${fieldName}=${value}`; }); // redirect window.location.href = url; }); </script> Result: /form.php?filter3=processwire&filter2=is&filter1=awesome

Looks like we've been down this path before:

You don't need a different field for this scenario. You can use template overrides for the field settings. In the field settings (Overrides tab): Then from the template settings, edit the field in template context:

$f = wire('modules')->get('InputfieldColor'); $f->inputType = 1; Simplest solution: Choose inputType 0 or 1. If you want to use the Spectrum color picker (inputType = 3). I added an option to explicitly disable the alpha channel. Please update to version 1.1.6 and disable the alpha channel: $f = wire('modules')->get('InputfieldColor'); $f->inputType = 3; // spectrum $f->alpha = false; If you want to use a custom JS input type (inputType = 4), the alpha channel is disabled by default. The following additional properties are provided to make it work with your custom color picker: initJS (initial JS) fileJS (custom JS file) fileCSS (custom CSS file) $f = wire('modules')->get('InputfieldColor'); $f->inputType = 4; // custom js and css $f->initJS = '$("{id}").initCustomJS({ color: "{value}" });'; // placeholders for value and id of HTML input element $f->fileJS = "/path/to/file.js"; $f->fileCSS = "/path/to/file.css";

TextformatterEmoji converts named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. For instance :smile: converts to: ? This can be especially useful if your ProcessWire uses the utf8 character set rather than utf8mb4 as it enables you to use emojis on an installation that typically would not be able to save them. This is because emojis usually require utf8mb4 (4 bytes characters) to be used by the database in order to store them. Note that how the emoji appears (and sometimes whether it appears) can vary from platform to platform, and from browser to browser. Here is an alphabetical list of supported emojis and the shortcodes you can use to show them in your text. If you want to add any emojis that are not already present you can do so in the emojis.json file.

If folks are looking to add the full gamut of emojis, be sure to check out https://emojipedia.org/ You have to scroll down a bit on more complex multitone emojis, but shortcodes are also included.