Leaderboard

This week we have some major improvements to our core date/time Inputfield, as well as a new ability to specify your own custom classes for Page objects. Read on for all the details and examples— https://processwire.com/blog/posts/pw-3.0.152/

If all embeds are iframes, I would only use a text field for the URL. There's also this textformatter module or a CKE plugin I would check out.

Memo to myself and mybe to safe someone else from losing hours trying to understand why a multi-language Inputfield does not render() as expected... Learnings: 1) Inputfield::render() is only hookable for single-language Inputfields! When PW renders a multi-language Inputfield the LanguageSupport module adds a hook that fires after the original Inputfield::render(). This hook calls the render() method for each language and to avoid circular references it does that directly on $inputfield->___render() and not $inputfield->render(): https://github.com/processwire/processwire/blob/51629cdd5f381d3881133baf83e1bd2d9306f867/wire/modules/LanguageSupport/LanguageSupport.module#L445-L453 2) When building a custom Inputfield that supports a multi-language setup it is critical that its render() method is defined with 3 underscores! Otherwise the LanguageSupport hook that adds the markup for the other languages' fields would not fire.

Thank you. I did try most of the different ways of including files. The problem wasn’t with the include itself which was working fine. The include itself was running some PW selectors and dynamically populating some variables critical to the rest of the page content. Seems that with a standard include things weren’t loading in the order I needed for this to work, but using an appended init file works fine ?

Can you post the code in your graphql.php template file. My only guess is that something happening in that file.

Hi there I made a change in core/WireInputData.php to allow for a config option to allow multidimensional arrays (created a pull request as below). https://github.com/processwire/processwire/pull/161 I posted this in another topic but realised it hadn't been visited for over a year, so thought I'd start another. I understand the reasoning behind keeping the arrays one dimensional by default, but rather than resorting to having to use raw $_POST arrays etc. I thought a useful compromise would be a config variable to enable the behaviour override. To use, just set $config->wireInputMultiDimensional to true. @ryan is there any chance of this being pulled (or a cleaner/better version)?

@Zeka Thanks, I think I tracked down the issue (caching issue that occurs only when multiple date fields) and have pushed a fix on the dev branch. @szabesz From your /site/init.php you can set the location with $config->setLocation('classes', 'path/to/classes/'); for example $config->setLocation('classes', 'site/templates/classes/'); You can also use the method mentioned earlier by adding your own directories to the $classLoader. However, the more potential locations there are for something, the more overhead, so I would recommend sticking to the $config->setLocation() and keep all of your classes in one directory. This keeps everything fast and efficient. If that's the case, then you would have to add locations with the $classLoader and accept the overhead of doing so (though it's probably negligible so long as things don't grow too much). But I also think with that kind of structure, things look isolated when it comes to reusability, limiting their usefulness. That may be fine for your use case, but as far as classes go, one of the primary purposes is reuse and extending one another where appropriate, so you ideally want to keep them together. @bernhard ProcessWire preloads a few pages on every request, since they always get used. Preloaded pages are loaded as a group rather than individually, enabling it to boot faster. This happens before the init state for modules, so a module will not have the opportunity to specify a class for these preloaded pages, but a file in /site/classes/ will. See the $config->preloadPageIDs setting for a list of what those pages are. But essentially they are the homepage, admin root page, guest user+role, and superuser role. For your case, it sounds like only the homepage is a consideration here. I would suggest just asking PW to uncache the homepage at your module's init() state. This should force it to reload (when it's next requested) using your custom class. $homePage = $this->pages->cacher()->getCache(1); if($homePage) $this->pages->uncache($homePage); You can also use $config->setLocation() for this, i.e. $config->setLocation('fieldTemplates', 'site/templates/my-custom-directory/'); I think this is fine if you are just doing it once or twice, but if you find you are repeating yourself, typing out "/articles/fields" or similar in multiple places, then you always want to abstract away stuff like that into a single location so that if you ever need to change it, you change it in just one place. PHP functions are ideal for this. This will be simple to do, but when it comes to the directory and file names that you are using, I recommend using the exact same names that you do with your templates and fields, which will make it a simple matter to abstract away repetitive code or locations into functions. "All these directories" are 3 directories, 2 of which are for optional features that are disabled by default — the absolute minimum number of directories necessary to support these things. ProcessWire is focused in what is the most simple, efficient, familiar (as it relates to the admin), and maximizes reusability. It's not opinionated about it outside of those factors. For something like field-templates, a primary purpose of having them is so that you can reuse them across different templates (to avoid repeating yourself); otherwise they aren't that useful. For the structure that you appear to be using, it looks to me like your intention is to isolate them by template, so why have them at all? If the purpose is code/markup isolation (which is still worthwhile) then I think just using an include() or $files->render(); would be preferable, more efficient and flexible for your use case. So that's what I'd recommend there. The same goes for the new page classes—if you are isolating these things in the way you've suggested, it'll be confusing for classes to extend one another or be shared across multiple templates, and it'll take more overhead for PW to find them. If you don't intend to use them like that, maybe they can still be useful, but not nearly as much so. So at that point I would reconsider whether you want/need custom Page classes. Basically, you are using a highly opinionated structure for your site files, and that can be a good thing because you've decided where everything goes and have a plan/system for how it will grow in terms of your file structure. ProcessWire is built to support a lot of different types of websites and applications, and at any scale. But it's not opinionated about this stuff beyond the bare minimum, precisely so that you can be as opinionated as much as you want with your own projects. That's why you are able to build a more complex structure for your files that suits your need, and also why it's also just as suited for others that might prefer a simpler structure in their projects. There's also no need to feel obligated to use things like field templates or custom page classes just because they are there. The point of these features is to reduce redundancy and prevent you from having to repeat yourself. But you may have your own preferred ways of doing that—whether it's with functions, file/directory structure, or anything else, it's all perfectly fine in PW. A template file receiving a $page is the only assumption needed in ProcessWire and everything else is optional. So use these things when they help you do that, and avoid using them when they don't. The reason these features are disabled by default is because not everyone needs them. Personally, the only time I use field templates is for multi-value fields with lots of properties, like repeaters, where I need to reuse the same output/markup across multiple template files. Though custom Page classes I'm already using quite a bit and likely will in most cases.

Here's a quick and dirty demo how to add your own anchors to the builtin anchor feature of ProcessPageEditLink. No form manipulation shenanigans and no JS either. ? wire()->addHookBefore("ProcessPageEditLink::execute", function(HookEvent $event) { $page = wire('pages')->get((int)wire('input')->get('id')); // Limit to a certain template type: if($page->template->name !== 'home') return; $anchors = is_array(wire('input')->get->anchors) ? wire('input')->get->anchors : []; // This is the spot to add your own annotation anchors: $myAnchors = [ "some_anchor", "other_anchor", "third_anchor" ]; $anchors = array_merge($anchors, $myAnchors); wire('input')->get->anchors = $anchors; });

@Gadgetto That doesn't work in all cases though. My module allows you to call it's main method with custom arguments, overwriting any configuration option for this method call only. If I were accessing the module config through the magic __get properties, that would mean I'd have to check for overwrites anywhere I need to access an option, making the code overly complicated. Right now I'm merging the passed options with the module configuration and then merging the defaults in manually. In my opinion, the second step should be done by getModuleConfigData automatically.

The newest version of Klaro gives you the option if the CSS is included or you provide your own CSS. This is based on my PR.

@ryan It looks like there are some issues with InputfieldDatetime. I have to fields 'publish_from' and 'publish_until'. None of them are configurated to prefill today's date if empty, but after the update, if one of the fields has value second one is prefilled with its value. The second issue is that after page save I cannot change the selected value, it shows that the date is changed but after page save it still show the previous date. The third issue is that Date Picker options are not applied to the field. For example if I set Date Picker option to "No date/time picker" on the first field second one will also have no date/time picker. Looks like there is something wrong with js initialization and first field configuration is applied to all other date fields on the page edit screen. Tested on two different sites.

Just had a thought, so revisiting this. Going by your screenshot, it seems to me that each message is a unique page, no? If that is the case then you may have your cake and eat it too if instead of storing a message's subject in the 'data' column of your Fieldtype, let it be the page's title? This means for multilingual sites, they can decide to have multilingual messages by using language field title and language textarea (assuming that is where the message body is). You would then need to use 'data' to store something else. Just my 2p.

There is one actually, sort of. Look at the 'images' field in a multilingual setup. As you are aware, for truly (I use this word reservedly) multilingual fields, each language has to have its own column. That makes it easy to search the columns in the language you want. However, in your case, since you want only one column to have multilingual features, you have two choices ( + a 3rd not very good one): Go the route of images fields. In a multilingual setup, the description column of an image field holds each languages' value, saved as JSON. E.g. {"0":"We're gonna need a bigger terminal.","1012":"Wir brauchen einen größeren Terminal.","1013":"Me tarvitsemme isomman päätteen."}. The index of the values are the language ID. In this case, 0= English, 1012=German and 1013=Finnish.The trade off here is searching in one language is limited. Change your database design pattern. No need to cram things in if they don't fit ?. Let your subject be its own multilingual field and let your other single value data live in their own non-multilingual field. Nothing wrong with that. I mention this 3rd option hesitantly. Stick with one field as your are doing but for your data (subject) column create a lookup table for other languages. I am no DB guru but the little I know tells me this 3rd option is not a good design at all.

Sorry for not finding this discussion earlier. It sounds like the issue is already resolved, but I'll just add a couple minor points. Multi-language support is something that is installed by modules rather than something that's in the core from the beginning. As a result, the "default" language is the one you would have if you had no multi-language support installed. Likewise, the content of the default language is the content that would remain if you later uninstalled language support. So you need to think of that default language as the foundation or core language of the site. Once you start using multi-language fields, you can't easily swap in another language as the default (at least not without copying/pasting or making a little scripts to move things for you). If you needed the ability to do that, then you'd probably want to consider your 'default' language as unused on the front-end, and delegate all of your languages to non-default languages. I think it would be perfectly fine to consider the "default" language as "no language". When editing a page, you'd still be left with placeholders for the default language, which you'd probably just consider to be notes for the admin. The default language homepage is always represented by the root URL, "/", regardless of what name you've given it in the homepage settings tab. This is to ensure that a user arriving at your homepage doesn't encounter an immediate redirect to /en/ or /de/ or the like. Redirect from homepage is a behavior frowned upon by search engines, and generally considered a bad practice regardless. So ProcessWire is coded to prevent an automatic redirect from occurring on the homepage. That default language name comes into play on the rest of the pages in your site. If you wanted your homepage to be nothing but a language gateway (with no default assumed) then you'd need to delegate your real default language homepage to a separate page, like /en/welcome/ or something like that, which your language switcher can link to.