Leaderboard

Last week we released the new ProcessWire 3.0.184 master/main/stable version. This is our biggest version release in a year. It's been a very smooth stable version launch with no major issues so we're keeping the version number where it is this week. If you haven't upgraded yet, it's an easy and worthwhile upgrade. For full details see the blog post that covers it all. This week I have 3 new Textformatter modules released in the modules directory. These are modules that I developed earlier for recurring needs that I had, but this week decided to finish them up and release them. I hope that you might find one or more of them useful sometime. TextformatterFindReplace This module applies find/replace patterns to formatted text or markup at runtime. The patterns may be simple text or more complex regular expressions. This module can be handy if you perform a text replacement on all output from a particular field, without having to manually make the change on all instances where it might appear. For instance, maybe you need to insert a trademark symbol ™ after every appearance of a brand name, or maybe your website hostname has changed and you need to replace all references to it, or perhaps you need to replace all <h1> headlines with <h2> headlines. These are just a few examples of any number of possibilities. Read more / Usage / Examples TextformatterMarkdownInMarkup Enables you to use Markdown formatting codes in CKEditor (or HTML). A significant amount of content that is populated into the “bodycopy” field of websites is not actually written in the admin and instead originates from text editors, word processors, and other tools outside of the CMS. It then gets pasted into CKEditor, and then manually formatted into HTML using tools in CKEditor. This process of manually converting links, lists, headlines, bold, and italic text and more can be sometimes very time consuming. This module provides a time saving alternative, enabling use of markdown formatted text in CKEditor (or any HTML/richtext editor). It remains as markdown formatted text in the editor, but as soon as it is rendered on the front-end it is automatically formatted as HTML. This means that text like **this** gets converted to this, links like [this](https://processwire.com) get converted to this, and so on for most types of markdown formatting. This enables markdown formatted text to be written anywhere and the formatting to be rendered properly in your bodycopy when viewed on your website. Using this module means that you can mix richtext and markdown in the same copy. No longer do you have to manually convert all of the links, lists, bold/italic, and so on in pasted in text. This module saves me quite a bit of time when writing blog posts like the one last week. Much of the formatting in that post was markdown based, since I wrote the post in my text editor over a period of a couple weeks. Once I got it into CKEditor, I did some formatting with that too, but when it came to other formatting (especially links and inline `code`) it was a big help to have them just work, and not to have to re-do all of them manually with CKEditor tools. So why not just work exclusively in Markdown? Well I don't like working with just markdown most of the time, I much prefer CKEditor. But I also can't deny the convenience of markdown for a lot of cases too. So being able to use Markdown within CKEditor is the best of both worlds, to me at least. Read more / Supported markdown / Configuration options TextformatterEmoji This module converts more than 800 named shortcode emojis in ProcessWire text or textarea fields to the corresponding UTF-8 emoji character. ? This can be especially useful if your ProcessWire database 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. Though when you want to specify an emoji by name, this module will be useful regardless of your database charset. Read more / Supported emojis reference

Pages will only appear in the dropdown menu if those pages have a Process assigned. See here. In effect this usually means "pages that use the admin template". You could possibly create a custom Process module that you use to redirect to other pages in the module's execute() method. Then create new pages using the admin template and select your Process. See here for an easy way to set the menu icon of admin pages. But also consider using the "nav" item in the getModuleInfo() method of a custom Process module. This lets you define some dropdown menu items for the Process when the page is in the top menu. ProcessModule is an example. Unfortunately you cannot set the first level of dropdown items dynamically. https://github.com/processwire/processwire-requests/issues/189 The top menu is cached (unnecessary in my opinion) so if you are making changes and not seeing them reflected in the menu then do a Modules > Refresh (and Tracy has a handy shortcut). Add "#ProcessPageEditChildren" to the URL. /your-admin-page/page/edit/?id=1234#ProcessPageEditChildren

Wow, a triple-whammy of modules, thanks @ryan! I noticed that two of these new modules don't have support threads in the forum and the Support button in the modules directory listing isn't functional. That situation also applies to your Login Register module which I believe used to have an entry in the modules directory but no longer does. (Edit: after doing a quick scan through your modules in the directory it looks like the majority don't have support threads in the Modules/Plugins subforum) It's inevitable that users of these modules will have questions/issues that they will want to raise here in the forums, so it would be good if every module that's shared with the community has a dedicated thread in the forums. Otherwise people open multiple new topics so it's harder for users to look through the history of discussion about a module. If the reason some of your modules don't have support threads is that you're not able to spend time responding to support requests (which is totally legitimate IMO) then the opening post could explain the support status of the module, maybe something along the lines of "this module has been shared with the community but the author is generally not available to provide ongoing support". Then people can still post questions or issues with the understanding that they are not guaranteed to get support from the module author but that other members of the PW community may offer advice.

I do not know how you do this magic ?, Ryan, but it happens once again. I do need emojis in utf8 db this week. And bang ? - now I have it))

Thanks. I assume you mean if you accidentally add a description because the point of this module is that it hides the fieldset that surrounds the fields so you wouldn't expect to be able to see any description. In v0.1.7 the module explicitly hides any description and notes for the fieldset so if these are accidentally present they won't disrupt the intended layout.

To be honest, I don't know if this is a standard processwire file. But with language files one can use it as follows: Instead of adding each string to an own variable, you can add a second parameter to all the language strings you use around in different template files or module files or where ever you need them: __('Text 1', '/path/to/your/_strings.php'); __('Text 2', '/path/to/your/_strings.php'); ... And instead of adding the '/path/to/your/_strings.php' as text all the time, I use a functions call for that. This way you do not have to include the file and can use it everywhere handled through the PW translations system, because you tell it that the current string is the same as a string in the centralized _strings.php In /site/init.php I define this function, that simply returns the path to my centralized translation file: /** * TRANSLATABLE STRINGS * Include translatable strings */ if(!function_exists('ProcessWire\mystrings')) { function mystrings() { return '/site/_strings.php'; // absolute URL or absolute filepath to the central translation file } } My _strings.php would look like this: <?php namespace ProcessWire; /** * TRANSLATABLE STRINGS * Define globally available translatable strings * * USAGE * * __('Lesen Sie mehr ...', mystrings()); * * The function mystrings() returns the textdomain of this file. * **/ ... __('Datenschutzerklärung'); __('Die Maße des Werks sind:'); __('Dieses Bild drucken!'); __('drucken'); ... __('Text 1'); __('Text 2'); ... __('Zurück zur Übersicht'); To sum up, this way I don't need to include a _strings.php and it also works every where.

This week we have a new master/main version released after a full year in the making. With nearly 40 pull requests, hundreds of new additions and more than 100 issue reports resolved, this new version has a ton of great new stuff and we’ll cover most of the new stuff here— https://processwire.com/blog/posts/pw-3.0.184-master/

Minimal Fieldset Adds a config option to Fieldset/FieldsetGroup/FieldsetPage to render the fieldset without label or padding in Page Edit. When a neighbouring field in the same row is taller than the fieldset the extra height is distributed evenly among rows within the fieldset. Requires ProcessWire v3 and AdminThemeUikit. Why? This module allows you to create layouts in Page Edit that would not be possible without it. It's useful when you want a layout that has two or more fields as rows that are themselves within a row in Page Edit. It's also useful when you have some fields that you want to add to a template as a group (i.e. via FieldsetGroup or FieldsetPage) but having a heading and visible wrapper for the fieldset in Page Edit would be redundant. Example: Installation Install the Minimal Fieldset module. Usage In the field settings for any Fieldset/FieldsetGroup/FieldsetPage, tick the "Remove label and padding for this fieldset" checkbox. https://github.com/Toutouwai/MinimalFieldset https://modules.processwire.com/modules/minimal-fieldset/

I did a very quick text and it seems to work! ? I just created a new Process class based off one that was already in there and placed it in site/modules and added the nav, stripped back what I thought I didn't need and installed the module and it pretty much worked first time. It will take a bit of tweaking but the bit I was struggling with now works. Thanks again!

I think MediaManager or FieldtypeDynamicOptions could help you, depending on your needs, check them out!

Well its about time, after using ProcessWire for years (and loving it) to share some projects we have done with it. This is our own agency website 2getmore.at we build websites, online shops and apps for our customers. Also we support them with their online marketing needs like ads, SEO and Social Media. Plugins used AdminOnSteroids Breadcrumb Dropdowns Custom Inputfield Dependencies Dashboard Email two-factor authentication Form Builder PRO General site settings (Process) Jumplinks Map Marker ProCache PRO ProDrafts PRO ProFields: Repeater Matrix PRO Seo Maestro SVG File Sanitizer/Validator TOTP two-factor authentication Tracy Debugger Upgrades Wire Mail SMTP Other tech We use the functions API. As the output strategy we are very happy with markup regions. For the Frontend we use UIkit which we also love just like ProcessWire. I will be posting some of our projects done for customers as well in the next couple of weeks. Happy to be part of the ProcessWire community, I am not very active in the forums but when i have questions people are always very supportive. Looking forward to your Feedback.

Really nice work by Ryan and all the involved people. I am very happy to see more adaption of PR's from the community and more effort of the community to work on ProcessWire, because @ryandecided to make PW more community-driven. So I have a goodie for all german speaking ProcessWire users: Guess what will be released later today (if nothing happens), or at least tomorrow? YEAH, right, the german language pack!

Updated a side project (https://www.restaurants-neumuenster.de/) today to the newest master and all related modules without any issues. Such a perfect setup overall! Feels not only faster but even Google says it is. Never saw those ratings on that site

Congratulations to all of us it the community! And the biggest possible thanks to Ryan for making this step to actively communicate with everyone interested on PRs, issues and wishes! Many of the latter came true ???

@teppo - certainly not a bad idea. It's actually what I did with the Terminal panel for the same reason. However, this is the first report I've had of Adminer being flagged as spam by a host, so I might wait to see if others also have the same issue. I am hesitant because I think this is a such a useful panel - I use it many times a day - I really love the context sensitive initial view it gives depending on what you are currently viewing / editing in the admin. As well as being a great utility for getting things done, I also think it's a great learning tool for users new to PW so I'd hate to make it harder to find for new users.

Then Alpine JS it is ?. Learn Vue, say thanks to the creators then say hello to Alpine JS. You will write its code right inside your ProcessWire inputfields, markup, whatever. Everything will be reactive. Make use of Inputfields->attr to assign Alpine properties. You might need the full attribute, e.g. 'x-on:change' instead of @change as ProcessWire might strip the latter out. Below is a quick example. I haven't checked it for errors. Inside your ProcessWire code. <?php // get a ProcessWire inputfield wrapper $wrapper = new InputfieldWrapper(); // get an inputfield text to store a name $field = $this->modules->get('InputfieldText'); // add some usual field values $field->name = 'your_name'; // OR // $field->attr('name', 'your_name') // etc... // let's alpinejs-it! $field->attr([ // MODEL THE VALUE DIRECTLY IN THE STORE // 'x-model' => "\$store.mystore.person.name", // OR HANDLE THE CHANGE YOURSELF // @note: ProcessWire will strip out the '@' - so we use x-on:event instead 'x-on:change' => "handleNameChange",// this is a method inside your Alpine data code ]); // IF YOU NEED TO.... // set a wrapper-level class, e.g., as a show-if // @note we escape some things here, e.g. the $ // could also use JavaScript template literals for the 'some_text', e.g. `some_text` // here we add a hidden class to the wrapper depending on some store value // we could have used x-show or x-if instead $class = "{ hidden: \$store.mystore.some_text==\"some_text\"}"; $field->wrapAttr( 'x-bind:class', $class, ); $wrapper->add($field); // initialise alpine js data // 'persons' could also be an object here, but for more complex objects, better to assign to a function in your code like this $out = "<div x-data='persons'>" . $wrapper->render() . "</div>"; return $out; You JavaScript // ALPINE (version 3+) document.addEventListener("alpine:init", () => { Alpine.store("mystore", { // YOUR STORE FIELDS // for some results results: [], some_text: "some_text", is_modal_open: false, person: {}, }) Alpine.data("persons", () => ({ handleNameChange(event) { this.changeCustomerName(event.target.value) }, changeCustomerName(name) { this.$store.mystore.person.name = name } })) }) Hope this helps.

Thanks, I'm glad you like it. ? The "Admin theme settings (Uikit)" options don't exist for the standard Fieldset fieldtype (FieldsetOpen) so that wouldn't work, and in any case the location of the module settings fields doesn't determine whether or not they can appear in template context. But in the newly released v0.1.6 I have added support for defining the Minimal Fieldset settings in template context so this should cover what you're wanting to do.

Glad you like it. ? Done, in v0.1.1.

I don't know if there is a better way to achieve the same result,I had (for a previous project) to insert : CKEDITOR.editorConfig = function( config ) { // Define changes to default configuration here. For example: config.protectedSource.push(/<i[^>]*><\/i>/g); config.enterMode = CKEDITOR.ENTER_BR; // I added this because I didn't want a new <p> tag on every new line, <br /> instead. }; CKEDITOR.dtd.$removeEmpty['i'] = false inside site\modules\InputfieldCKEditor\config-body.js (you shoud already have that file there). To be honest I don't know why this is necessary and doesn't work by default, but as far as I know it's not related to processwire, rather by Ckeditor itself.