LostKobrakai

Can you look at the settings of the field especially the one stateing if the field is single value or multi value?

The only thing necessary is that you have files `/site/template/{template_name}.php`. Most templates use php files of the same name as the template, but you can also use an "alternative name" you can set for certain templates. The latter is certainly less common though. What you do after that is 100% up to you, which is a boon as well as a pain at the same time. It's nice to not be prescribed how to do things, but it's bad to not have a fixed structure as each project may very well be build differently.

It's basically like a repeater, but limited to a single page, which you don't need to explicitly create.

That's what FieldtypeFieldsetPage would allow you to do. Create the field on installation of your module (and update/delete it from your module; It's not to be edited by the user) and the user would just need to add that field to whatever template needed.

In my opinion the cleanest approach is using: It's simple to add into a CI/CD workflow and you can use e.g. git to keep track of changes. You could also try to use the json exports of processwire, but it does have way to many quirks in my opinion.

Based on your description I feel like you're tackling the problem from the wrong end. You're actually trying to do what was requested from MarkupSEO ages ago: Just adding a single field to a template, but getting a whole bunch of fields in the process. In my opinion either let people add all fields to their templates or even better have an own template and just store the metadata there. Sadly it took quite a few month until the latter option was actually added properly, but now we have it: https://processwire.com/blog/posts/processwire-3.0.73-and-new-fieldset-types/#fieldset-page-fieldtypefieldsetpage https://processwire.com/blog/posts/processwire-3.0.74-adds-new-fieldsetpage-field-type/ Edit: And some more context from the time I initially proposed the idea (I've no idea if Ryan actually knew this, but it's basically what I proposed):

This is an english speaking forum, so please add at least a short english introduction to your entry post.

Afaik it's part of the core, but maybe not installed by default. Look into the installable modules in the backend.

There are ways to do that (search for eval()), but really I'd quite strongly urge you to do it any other way. Evaling code is a quite unsafe operation unless you're very thorough with what you pass into it and it also makes your code more scattered, more difficult to debug and stuff like that. Much rather look for a way to encode the query you want to do in data instead of in code. E.g. processwire has the FieldtypeSelector, which allows you to use a quite flexible interface to build up selectors and it simply gives you an selector string to query pages by.

https://codepen.io/LostKobrakai/pen/ZwNMxa

It loads the actual data. All Field/Template classes are available once ProcessWire is bootstrapped.

It's part of ProcessWire's bootstrap process. I'm not exactly sure about the exact reasoning. @dragan FE or BE does not really matter. Fields/Templates are loaded even before anything request specific is executed.

That's not really true. The number of fields and templates does matter as those will be autoloaded for every request hitting processwire. It's not like 10 fields make a difference, but adding an additional 100 fields or 100 templates can indeed cause a slow down. It's different with pages though. Those are really only loaded on demand.

So there are a few things to unpack: You essentially removed exactly what's needed to know when working with an .htaccess file being unfamiliar with apache. There are like two setting in there, which are rather common to change: rewrite base (shared hosters often need it set) and https. That's it. Everything else is either static or only to be touched in certain corner cases. If you have rules to let files be directly accessed by the webserver (and not route through php -> bad performance) then you might want to disallow certain folders, which should not be accessable. Things like caches or logs are prone to leak important information about your website and simply allowing any file in the system to be accessable (see wordpress) is not good practice at all. Also this is not stuff that can be handled by the core, because you don't want php involved for static files, but you also want not all static files be accessable. For an example: Say you deploy your composer.json (you shouldn't, but well) with all the other files of your project. People could happily look for you using packages with known security issues and you'd even aid them, by telling them what version constraints you've set up. It was also already noted that for laravel most of the important stuff is not even web accessable by default, because only it's public folder is meant to be served by a webserver. This is not possible for processwire again because of shared hosters, where often you don't have the possibility to store files outside the webroot to begin with. That I can support. Nginx configs provided by the core would be really nice and would probably make ProcessWire more approachable for the usecases, where people rent own servers and want e.g. the performance of nginx. I'd say "the conversion" is scary without knowledge. I can understand that. But the plain presence of an a-bit-longer .htaccess didn't bother me much even before I knew what any of it did. You won't even notice in most cases as the instructions to install are basically: Download processwire, unzip and open url. There are cases where that's not enough, but it's certainly a big majority where this will just work. This is ill driven as like 95% of those rules wouldn't even hit the core without serving static files through php are things not changeable by php at all. So my final comment would be: The current .htaccess is usefully more elaborate than certain other systems. It makes it more complex to port to other systems, but it's 50% just a bunch of regexes to secure certain files/folders, so I'd say it's more tedious work than a to difficult one.

Relying on .htaccess is not really uncommon for php cms's out there. Some are more minimal on utilising apache, processwire is probably more on the "take what we can get"-side. Having php serve everything – especially static assets – is just not performant enough in any way. That's the reason for needing to rely on the webserver in front of php in the first place. The reason for apache specifically is because of .htaccess. Other webservers are usually only statically configurable, which is a deal-breaker for any shared-hoster, where a (global) webserver cannot be restarted whenever a single user needs to change his configuration. So if you only support one webserver, it better be apache.

Maybe just add your hook in some hook of ProcessPageEdit, which is executed before your hook shall be triggered.

Looks great. The only thing I negatively noticed is that the page loads seem to be slow even though you seem to be using procache:

It's probably for the same reasons mentioned here:

I'm mostly guessing. I've seen quite a bunch of tutorials using laravel, but never actually used it, so I try: I'm expecting that laravel uses reflection to know the type hint you put for the parameter and depending on the result do some boilerplate code you could've written on your own to retrieve the project and call the controller action with it.

Github is the bigger platform (potential for collaboration), it's interface is quite a bit faster and more productive than gitlabs and it has a better history in terms of availability. Also there are quite a lot of addons like linters, bots or CI options, which directly integrate with the github interface. All in all it's imho the more polished product in almost all areas. The only place I feel Gitlab is ahead is with it's integrated CI/CD tools.

This is an infinite loop you're causing. You hook after the render of a field named a specific name and in the hook you render another field of the same name, which again triggers your hook to replace and so on. You'd either need to find a hook, which won't be triggered again by what you're doing inside the hook execution (like @Martijn Geerts tried) or you need to find a way to differenciate the first call to your hook from the ones triggered by your code within the hook.

Reverse the second part?

I'd simply combine the two options.

It's been some time since I read the blog-post, but I really need to ask if we need the magic functions for the sanitizer, especially the grouped ones. They're hard to document, harder to be used for automated setups – where used sanitizers are aggregated by some coded means – compared to having them as parameters and I would say they're hardly simpler for manual usage over proper parameters. Personally I'd really vote for one clear way instead of having even more ways to do the same. For me there's also the reason that I find it way cleaner to work with data a.k.a. an array of sanitizer names vs. some magic naming, but that may just be me, but I think we really need to be aware of the backdraws of having to many options to do a thing in general.

Why would there if you need a "current" page to be able to do all of that?