Leaderboard

Also, there is a counter option built into PW for all textarea fields:

Perhaps I'm missing the point, but this should be the easy part. Maybe something along these lines: <?php $current_date = null; $items = $pages->find('template=news-item, sort=date_field, start=0, limit=20'); if ($items->count()) { foreach ($items as $item) { $date = date('j.n.', $item->getUnformatted('date_field')); if ($date !== $current_date) { if ($current_date !== null) echo "</ul>"; echo "<h3>{$date}</h3><ul>"; $current_date = $date; } echo "<li>{$item->title}</li>"; } echo "<ul>"; } It's a bit crude and probably wouldn't work as-is with your infinite scroll approach, but that's the basic idea anyway ?

Windows Terminal has been released and can be downloaded from the Microsoft Store. Article: https://www.theverge.com/2019/6/22/18701365/microsoft-windows-terminal-10-download-store-features WSL (WSL2 in the near future) + VSCode + Terminal... Microsoft is awesome.

@BitPoet's groupBy() hook is nice for this sort of thing. As with @teppo's suggestion, you'd have to do a bit more to get it working with infinite scroll (the limit might fall in the middle of a day, in which case you wouldn't want the day heading added again on the next pagination).

MarkupMenu is a markup module for generating menu trees. When provided a root page as a starting point, it generates a navigation tree (by default as a HTML "<ul>" element wrapped by a "<nav>" element) from that point onwards. If you've also provided it with current (active) page, the menu will be rendered accordingly, with current item highlighted and items rendered up to that item and its children (unless you disable the "collapsed" option, in which case the full page tree will be rendered instead). Modules directory: https://modules.processwire.com/modules/markup-menu/ GitHub repository: https://github.com/teppokoivula/MarkupMenu Usage As a markup module, MarkupMenu is intended for front-end use, but you can of course use it in a module as well. Typically you'll only need the render() method, which takes an array of options as its only argument: echo $modules->get('MarkupMenu')->render([ 'root_page' => $pages->get(1), 'current_page' => $page, ]); Note: if you omit root_page, site root page is used by default. If you omit current_page, the menu will be rendered, but current (active) page won't be highlighted etc. A slightly more complex example, based on what I'm using on one of my own sites to render a (single-level) top menu: echo $modules->get('MarkupMenu')->render([ 'current_page' => $page, 'templates' => [ 'nav' => '<nav class="{classes} menu--{menu_class_modifier}" aria-label="{aria_label}">%s</nav>', 'item_current' => '<a class="menu__item menu__item--current" href="{item.url}" tabindex="0" aria-label="Current page: {item.title}">{item.title}</a>', ], 'placeholders' => [ 'menu_class_modifier' => 'top', 'aria_label' => 'Main navigation', ], 'include' => [ 'root_page' => true, ], 'exclude' => [ 'level_greater_than' => 1, ], ]); Note: some things you see above may not be entirely sensible, such as the use of {menu_class_modifier} and {aria_label} placeholders. On the actual site the "nav" template is defined in site config, so I can define just these parts on a case-by-case basis while actual nav markup is maintained in one place. Please check out the README file for available render options. I'd very much prefer not to keep this list up to date in multiple places. Basically there are settings for defining "templates" for different parts of the menu (list, item, etc.), include array for defining rules for including in the menu and exclude array for the opposite effect, classes and placeholders arrays for overriding default classes and injecting custom placeholders, etc. ? MarkupMenu vs. MarkupSimpleNavigation TL;DR: this is another take on the same concept. There are many similarities, but also some differences – especially when it comes to the supported options and syntax. If you're currently using MarkupSimpleNavigation then there's probably no reason to switch over. I'd be surprised if someone didn't draw lines between this module and Soma's awesome MarkupSimpleNavigation. Simply put I've been using MSN (...) for years, and it's been great – but there are some issues with it, particularly in the markup generation area, and it also does some things in a way that doesn't quite work for me – the xtemplates thing being one of these. In some ways less about features, and more about style, I guess ? Anyhow, in MarkupMenu I've tried to correct those little hiccups, modernise the default markup, and allow for more flexibility with placeholder variables and additional / different options. MarkupMenu was built for ProcessWire 3.0.112+ and with PHP 7.1+ in mind, it's installable with Composer, and I have a few additional ideas (such as conditional placeholders) still on my todo list. One more small(ish) difference is that MarkupMenu supports overriding default options via $config->MarkupMenu. I find myself redefining the default markup for every site, which until now meant that each site had a wrapper function for MarkupSimpleNavigation (to avoid code / config repetition), and this way I've been able to leave that out ? Requirements ProcessWire >= 3.0.112 PHP >= 7.1.0 If you're working on an earlier version of ProcessWire or PHP, use MarkupSimpleNavigation instead.

I don't know how to do this in PW, but I'm guessing something like GROUP BY in mysql should work. Check RockFinder I see some examples: https://github.com/BernhardBaumrock/RockFinder#custom-sql-aggregations-groupings-distincts

Well, a real linux kernel inside windows... And proper copy&paste. And having one single config json sounds awesome. Hope that principle will find its way to VSCode, then it would finally be really easy to share your dev environment across multiple machines ?

Interesting, thx for sharing!

Just add this plugin: https://ckeditor.com/cke4/addon/wordcount Or use AdminOnSteroids module which comtains this plugin.

I have no experience with this Tribe events thing, so can't speak for that, but for the bulk of the content I'd recommend skipping the database export idea and going with the built-in REST API. While the REST API has its quirks, going directly to database for exports is going to be a major pain in the a*s in comparison. Not entirely unlike exporting ProcessWire content with raw SQL... ? It would be best to have a separate copy of the site at hand first, but after that it's basically as simple as installing the ACF to REST API plugin (which adds ACF field data to the REST API results) – and of course making sure that the REST API is enabled in the first place. You should be able to query and export all your pages, articles, and any custom post types with this method. Once you have the data, importing it to ProcessWire is going to be a breeze. (Note: based on some quick googling the Tribe events plugin also provides REST API support. I haven't used this, but it looks promising.) Also, in case that idea won't pan out, you can always rely on existing solutions, such as WP All Export (which provides a GUI for exporting content, including ACF data). Admittedly I haven't worked with this plugin before, but it's the companion plugin for WP All Import, the de facto standard plugin solution for complex imports. WP All Import is a bit of a monster and can feel clunky (hence devs often prefer custom imports for long-running, often-used, scheduled stuff), but for one-off cases it's a really handy tool. -- Edit: in case anyone is wondering, the WP REST API was first announced on June 17th 2013, which would be a week or so after Ryan started this thread. It didn't make it's way into the core until 2015, and even then it was for a very long time considered "a work in progress". It's been more than five years since this thread was started, so it shouldn't come as a big surprise that some things have changed ?

ProcessWire InputfieldRepeaterMatrixDuplicate Thanks to the great ProModule "RepeaterMatrix" I have the possibility to create complex repeater items. With it I have created a quite powerful page builder. Many different content modules, with many more possible design options. The RepeaterMatrix module supports the cloning of items, but only within the same page. Now I often have the case that very design-intensive pages and items are created. If you want to use a content module on a different page (e.g. in the same design), you have to rebuild each item manually every time. This module extends the commercial ProModule "RepeaterMatrix" by the function to duplicate repeater items from one page to another page. The condition is that the target field is the same matrix field from which the item is duplicated. This module is currently understood as proof of concept. There are a few limitations that need to be considered. The intention of the module is that this functionality is integrated into the core of RepeaterMatrix and does not require an extra module. Check out the screencast What the module can do Duplicate multible repeater items from one page to another No matter how complex the item is Full support for file and image fields Multilingual support Support of Min and Max settings Live synchronization of clipboard between multiple browser tabs. Copy an item and simply switch the browser tab to the target page and you will immediately see the past button Support of multiple RepeaterMatrix fields on one page Configurable which roles and fields are excluded Configurable dialogs for copy and paste Duplicated items are automatically pasted to the end of the target field and set to hidden status so that changes are not directly published Automatic clipboard update when other items are picked Automatically removes old clipboard data if it is not pasted within 6 hours Delete clipboard itself by clicking the selected item again Benefit: unbelievably fast workflow and content replication What the module can't do Before an item can be duplicated in its current version, the source page must be saved. This means that if you make changes to an item and copy this, the old saved state will be duplicated Dynamic loading is currently not possible. Means no AJAX. When pasting, the target page is saved completely No support for nested repeater items. Currently only first level items can be duplicated. Means a repeater field in a repeater field cannot be duplicated. Workaround: simply duplicate the parent item Dynamic reloading and adding of repeater items cannot be registered. Several interfaces and events from the core are missing. The initialization occurs only once after the page load event Attention, please note! Nested repeaters cannot be supported technically. Therefore a check is made to prevent this. However, a nested repeater can only be detected if the field name ends for example with "_repeater1234". For example, if your MatrixRepeater field is named like this: "content_repeater" or "content_repeater123", this field is identified as nested and the module does not load. In version 2.0.1 the identification has been changed so that a field ending with the name repeater is only detected as nested if at least a two-digit number sequence follows. But to avoid this problem completely, make sure that your repeater matrix field does NOT end with the name "repeater". Changelog 2.0.1 Bug fix: Thanks to @ngrmm I could discover a bug which causes that the module cannot be loaded if the MatrixRepeater field ends with the name "repeater". The code was adjusted and information about the problem was provided 2.0.0 Feature: Copy multiple items at once! The fundament for copying multiple items was created by @Autofahrn - THX! Feature: Optionally you can disable the copy and/or paste dialog Bug fix: A fix suggestion when additional and normal repeater fields are present was contributed by @joshua - THX! 1.0.4 Bug fix: Various bug fixes and improvements in live synchronization Bug fix: Items are no longer inserted when the normal save button is clicked. Only when the past button is explicitly clicked Feature: Support of multiple repeater fields in one page Feature: Support of repeater Min/Max settings Feature: Configurable roles and fields Enhancement: Improved clipboard management Enhancement: Documentation improvement Enhancement: Corrected few typos #1 1.0.3 Feature: Live synchronization Enhancement: Load the module only in the backend Enhancement: Documentation improvement 1.0.2 Bug fix: Various bug fixes and improvements in JS functions Enhancement: Documentation improvement Enhancement: Corrected few typos 1.0.1 Bug fix: Various bug fixes and improvements in the duplication process 1.0.0 Initial release Support this module If this module is useful for you, I am very thankful for your small donation: Donate 5,- Euro (via PayPal – or an amount of your choice. Thank you!) Download this module (Version 2.0.1) > Github: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate > PW module directory: https://modules.processwire.com/modules/inputfield-repeater-matrix-duplicate/ > Old stable version (1.0.4): https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDuplicate/releases/tag/1.0.4

We recently rebuilt the Architekturführer Köln (architectural guide Cologne) as a mobile-first JavaScript web app, powered by VueJS in the frontend and ProcessWire in the backend. Concept, design and implementation by schwarzdesign! The Architekturführer Köln is a guidebook and now a web application about architectural highlights in Cologne, Germany. It contains detailled information about around 100 objects (architectural landmarks) in Cologne. The web app offers multiple ways to search through all available objects, including: An interactive live map A list of object near the user's location Filtering based on architect, district and category Favourites saved by the user The frontend is written entirely in JavaScript, with the data coming from a ProcessWire-powered API-first backend. Frontend The app is built with the Vue framework and compiled with Webpack 4. As a learning exercise and for greater customizability we opted to not use Vue CLI, and instead wrote our own Webpack config with individually defined dependencies. The site is a SPA (Single Page Application), which means all internal links are intercepted by the Vue app and the corresponding routes (pages) are generated by the framework directly in the browser, using data retrieved from the API. It's also a PWA (Progressive Web App), the main feature of which is that you can install it to your home screen on your phone and launch it from there like a regular app. It also includes a service worker which catches requests to the API and returns cached responses when the network is not available. The Architekturführer is supposed to be taken with you on a walk through the city, and will keep working even if you are completely offline. Notable mentions from the tech stack: Vue Vue Router for the SPA functionality VueX for state management and storage / caching of the data returned through the API Leaflet (with Mapbox tiles) for the interactive maps Webpack 4 for compilation of the app into a single distributable Babel for transpilation of ES6+ SASS & PostCSS with Autoprefixer as a convenience for SASS in SFCs Google Workbox to generate the service worker instead of writing lots of boilerplate code Bootstrap 4 is barely used here, but we still included it's reboot and grid system Backend The ProcessWire backend is API-only, there are no server-side rendered templates, which means the only PHP template is the one used for the API. For this API, we used a single content type (template) with a couple of pre-defined endpoints (url segments); most importantly we built entdpoints to get a list of all objects (either including the full data, or only the data necessary to show teaser tiles), as well as individual objects and taxonomies. The API template which acts as a controller contains all the necessary switches and selectors to serve the correct response in <100 lines of code. Since we wanted some flexibility regarding the format in which different fields were transmitted over the api, we wrote a function to extract arbitrary page fields from ProcessWire pages and return them as serializable standard objects. There's also a function that takes a Pageimage object, creates multiple variants in different sizes and returns an object containing their base path and an array of variants (identified by their basename and width). We use that one to generate responsive images in the frontend. Check out the code for both functions in this gist. We used native ProcessWire data wherever possible, so as to not duplicate that work in the frontend app. For example: Page names from the backend translate to URLs in the frontend in the form of route parameters for the Vue Router Page IDs from ProcessWire are included in the API responses, we use those to identify objects across the app, for example to store the user's favourites, and as render keys for object lists Taxonomies have their own API endpoints, and objects contain their taxonomies only as IDs (in the same way ProcessWire uses Page References) Finally, the raw JSON data is cached using the cache API and this handy trick by @LostKobrakai to store raw JSON strings over the cache API. Screenshots

Repeater Images Adds options to modify Repeater fields to make them convenient for "page-per-image" usage. Using a page-per-image approach allows for additional fields to be associated with each image, to record things such as photographer, date, license, links, etc. When Repeater Images is enabled for a Repeater field the module changes the appearance of the Repeater inputfield to be similar (but not identical) to an Images field. The collapsed view shows a thumbnail for each Repeater item, and items can be expanded for field editing. Screencast Installation Install the Repeater Images module. Setup Create an image field to use in the Repeater field. Recommended settings for the image field are "Maximum files allowed" set to 1 and "Formatted value" set to "Single item (null if empty)". Create a Repeater field. Add the image field to the Repeater. If you want additional fields in the Repeater create and add these also. Repeater Images configuration Tick the "Activate Repeater Images for this Repeater field" checkbox. In the "Image field within Repeater" dropdown select the single image field. You must save the Repeater field settings to see any newly added Image fields in the dropdown. Adjust the image thumbnail height if you want (unlike the core Images field there is no slider to change thumbnail height within Page Edit). Note: the depth option for Repeater fields is not compatible with the Repeater Images module. Image uploads feature There is a checkbox to activate image uploads. This feature allows users to quickly and easily add images to the Repeater Images field by uploading them to an adjacent "upload" field. To use this feature you must add the image field selected in the Repeater Images config to the template of the page containing the Repeater Images field - immediately above or below the Repeater Images field would be a good position. It's recommended to set the label for this field in template context to "Upload images" or similar, and set the visibility of the field to "Closed" so that it takes up less room when it's not being used. Note that when you drag images to a closed Images field it will automatically open. You don't need to worry about the "Maximum files allowed" setting because the Repeater Images module overrides this for the upload field. New Repeater items will be created from the images uploaded to the upload field when the page is saved. The user can add descriptions and tags to the images while they are still in the upload field and these will be retained in the Repeater items. Images are automatically deleted from the upload field when the page is saved. Tips The "Use accordion mode?" option in the Repeater field settings is useful for keeping the inputfield compact, with only one image item open for editing at a time. The "Repeater item labels" setting determines what is shown in the thumbnail overlay on hover. Example for an image field named "image": {image.basename} ({image.width}x{image.height}) https://github.com/Toutouwai/RepeaterImages https://modules.processwire.com/modules/repeater-images/

? ? ? ? ? Ok...now this changes everything. Unfortunatelly... I have no idea right now. ?

Same here... Win/Chrome, Win/Firefox. There aren't that much dates/days but it seems to work pretty well. Or I don't understand the problem.

In Win / Chrome it looks exactly like your screenshot. Styling and inf. scroll seem to work just fine. What are you testing with, and how does it look like on your end?

You could try the language-alternate fields method. It works pretty well with images, maybe it works with the comment field as well. On the other hand... why is it so bad to have a discussion in several languages below an article? It's actually the same content only in different languages. So why hide opionions that are in another language? But hey... it's your project. ?

I mean the cmd in windows by now is missing a lot of basic stuff ?

Thanks @Robin S, somehow I thought the built-in one didn't work for CKEditors but it's not true. Just tried it and worked fine for a multi-language field as well, and showed the same values as the CKEditor plugin. According to the CKEditor plugin's documentation it offers more advanced configuration though.

I tried a lot of them before: Ampps, EasyPHP, Fenix, HFS, UniForm, USB, Laragon, UWamp, Wamp and ZWamp. For me Laragon came definitely out as the best in: 1) easy interface 2) simple switching between php versions 3) auto virtual hosts 4) speed 5) stability

Because it brings a lot of tools out of the box and makes everything really simple: New project --> create a new folder and klick reload MySQL --> HeidiSQL on board Testing E-Mails --> Mailcatcher on board Share your current work with a client --> ngrok on board But yes, sometimes it would be great to have a "real" linux machine for development. I've never tried WSL, but I've tried devilbox and came back to laragon because of its simplicity.

In contrast to you and several others here my focus is more towards frontend development, some technical SEO stuff and only a few bits of real programming. Some hooks, some minor module stuff but nothing fancy. So I looked for something that is super easy to use with everything I need for my jobs. I used and tested a lot of tools but at the end I stayed with Laragon as it's doing exactly what I need. In the last few days I started to use PW Kickstart from @bernhard which adds another layer of comfort to my workflow. As it works as expected I feel no need to change my setup.

That's a nice addition to Bracket Pair Colorizer 2.

Is there a reason why you guys use Laragon instead of WSL? I used WampServer for years, but like Laragon, its using the Windows version of Apache, MySQL and PHP. While that works, I feel the Windows versions of those will always be second class. Add in things like node and Windows' character limits for file paths (which I think has now been resolved) and it gets more dicey. Also, it's probably slower. I don't use a Mac or Linux, so when WSL came out, Microsoft basically fixed a huge problem for people like us (Windows users doing non-Windows development... that is, LAMP stuff). Why not just use WSL? You get rsync and all the Linux utilities that I don't know how I lived without. There's a little bit of initial setup, but I've boiled that down into 10 minutes with a set of commands that'll make ProcessWire run perfectly.

I discovered indent-rainbow today: https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow I don't like visual distractions when coding, and I thought this might contribute to that, but the colors are very very subtle so I'm keeping this one installed.

That can definitely be a bit of a pain, and applies to any migration really ? The good thing about the way WordPress handles internal links is that they are all (assuming they've not been modified via hooks or plugins, and a plugin hasn't been producing loads of "non-standard" links) absolute URLs with predefined prefix for each custom post type, and as such – in a lot of cases – you can just run a string replace on the exported data. If you're working on a copy of the site, you can also use WP-CLI (if you have it installed) and run something like "wp search-replace 'https://OLD' 'https://NEW' --all-tables" before the export. Of course if you move things around a lot, it's not going to be quite as simple.

Googlebot is clever these days. JS-content is no problem for indexing anymore (React, Angular, Vue etc.). Meta tags and page titles are adjusted for every page-view (something a lot of developers simply forget when building SPAs). Of course, you could always improve SEO, e.g. creating a sitemap.xml... https://www.smashingmagazine.com/2019/05/vue-js-seo-reactive-websites-search-engines-bots/ ^ a good read about the subject

@bernhard It's a little trick you can do with Google Chrome: In the responsive view mode, select one of the iPhone models in the responsive mode settings bar. In the flyout menu on the upper right, there's an option "show device frame". Only works with some of the devices, I've used "iPhone 6/7/8 Plus". If you take a screenshot (via the same flyout menu) while in responsive design mode with the show device frame option turned on, the device frame will be included in the screenshot.

@netcarver Thanks! @bernhard Thank you for the QA ? Regarding the "back" button, I tried to make it more intelligent, but I got stuck on the history API not having a reliable way to check the last items. I thought about turning it off only on the homepage, but I wanted to have a way to go back to the last page if you go e.g. from an object detail page to the homepage and want back to the object. I'd have to track the last history states manually, since the Vue Router just wraps around the history API and doesn't keep a memory of itself. I'll put that back on the to do list! As for the share button, we only have that on the object pages in the subnavigation; it would take up to much space too have it on the bottom all the time. Maybe we can put it at the end of every page, or in the navigation. Though it's only supported in Chrome on Android and Safari at the moment, and most browsers have their own native sharing button, so it wasn't the most important feature to us. @pwired Thank you so much! ?

This looks absolutely brilliant! Congratulations for this great work and thanks for sharing it with us! I've also tried it on my phone and everything just worked ? One thing that was counter intuitive for me was the left arrow icon on the top left corner of the frontpage. On all other pages this icon means "back", on the frontpage there is no "back" of course, but I didn't realize that I was on the frontpage, so it might make sense to remove the icon there? Another thing: I wanted to share the app with a friend, but the share icon is only available on sub-pages.

@MrSnoozles and everyone! This project is certainly halted at the moment and we are discussing what to do with it. We have not publish because one of our original intentions was to make it a Pro module. We still need to clear our heads from work and decide what to do.

I recently mentioned that I was working (more like messing about quickly :-)) on a Visualisation module based on the awesome chart lib Vega. I haven't touched this module in a while. I only realised today as I was transferring my dev setup to WampServer and testing things out that I'd left this off at a stage where one could view a basic Viz. See the screenshots below. Word of warning: this does not even qualify as pre-alpha in my opinion. It is very early days. It is more of a playground to test ideas. It's also not high in my list of priorities so I don't know when it will be ready... Screenshots Create new viz from list of pre-built visualisations/charts Editing a single visualisation/chart

I have started a topic in Repeater Matrix closed support board with a request to make it possible to override InputfieldRepeaterMatrix::renderFooter method in a hook. This way we can probably implement any kind of add content type design without css overrides.

I guess it's just CSS? a.InputfieldRepeaterAddLink.InputfieldRepeaterMatrixAddLink.InputfieldRepeaterAddLinkInit[data-type="3"] { font-size: 0; width: 150px; height: 100px; display: inline-block; background-image: url(https://via.placeholder.com/150); background-repeat: no-repeat; } span.ui-priority-secondary { display: none; }

Hello @Michael van Laar, To answer you main question first: Yes, I don't see a performance issue in using either. The RepeaterMatrix and PageTable field are similar in that they use pages which can be used for content elements. I prefer the RepeaterMatrix field, because it has a better usability in that you can edit the content elements on the same page. Before there was the RepeaterMatrix field, I also used for a few times the PageTable field with the PageTableExtend module. But if you have bought the ProFields I would recommend using the RepeaterMatrix. On the back-end it is best when using a RepeaterMatrix field to have the default option on, that all repeater items should be loaded via Ajax. I assume the page you linked is not cached? According to WebPagetest the document was loaded after 670ms, which is good (best would be under 300ms). Everything after that are your styles and scripts which are not related to the RepeaterMatrix. For a regular XML sitemap, you would just output all visible pages on your website. So in your example that would be around 150 pages. But even more should be no issue. I usually use the module MarkupSitemapXML for this. With other sitemap formats I have not much experience, I have just learned about them: Image sitemap: You could output the link of a page and all it files like this. Video sitemap: This seems to work only with self hosted videos. So not embeded videos. But I could be done like mentioned before. All of those solutions mentioned are decoupled from the RepeaterMatrix and PageTable field. On every page you only output the content elements used for the page. So the total count of content elements wouldn't matter. If you have a page with 10 or 50 content elements, it should not really be a performance issue. I can think of no use case, where you would output all content elements of all pages at the same time. As mentioned before the sitemap example can be handled without have to deal with RepeaterMatrix or PageTable. Yes, thats what the RepeaterMatrix field is build for. Caching always helps if you don't have user input on your page. But depending on how you build your templates, without cache there should be no performance issue. For content elements I can't think of a better solution than RepeaterMatrix. If you have more questions, it would be best if you would share some screenshots of your set-up. ? Regards, Andreas

Actually class_exists() should work, but WillyC missed an important part. ProcessWire doesn't include module files that aren't autoload unless some information about them is requested, like $modules->getModuleInfo("className"), or the like. In the same manner, a class_exists("className"); call triggers the autoload mechanism and causes the file to be loaded. But you can prevent that by specifying false as argument 2 to class_exists(): if(!class_exists("ModuleName", false)) { // module is not loaded }

The "missing required value" string is translatable in the file /wire/core/InputfieldWrapper.php. For your language pack, you would add this file as a translation target.