Leaderboard

PAGEGRID 1 released!

The Bard field in Statamic has been been discussed and mentioned several times in the forums, dating all the way back to 2018, as something worth emulating in ProcessWire. Here is a short demo of a proof of concept of an unimaginatively (temporarily?) named (and very colourful) module doing just that. Demo App running outside ProcessWire. Screenshot Screenshot of the app in InputfieldBrad, running in a modal, quirks and all. Way Forward I don't know but no current plans for any sort of release, paid or otherwise. I like where @flydev ?? is headed with FieldtypeEditorJs so let's support that ?.

I often need to explain my clients that they need to be more precice with their bug reports and explain step by step what they did and what happened. Today a friend of mine shared a link of an austrian startup that wants to help in such situations with easy on-the-go screen/audio/video recording. https://recorder.calipio.com/home What do you guys think? I could think of a "support" button in the PW backend that opens that tool and sends the link directly to me via mail as a support request...

Tracy Console intalled too ?

Sorry solved... I'm little embarrassed, we have set the field option_type as single page ? not as a Multiple Pages PageArray now it works...

Sounds like you need to double check the name of the "option_type" field and check that it is set to support multiple values. Debugging this stuff is much easier with the Tracy Console because you can dump at each step of the process to figure out where the problem actually is.

There's no built-in option for that, but nearly everything is possible in PW with hooks and some lateral thinking. ? Below is one way you could achieve the goal. In my example I'm using "country" pages under a "countries" parent but the same idea will work for your case of children under the home page. Create a "multiple pages" Page Reference field named "top_pages" and add it to the template of the parent page. The field should be limited to the selection of child pages, so in "Selectable pages" set the "Selector string" option like this: Here "page" is a special keyword that means "the page that is currently being edited". Now edit the parent page and select the child pages you want to be sorted at the top. On the Children tab I have this: So I want the children sorted by title, apart from the children selected in the top_pages field. In /site/ready.php I have the following hooks, which affect the paginated listing of child pages in ProcessPageList: // Before ProcessPageList::find $wire->addHookBefore('ProcessPageList::find', function(HookEvent $event) { $selector_string = $event->arguments(0); $parent = $event->arguments(1); // Return early if the parent page doesn't include the top_pages field, or if the field is empty if(!$parent->hasField('top_pages') || !$parent->top_pages->count) return; // Convert selector string to Selectors object to make it easier to examine and modify $selectors = new Selectors($selector_string); $start = $selectors->get('field=start'); $limit = $selectors->get('field=limit'); // Return early if Selectors object does not conform to what is expected for some reason if(!$start || !$limit) return; // Get start and limit as integers $start_value = (int) $start->value; $limit_value = (int) $limit->value; if($start_value === 0) { // This is the first pagination // Reduce the limit by the count of the top pages $limit->value = $limit_value - $parent->top_pages->count; // Set a custom property on the ProcessPageList object // to indicate that the top pages should be prepended to the children $event->object->add_top_pages = true; } else { // This is not the first pagination // Reduce the start by the count of the top pages $start->value = $start_value - $parent->top_pages->count; } // Set the selector string argument to the string value of $selectors $event->arguments(0, (string) $selectors); }); // After ProcessPageList::find $wire->addHookAfter('ProcessPageList::find', function(HookEvent $event) { $parent = $event->arguments(1); // If there are top pages to add... if($event->object->add_top_pages) { // Prepend the top pages to the children $children = $event->return; $children = $parent->top_pages->add($children); $event->return = $children; // Unset the custom property now that the job is done unset($event->object->add_top_pages); } }); Result: Note: with this approach you must not select more "top pages" than the pagination limit for ProcessPageList (the default is 50).

that was exactly what I was looking for. I wasn't aware of the requiredAttr. Works like charm ? Thanks

Check the documentation: So it's an array of matched elements. But you don't need to do anything with it in your case - just return the replacement. You need to pass the variable that is holding the count by reference, as shown in my example.

And one more... Meet Brad, a proof-of-concept Bard Fieldtype ?.

There are a couple of blocks that I did not show. I can add another video to showcase those, when I find some time. In the meantime you can check out https://www.michael-philipp-bader.com/ to see them in the frontend. The home page (overview) for example features a gallery block that opens an image or video in a light box. On the contact page you can see a map block that uses the Leaflet Map Marker module. On the portfolio page there s a page reference block that loads all the selected pages/projects. I just want to be clear that it's up to the developer to create as many blocks as they like. Blocks can have all the fields that are available in PW. You just create a template and assign fields (like you normally do) and add that template to this fieldtype. Then you create a file with the name of that template in your template folder (or subfolder if you use the delegate template approach feature of this module) with the markup that gets rendered. You can also add a special class to elements you want to make draggable/resizable. More instructions on how to use this, with code examples will follow, once it's ready.

If anyone else is interested, I started researching different ways to try to solve this problem(not just with Processwire.) You can view the Google doc here. Feel free to copy/edit or whatever. I wonder if we can simplify things? Do we really want a layout editor in the Processwire backend where you can adjust the grid widths and so on, or do we just need some UI modifications to the tools we already have? Here's an example where I think the backend page editor is too complex. from:https://getkirby.com/ and https://modmore.com/contentblocks/ The page editor could slow down and be clunky from trying to render all the DOM elements? Too complex to work on mobile Content editing gets smushed into small columns Dragging and dropping across layout regions requires a lot of dexterity for the end users - think accessibility. requires taking up the whole page for editing A page/layout editor will have to somehow visually represent your frontend layout in the backend. That seems problematic to me. Instead of having a complex page/layout editor where the user has to drag and drop columns, how about we simplify the interface so that it works on mobile as well? While the YooTheme demo looks cool, I don't think it would work good on mobile? I think the YooTheme UI is still too complex. How about we just allow the user to choose from prebuilt sections or components? Those prebuilt sections/components could then be edited in the Processwire sidebar panel like the Processwire ProDrafts sidebar editing. It would be cool if the RepeaterMatrix, Page Reference, Page Table, Repeater fields got rid of all the cluttered "Add New" type links and instead had one "Add new" button/link that would give the option to choose a template visually in a Processwire Sidebar Panel. Maybe also add another option to RepeaterMatrix, Page Reference, Page Table, Repeater fields to edit pages in the Processwire Sidebar Panel instead of the inline expand/dropdown editing? Just like the Processwire ProDrafts module does with Live Preview? This is how Godaddy.com's website builder works. You can try it for free. When you click the plus icon to add a new section, it shows this selector in the sidebar. This is also how https://froont.com/ sidebar works. A user selects a prebuilt section or component/widget. Also http://cards2.webflow.io/ and https://froala.com/design-blocks and https://www.brizy.io/brizy-design-kit-2/ you can see how a page is built from these widgets/components that stack on top of each other. Imagine if I were to create a Processwire "Landing Page" template. It would probably only have 3 fields: Page Header - Single Select - to override the default site header Page Sections - Allow Multi Select - to add layout rows Page Footer - Single Select - to override the default site footer That would give a lot flexibility of the page design without allowing a user to screw up the design. When looking at the processwire page editor, it could show the three fields each containing a preview graphic of the element that was selected. Maybe @bernhard 's module would allow the visual selection of the templates somehow or maybe @ryan could add a representative/template preview image option to all the templates? The Sections field would allow multiple selections. Those selections would display in a single column like the Page Table field that allows you to move the preview graphic of the element that was selected up or down in the list. Maybe Page Table Extended could be used to show that preview graphic from the TemplatePreviewImages module? I haven't tried. If you click the preview graphic, it will open that element in the Processwire Sidebar Panel for editing. Here is a rough mockup of what it could look like: That way the page editing is nice and simple, no need to worry about messing with the indentation of nested elements like in this example: Indentation is too easy for editors to mess up IMHO. Now what happens if you click on the "Three Column" item above? It would open for editing in Processwire Sidebar Panel on the right. Now that "Three Column" page has other Page Reference fields to components/widgets: Column 1 - contains a RTE Editor widget using a limited/restricted CKeditor or a markdown editor? Column 2 - contains an Art Directed Responsive Image widget Column 3 - contains a Accordion widget with other types of referenced widgets like a Editorjs.io widget or a file downloads listing widget So that is where I'm not clear on. Do we need some mechanism to allow us to "Drill down" to edit other referenced pages in the sidebar? How do we go deeper? Could there be some kind of breadcrumbs or back button like on an iphone? The SilverStripe CMS has drill down editing as seen in this video at the https://youtu.be/IKGUd2dq8XI?t=1022 although it doesn't use sidebar editing. Technically, I'm not sure how they achieve that? Anyways, I don't have the solution, but I thought I would share those concepts as rough as they are. ? I also like Bernhard's concept of defining these widget/components in code so they can be shared across sites. Creating all these fields and templates by clicking in the admin would not be fun. No disrespect to Processwire. (I love Processwire and it's admin theme btw) I love hearing all the discussion on this. It's one huge problem that definitely needs solving. I need to able to give non technical users the ability to create customized landing pages without them knowing html. They like to be able to switch out a whole section just to see what it would look like. That's why I would prefer to give them the ability to select prebuilt responsive components instead of allowing them the ability to create grids with rows with margins and paddings and so much other htmly stuff.

I think Hanna Code is not a good candidate for solving this need. For a couple of reasons: 1. The Hanna Code textformatter does not necessarily only execute once when are outputting the field value in your template. It executes whenever the formatted value of the field is accessed. In practice I think you'll find this happens (or can happen) more than once in the same request (Ryan has pointed this out somewhere, and you can test it with Tracy Debugger) and so your counter incrementation is not going to be reliable. 2. You will be using the exact same tag [[nextimage]] multiple times within the field value. The Hanna Code textformatter uses a str_replace() to replace all matching tags in the field value. So it doesn't matter how you increment a counter within the Hanna tag code - all identical tags will get the same replacement value. Instead I think you should use your own placeholder and then do your own replacement (either in a template file or in a custom textformatter module). Example... In your field value, use the text {{nextimage}} inside a paragraph by itself. So the resulting markup would be <p>{{nextimage}}</p>. In your template file you can use preg_replace_callback(): $body = $page->body; $images = $page->images; $pattern = '/<p>{{nextimage}}<\/p>/'; $count = 0; $callback = function($matches) use (&$count, $images) { $out = ''; $image = $images->eq($count); if($image) { $out = "<img src='$image->url' alt='$image->title' title='$image->title'>"; } $count++; return $out; }; $body = preg_replace_callback($pattern, $callback, $body);

@fruid That error indicates that your PHP version doesn't support the null coalescing operator (??) which was introduced in PHP 7.0. Are you still using PHP 5.X? I would strongly recommend you upgrade to 7.3 or 7.4, the last 5.6 release has been end of life for over two years now! See the supported versions list on PHP.net. In the meantime, you can use the ternary operator instead: // get current image index from global variable, or start with zero on the first iteration $next = isset($GLOBALS['next_image']) ? $GLOBALS['next_image'] : 0; But again, please update to a supported PHP version ASAP.

This week I've been focused primarily on keeping up with the conversation about requests for 2021 and beyond, as well as doing related research here. We are starting to narrow in on ideas and plans, but there's more to cover still. Most of the conversation is happening in the PW 3.0.170 thread and last week's update thread. If you want to see what our preliminary roadmap looks like, Teppo did an amazing job covering it in the ProcessWire Weekly #348. I don't recall where it was or who asked, but I remember someone asking whether things like "thumbs up" quantities on GitHub issue reports and feature requests are paid attention to. And the answer is, not really so far. That's because GitHub doesn't display this info anywhere other than on the actual issue report. And even then, I often don't notice it. But this week I've been looking into it more and see that we can sort GitHub reports by quantity of thumbs-up votes. (Maybe the rest of you knew about this, but I guess I'm slow when it comes to GitHub). So it turns out that these thumbs-up votes aren't just social media fluff, they are actually very useful on issue reports and feature requests. Usually I cover these things newest-to-oldest, but now I'm going to start going through in order of votes, as this seems to make a lot more sense. Sorry I didn't catch this useful feature earlier. Please use the thumbs-up votes on GitHub for issue reports and feature requests that you value the most, and going forward, that will help us to cover them in a useful order. Next week I'm booked on a client project (working in PW), so it may be quiet for another week in terms of core updates, but then will be back to wrapping up our roadmap and ProcessWire development. Thanks for reading this far and have a great weekend!

Just my five cents (or fifty, looking at the length of this answer): There is zero interest here to move ProcessWire away from what it does now, or somehow get rid of the way it handles structured data. Absolutely zero. If you're worried that someone wants to thrash the system we now have and replace it with a Gutenberg clone, fear not: that will not happen, period. Now, as you've pointed out, there are different use cases. Almost all the sites I build and clients I work with nowadays require a "builder" approach: flexibility in terms of laying pages out. CKEditor goes to some extent here, but it's riddled with issues, and honestly the experience can be pretty horrendous: image management in particular is a lacklustre, and embedding any type of dynamic content (or anything CKEditor doesn't handle itself) gets difficult/technical (short codes with params etc.) A couple of reasons why comparing what we're doing to what WP is doing with Gutenberg makes little sense: In WordPress Gutenberg is going to replace the "classic editor", and it's also going to replace a lot of other built-in tools (such as menu management GUI) in the long term. The ultimate goal there is a "full site editor". This has very little to do with what we're discussing here. WordPress has never (natively) provided custom fields. Instead they have predefined fields and (freeform) page meta. ACF and similar plugins that make custom fields possible are popular, but page builders are even more so. It makes sense for the core team to extend the core with the tools that most users seem to want. I could get into the reasons why Gutenberg reviews are so bad — such as there being a lot of history, a lot of resistance to change, a lot of misunderstanding, likely mostly developer votes while the feature itself is aimed more at content editors, and so on — but I won't. My point is that improving the ability of ProcessWire to handle flexible layouts is not going to take anything away from those who don't want or need that. ProcessWire has many things that some users don't need or use. For an example, I've never used front-end editing for client sites. It's a feature I don't need, so I don't use it. It's as simple as that ? I'm going to cherry-pick one thing from this list: "I want to protect the entire site" ? I've worked on many completely non-public sites. While I believe I get the reasons @ryan has for not allowing the home page to be non-public, I would absolutely love for this to change. Even if it required a hook or config setting, that'd be a very nice addition. Currently I'm doing this with custom code, but there are some negative implications and I'm always a bit worried that it'll break: first of all it's (my) custom code and if something changes there's always a slight possibility that it won't work as expected, and second of all it needs to be done with hooks (to protect assets and make sure that nothing can interfere) and can thus sometimes get a bit complicated. TL;DR: if there was an option to somehow protect the entire site so that all non-authenticated requests (home page included) result in a login request, I'd be one happy user ?

Hi @ryan thanks for the great info about the future of PW from last week and thanks for the condensed list above. I agree with most of what's already been said, but want to add some points as I've been heavily working on several mentioned areas over the last year. IMPORTANT: Admin Theme As mentioned I've been working on a better admin experience for quite a long time. This is an example screenshot of RockSkinUikit (which I'm not using any more): My key goals have always been easy things: Make it easy to change ONE main color which does look good in most situations (because the secondary colors are gray) Make it easy to change the Logo Make it easy to add custom CSS/LESS -------- I am now using a custom Admin Theme module AdminThemeRock that does look similar to what I've built using RockSkinUikit: Again: Custom color, custom logo, that's it! -------------- Another one: Custom color, custom logo: ----------- Another one changing only the main color (page tree example): ------------- Learnings: If the core changes, my theme breaks!! That's a no-go. I've had to add several custom hacks to my theme that make it out of sync with the core. But important parts of the theme have not been hookable, so that was my only option meaning I have to pull all changes from the core into my admin theme module. I guess nobody else is as crazy as I am and that might be one major reason why we have not seen any other admin theme modules... My theme uses the old admin theme repo sources, because we do not have any source files in the core... https://github.com/ryancramerdesign/AdminThemeUikit/ PLEASE add the source files the core or in a separate repo that we can fork or help with PRs!! I've added you to my private repo on github so that you can see all the changes that where necessary for getting everything to work. For all others, here's an example of how my dirty core hacks look like: getNav() and getSearchform() are hookable methods that I added to my module. I've also built a frontend module that I'm using on my sites. There I use a simple but very effective technique that uses one single render() method to render several code blocks that I organize in files: // file structure foo |-- foo1.php '-- foo2.php bar |-- bar1.php '-- bar2.php // code echo $uk->render("foo/foo1"); echo $uk->render("bar/bar2"); This keeps the files organised and makes it very easy to do custom modifications before or after a file is rendered: $wire->addHookBefore("RockUikit::render(foo/foo1)", function ... ); $wire->addHookBefore("RockUikit::render(bar/bar2)", function ... ); Using a dom parser like https://github.com/paquettg/php-html-parser would even make it possible to modify/add/remove single html elements of the returned output! Of course having custom hooks would be more elegant and performant, but I wanted to mention this option nevertheless. Support for a Dashboard-Page That's another big thing for all my pages. I don't want to show the pagetree to logged in users unless they really want to see it! Take this simple example: Or this more beautiful one: The latter is taken from the Dashboard module which proves the big demand of the community for such a feature! I don't want to talk bad about this module here, I've shared my thoughts in the related thread with @d'Hinnisdaël and should maybe go for a beer with him when all this covid thing is over, but IMHO the module has two major drawbacks that would not be necessary! 1) It introduces a whole new concept to the PW admin that is already there. The PW admin is built upon inputfields and it would be very easy to build a dashboard (or to be more precise, the dashboard widgets) using these existing tools. (this is built using inputfields). 2) Making the admin show the dashboard instead of the pagetree feels hacky in several situations. We've discussed that here: One problem is, for example, that the breadcrumbs do not work as expected any more. Clicking on breadcrumb "bar" in " foo / bar / foobar " would take you to the dashboard and not to " foo / bar ". ############################################ Would be great: Migrations I think the core and all modules could benefit greatly from easy api migrations like I have built in my RockMigrations module. It's far from perfect, it's not very well documented, but it does some things right in my opinion and that's why I have it in all my installs and nowadays have it as requirement for almost all my modules that I build. Why? Because I want to have my fields under control of GIT Because I want to write an easy setup file that creates all fields/templates/pages that I add to this codeblock Because I want to push changes to my live server without exporting fields via mouseclicks, then updloading json files, then going through a migration click-marathon again, when I can simply do git pull & modules refresh Because I want to be able to create reusable components easily. I know that one can do all that using the standard PW API and creating a custom module, but take this example and see how easy and clear things get when using RockMigrations (or even better a solid core migrations API): I've recently added an example module that shows how I'm using RockMigrations now: https://github.com/BernhardBaumrock/RockMigrations/blob/master/examples/MigrationsExample.module.php ############################################ Brainstorming: ProcessWire without DB We all love ProcessWire and it's tools, but there's one drawback: The great API is only available if we have fully installed version of ProcessWire available. That has been a problem for me when I tried to work on a module that installs ProcessWire automatically (PW Kickstart and now working on RockShell). Examples of such classes that might be useful even without a DB connection could be: WireData WireFileTools WireRandom WireTextTools WireHttp Sanitizer I know that there are several cases where DB settings are absolutely necessary (for example page data or sanitzier settings), but there are other frameworks, that show, that such a concept can work and make a lot of sense: https://nette.org/ One might argue, that this might be going too far... But if we are talking about the future of PW, why not thinking of something like this: // copy files to root folder include("index.php"); $wire->install([ 'user' => 'demo', 'pw' => $wire->random->alphanumeric("8-12"), ... ]); Or take another example: https://processwire.com/api/ref/wire-mail/ There's no reason why we need a running PW instance with a DB connection for such a code example. Of course I know that it's technically required in many places in the core, but maybe these places could be identified and removed in the future?! Or maybe PW could support noSQL or something? ############################################ Would be great: A better Date/Time/Range-Field (dream: Support for recurring dates/ranges) I've started a discussion here and as you can see the post got a lot of attention: ProcessWires date field is nice, but it is a PAIN to work with date ranges, to build calender-like applications, to get the proper entries from the DB, etc... Why? Because the only option right now is to add TWO date fields to one template and there the problems begin... What if you want to make sure that one date is after the other? What if you want to show all events of one month? There's a HUGE potential for bugs like "foodate < $lastOfMonth" should have been "foodate <= $lastOfMonth" How to get the timestamp of $lastOfMonth properly? An API like https://carbon.nesbot.com/ would be great! What if events can have a range (like from 2021-01-10 to 2021-01-15), but can also be a single day event (2020-12-24). What if an event is on one day but has a start and end time (2020-12-14 from 18:00 to 22:00)? What about timezones? How to do the proper formatting? Showing a date like this "2020-12-24 18:00 to 2020-12-24 22:00" is a lot worse than "2020-12-24 18:00 - 22:00". This gets even more complicated when you want to show the days... What if you want/need to handle recurring events...? ############################################ PageBuilder I've taken several runs on that topic and finally (?) found a good solution during development of one large project last year. My approach was to make a new Fieldtype similar to Repeater and RepeaterMatrix, but with some big conceptual differences (it's more like Repeater than RepeaterMatrix): Every item is a single page in the tree and has a custom template Every repeater item can live anywhere in the pagetree Every item is defined in a single PHP file (using RockMigrations to make it reusable) This makes the setup very flexible on the one hand, makes it reusable across projects (simply copy the file and do a modules::refresh triggering the migrations) and makes it REALLY simple to use for the clients on the other hand: Setting up such a block is quite easy: class Headline extends \RockMatrix\Block { public function info() { return parent::info()->setArray([ 'icon' => 'header', 'title' => 'Überschrift', 'description' => 'Fügt eine Überschrift auf der Seite ein.', ]); } public function init() { $this->addHookAfter("Pages::saveReady", $this, "saveReady"); } // this method makes it easy to customize the item's edit-form // you can change labels, collapsed state, add notes or custom classes etc... public function buildForm($fs) { if($f = $fs->get('title')) { // dont show label for this inputfield $f->skipLabel = Inputfield::skipLabelMarkup; $f->wrapClass('rmx-pd5'); // add class to remove padding } } // the label of the repeater item public function getLabel() { return $this->title ?: $this->info()->title; } // migrations for this item public function migrate() { // the parent migrate creates the necessary template for this block parent::migrate(); // then we set the title field optional for this template $this->rm()->setFieldData("title", [ 'required' => 0, ], $this->getTpl()); } // code to use for rendering on the frontend public function render() { return "<h3 class='tm-font-marker uk-text-primary'>{$this->title}</h3>"; } // optional saveready hook public function saveReady(HookEvent $event) { $page = $event->arguments(0); if($page->template !== $this->getTpl()) return; if(!$page->id) { $page->title = "This is my initial headline"; } } } As you can see in the screenshot, I'm using CKEditor for editing fulltext. That's great, because I can remove all plugins that do usually need more education for clients (like inserting images) and build custom blocks solely for this purpose that every client can grasp a lot quicker and where I have a lot more control and freedom (since the block is a separate template). This means I've always had the freedom of custom image fields even before the image field supported them. Another example: A gallery block (headline + image field): I'm not sure about the scalability of this approach, but having all blocks as custom pages is a huge benefit in many ways. For example I could create a Matrix field having invoice items. Each item would be a page of type "invoiceitem" and then I could query all "invoiceitems" using RockFinder and build an average invoice NET or GROSS value of all invoices of 2020... Access control, page status, etc etc are still challenges though, of course. ####################### I hope that all makes sense and I'm willing to share any of my modules code if that helps. Or give you a demo/walkthrough via screenshare. One last question, as we are talking about the future of PW: One thing is what would happen to the core of PW if anything happend to you @ryan. But we could at least fork the core and do... whatever then would be necessary to keep all our businesses running and all our clients happy. But what about all the Pro modules? We could not get a copy of them and work on ProCache for example on our own (as a community). Did you think about that szenario and have a reassuring anwer for us? ? Of course, I wish you a long life and many happy years of developing PW - it's absolutely impressive what you have built here ?

my pleasure ?

Hi, This module does not appear to be compatible with the latest master. Seems the refactoring of InputfieldDatetime since 3.0.148 is the culprit. Failed to construct module: \InputfieldDatetimeAdvanced - Method InputfieldDatetimeAdvanced::getInputFormats does not exist or is not callable in this context I added getInputFormats() from a previous version of InputfieldDatetime and that appears to have fixed it: <?php /** * Get the input format string for the user's language * * thanks to @oliverwehn (#1463) * * @param bool $getString Specify true to get a format string rather than an array * @return array|string of dateInputFormat timeInputFormat * */ protected function getInputFormats($getString = false) { $inputFormats = array(); $language = $this->wire('user')->language; $useLanguages = $this->wire('languages') && $language && !$language->isDefault(); foreach(array('date', 'time') as $type) { $inputFormat = ''; if($useLanguages) { $inputFormat = trim($this->getSetting("{$type}InputFormat{$language->id}")); } if(!strlen($inputFormat)) { // fallback to default language $inputFormat = $this->get("{$type}InputFormat"); } $inputFormats[] = $inputFormat; } if($getString) return trim(implode(' ', $inputFormats)); return $inputFormats; } Cheers, Chris

Hi BitPoet, thank you for that module, I'm quite happy cause I just recognized that it's not possible to use a multiplierfield in formbuilder forms – so your solution looks promising. I tried it with a single textfield and it works as expected. Except if the form validation forces the form to load again. Than the multiplier fields get messed up (cloned again) – and after a second submit error the fields are empty. Is this maybe related to a version conflict or is the repopulation after submit-errors just not implemented? ProcessWire: 3.0.123 FormBuilder 40/ states 39(?), FormBuilder Fieldset Multiplier 0.0.6 Form embed used: template embed (option B) Thanks for any help or hint…

@wbmnfktr, @Valery, @pwired Thanks for suggestions. I managed to get the desired result with HTML Purifier. $dirty = pages(11896)->archive_wysiwyg; $purifier = $sanitizer->purifier(); $purifier->set('AutoFormat.RemoveEmpty', true); $purifier->set('AutoFormat.AutoParagraph', true); $purifier->set('AutoFormat.RemoveEmpty.RemoveNbsp', true); $purifier->set('CSS.AllowedProperties', array()); $purifier->set('HTML.ForbiddenAttributes', array('*@class', 'img@width', 'img@height')); $purifier->set('HTML.ForbiddenElements', array('span', 'strong')); $settings = $purifier->getConfig(); $def = $settings->getHTMLDefinition(); $def->info_tag_transform['h1'] = new HTMLPurifier_TagTransform_Simple('p'); $def->info_tag_transform['h2'] = new HTMLPurifier_TagTransform_Simple('p'); $def->info_tag_transform['h3'] = new HTMLPurifier_TagTransform_Simple('p'); $def->info_tag_transform['h4'] = new HTMLPurifier_TagTransform_Simple('p'); $def->info_tag_transform['h5'] = new HTMLPurifier_TagTransform_Simple('p'); $def->info_tag_transform['h6'] = new HTMLPurifier_TagTransform_Simple('p'); $clean = $purifier->purify($dirty); // do something

These are already excluded from the autocomplete as far as I can tell. // ProcessPageEditLink > Link to URL: exclude pages using templates without template file and unpublished pages $wire->addHookBefore('InputfieldPageAutocomplete(name=link_page_url)::render', function(HookEvent $event) { $inputfield = $event->object; $fileless_templates = []; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $fileless_templates[] = $template->id; } $inputfield->findPagesSelector .= ', status!=unpublished, template!=' . implode('|', $fileless_templates); }); // ProcessPageEditLink > Select Page / Select Child Page: prevent selection of pages using templates without template file and unpublished pages $wire->addHookAfter('ProcessPageEditLink::execute', function(HookEvent $event) { $css = '.PageListStatusUnpublished .PageListActionSelect, '; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $css .= ".PageListTemplate_{$template->name} .PageListActionSelect, "; } $css = rtrim($css, ', '); $css .= ' { display:none !important; }'; $event->return .= "<style>$css</style>"; });

There are different inputfields in ProcessPageEditLink and they need to be treated differently: Link to URL, Select Page, Select Child Page. For Link to URL I agree that there is probably no common use case that needs pages without template files to be visible/selectable here. For Select Page and Select Child Page, I think that pages without template files should appear there because those pages may have viewable child pages, and also I think it is easier for users to understand these inputfields if they show the same pages that they are familiar with from ProcessPageList where non-viewable pages are listed. But the pages without template files should not be selectable as links. I suggest you raise a GitHub request or issue to ask for a change to this. In the meantime here are a couple of workaround hooks for /site/ready.php: // ProcessPageEditLink > Link to URL: exclude pages using templates without template file $wire->addHookBefore('InputfieldPageAutocomplete(name=link_page_url)::render', function(HookEvent $event) { $inputfield = $event->object; $fileless_templates = []; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $fileless_templates[] = $template->id; } $inputfield->findPagesSelector .= ', template!=' . implode('|', $fileless_templates); }); // ProcessPageEditLink > Select Page / Select Child Page: prevent selection of pages using templates without template file $wire->addHookAfter('ProcessPageEditLink::execute', function(HookEvent $event) { $css = ''; foreach($this->wire()->templates as $template) { if(!$template->filenameExists()) $css .= ".PageListTemplate_{$template->name} .PageListActionSelect, "; } if($css) { $css = rtrim($css, ', '); $css .= ' { display:none !important; }'; $event->return .= "<style>$css</style>"; } });

Not sure if this does what you want: https://ionicframework.com/docs/native/push/