LostKobrakai

Because it's (loosely) based on the selectors engine you select pages by and because it was never intended to serve bigger validation purposes, but more of a convenience tool to quickly show/hide things based on some external data. Having that it was a quick thing to add "required if" as another option besides "show if". So all in all: historical reasons. Real validation needs to run on the server side, and while show if and required if is checked against on the server side the main functionality it added at the time is the client side in showing/hiding fields and or showing/hiding the required asterisk. So mixing both is in my opinion a ill fit without changes to implementation.

Afaik ryan's position on hard constraints in form validation is that they don't work and you should expect things to be off. Like what happens if you change a input field from min. 1 to min. 2 images. Suddenly all your pages are in an invalid state and there's no form validation, which can save you from that.

Yeah, there are ways to use webp as progressive enhancement, so there's no need to detect browser support on the server side.

You can look into the FieldMigration class to see what it does on migration/rollback. It should just remove the field itself. If that doesn‘t clean up the fieldgroup than it‘s expected behaviour. You can still override/add to that by putting your own upgrade/downgrade functions like e.g. I did it here: https://github.com/LostKobrakai/MigrationSnippets/blob/master/Reverse_Template_Migration_Type.php

Laravel or Symfony are first and foremost general purpose frameworks, while ProcessWire is first and foremost a CMS with the benefit of having a small general purpose framework beneath. The difference lies mostly in what you get out of the box and less so in what you can build with it. E.g. laravel/symfony have components for using queues, processwire doesn't, laravel/symfony have a templating system, ProcessWire doesn't (it's php), …. On the other hand ProcessWire comes with a flexible backend to hook into, laravel/symfony don't have that (laravel nova would be similar, but costs money).

The problem I have with static json or yaml setup files is that it's not migration. It's just a static set of fields/templates/… without knowledge of what came before or after. I have almost always user generated data associated to a certain setup. So when changing the setup there's often the need for something to happen with said data as well, like when adding a new intro field for blog posts one might want to put the first paragraph of existing posts from the body into the intro. Craft seems to see their addition just as replacement of sharing db dumps and it's essentially that. If environments never concurrently change in terms of content, but just structure then some version controlled file for the structure is better than a db dump, which contains both structure and content. But as soon as the content is also affected by changes it's no longer a solution.

@bernhard I've not much time to work on my OSS stuff at the moment, as I'm no longer actively using it in my everyday work. But I'd happy to collaborate if someone wants to make a companion module and make sure the needed functionality is callable on the module.

The problem is that a middleground is even more complex. Either your prod environment doesn't change (in terms of what's in the db) then you can simply use db dumps, or your production environement's db does change concurrently to the dev db. The same is the case if you're working in a team of people as well. If the latter does happen you need some way to know what to update and what not to touch. Migrations is doing that by letting you manually define migrations, which are the stuff, which needs to be changed. This gives you full control and you can basically update anything in processwire by using the api. You can also still do stuff on your dev environment, which is not somehow automatically applied as change to prod. Bonus point: replayablility / reusability. What you're looking for is some way to basically let the computer do what you've to do manually with my module: detect what's to change. This could work for simple changes like in fields or templates, but does easily get quite complex is the not so simple cases, e.g. repeater matrix. For pages it's already getting not that simple. You might create pages, which are just for your dev work or pages, which need to be created in prod as well. One could manage whitelists or blacklists (of branches), but that's also a thing to maintain. Also if such a module is not super flexible you'll be bound to execute what it thinks did change. Most often such algorythms don't like a human to adjust their results, especially if steps depend on each other.

After a while it became even easier for me to just copy&paste together new fields/templates instead of creating them in the UI. There's certainly a transition phase, though. The UI I use mostly for when I'm not sure how to build something yet. For any project with a somewhat longer period of active development/maintainence I'd really suggest anyone trying it.

I'm not sure on the specifics (which @Pete or @ryan should know), but we have some restrictions on the forum for new members based on what we saw spammers (mis-)use. Iirc the limits are not that high, so maybe you just need a few more posts to be good to go.

Either match by the id or match by the title. $products = $pages->find("brand=" . $sanitizer->selectorValue($brand) ); $products = $pages->find("brand.title=" . $sanitizer->selectorValue($brand->title) );

Or if you need to be more sophisticated (and/or multi-language) something like: https://punic.github.io/#Misc-class

Yes. You need to change the order of fields in $template->fieldgroup like e.g. here https://github.com/LostKobrakai/Migrations/blob/master/classes/Migration.php#L41-L62

It could just as well be named gettext(), translate() or something long those lines and be way more descriptive and without the need to lookup docs.

Prices (or anything else in a shop) should never be by language imho. What if I'm living in a country foreign to my native speaking language. The German living in America should always be able to visit a shop in German (if it's localized), but otherwise shall be treated like any other American.

I imagine most often the ecommerce systems are less flexible (by design and necessity) than processwire, so it's easier to integrate the flexible system into the inflexible one than the other way around.

So the conditional hooks (probably) work on the $event->object of the HookEvent passed to the hook. That's why ryan's examples only use Page(…)::…. Page does not have a function added (neither hookable nor unhookable), while Pages cannot be evaluated against a selector.

The .gitignore is meant for the processwire project a.k.a. core development. For your own projects you'll need to change it to accomodate your needs.

Yep. It's a really great library.

I've a prove of concept S3 filesystem module based on flysystem and the core inputfield file running in a project of mine. I'm not comfortable to put it out in the public, but there are ways to make it work. Personally I'd try to avoid mounting remote filesystems, as there's more networking involved: client <-> server <-> S3. I'd rather work with direct s3 urls for the frontend.

Why not https://processwire.com/api/ref/wire-array/implode/ directly? Edit: … but you're right. Seems like WireArray::each really suffered from feature-creep. Reading the docs sounds like it's really inconsistant in what it does.

realfavicongenerater does offer a proper API for integration in other projects.

If that's your concern you could always use $page->getUnformatted('datefield') in your templates and use the outputformatting just for the backend formatting.

I'd vote strongly against that. Like who's to decide which 3rd party modules are worthy to be featured in the (1st party) docs? Who's job is it to maintain those docs if things change? Will modules be removed if they loose popularity? When exactly would that be the case? — I doubt we should put even more work on ryan's shoulders especially for stuff he might not even know very well. As afaik the module directory does not track downloads we cannot have a most downloaded modules listing, but imho that would be a more useful way to highlight modules, which are popular and not to be missed. We could also have a modules of the month poll or something like that for gathering information on module usage. As for documenting what a module does and how it's used; that should be up to the module maintainer and/or the community. Maybe the api docs could pull them out of the source code automatically like it does for the core (how it could work [1]). The point is the core docs are certainly not the place for providing information on 3rd party modules. 1: hexdocs.pm (try searching for e.g. phoenix or ecto for the best maintained examples) Each package of the hex package manager does automatically generate it's docs on publish and they will be published to hexdocs.pm. The docs are generated from the package's source code by a similar system to how it works for processwire. From my experience with it I've to say that having one platform for hosted docs, which are autogenerated (in 99% of the cases even by the same generator) is a real incentive to write (good) docs.

I feel like the Q&A style works for Stack Overflow, because discussion and order of posting is usually less important in a plain "here's the answer" context. There's hardly interaction between various answers besides the "xxx answer is wrong" every now and then. There are the comments for answers, but those are no longer answers by themselves and often hardly useful. Most topics here on the other hand are way more discussion heavy and afaik it's not like you can choose what you need, but rather certain subforums would have only Q&A style topics, while others would have normal ones. The other thing about Stack Overflow is that usually each topic just has just a single question asked. We have lot's of topics, which don't fit that pattern at all. Instead of one topic with 7 solution stack overflow might just have 7 similar questions with each a single different solution. I mean we certainly have duplication as well, but the problem isn't solved for anyone here. Iirc that's what made the Q&A forums a non-starter for me when testing those. By removing the order of messages they just didn't work for any kind of content, which refered to prev. posted stuff and was more contextual than just posting a potential solution in isolation.