LostKobrakai

Yeah, the selector should be like mine in both our examples.

No need for the if statement here: $hero_images = $page->closest("hero_gallery.count>0")->hero_gallery; (Also the count selector is incorrect above)

And if you want a bit more nicer syntax consider this one: https://github.com/tightenco/collect https://laravel.com/docs/master/collections

The best possible way is probably using migrations throughout the whole development phase, but you can also add them in at a later stage as well. All you need is a common db (code) state to start from for (all) systems. Personally I'd stay away from doing any template/field changes via the UI for as much as possible. This keeps you from "just changing this one thing real quick" and forgetting about it. But sometimes if you're experimenting because you're not 100% sure how to tackle a problem it might be faster to go that way. One just needs to be aware that everything needs to be a migration in the end. The second key is treating migrations like git branches/commits – Modify anything at will for as long as you haven't shared it to collaborators – Do not touch anything otherwise and rather add another migration to fix any errors/changes. One benefit of having this level of detail in migrations (which might be daunting) is that you can really quickly apply/undo changes you've added to the system. To get started with template/field changes you'd probably go like this (first two examples come with the module): Create fields initially (example) Create template initially (example) Make modifications with default migrations (example) Repeat 1–3 as needed (Maybe delete something every now and then) For snippets I've created the GitHub repo linked in above posts. I'll certainly add things there as well, but it's really meant to be a community effort to make this great. E.g. I'm currently not using multi-language anywhere, but others do so and might use interesting snippets. I'm also very much interested in other opinions regarding the whole workflow. By now I'm using it just for myself, where it's working great (sadly I cannot share to much of it), but others might have different opinions and workflows.

I'm on mobile, but I try to answer those questions as best as possible. For migrating field and template changes I'm currently not specifically supporting those json exports. The first reason is quite simple in that the json export didn't support all field features at the time I created the module. The other one is the fact, that I'm not really convinced that adding migrations after the fact is really a good workflow improvement. I'm doing all my local changes via migrations as well. This "ensures" their correctness, is after a few weeks of working with migrations not considerably slower than doing it in the UI and it's really recording your changes 100%. Another one just poping into my head is that those json strings are only exporting a current state. If you want the option to rollback changes there's also the need to have some way to undo changes, which those exports do not provide. I'd suggest you to give the template/field migrations a try/look for creation/deletion of them and also some of my helper functions, which help adding fields to templates and such things. I'm also open for suggestions of other helper functions if they hide a lot of unnecessary boilerplate code. Just to make that clear. The module is certainly not meant to record any UI changes for the user. Those other things you mentioned you want to be able to change are all certainly doable. You're free to do whatever you need in the default migrations. The collaboration issues is nothing I had to deal with very much by now, but I'm getting a collaborator in a few weeks, so there might be updates coming. The biggest issue is the fact that db's are shitty to keep in sync with vcs branches. If you can create a baseline db state you can simply tell collaborators to init that baseline db and run all migrations on it when switching to a new branch. When working longer on the same branch it should just be a matter of pulling in changes of other coworkers and if there's a migration file in the changes typing 'php migrate -m (file)' after the 'git pull' (or similar).

If you cannot be sure about the state of the output formatting use one of those: $thumb = $page->getUnformatted('fieldName')->first()->size(300, 200); $thumb = $page->getFormatted('fieldName')->size(300, 200);

The file and image fields always return a list of files/images if the page's output-formatting is off. This setting you're mentioning will only affect the field with enabled output-formatting.

@RyanJ Can you elaborate a bit more on how they manage database changes you're doing on those dev environments?

@pwFoo Nope. It's a function of the TemplateFile class and only works in files included by its render function.

Fork the repository on github. Work with this your forked repository like with any other. Submit a pull request on the original repo, which pulls in your changed branch.

I've just added a Snippet about reversing the functionality of the build-in (or custom) MigrationTypes. https://github.com/LostKobrakai/MigrationSnippets/blob/master/Reverse_Template_Migration_Type.php

If you find $page to not return the correct page (overwritten somewhere or whatever else) just use wire('page') or $this->wire('page') (depending on the context) instead.

The easiest way to find those properties is to enable debug mode and hovering over the "collapse" icon of those options, when editing the field. This will often show you how those properties are named. Also the php docblocks of those modules are geting better and better in stateing those as well. Use them just like that: $this->min = 1.

$f->flags = Field::flagGlobal; $f->set('flags', Field::flagGlobal); $f->setFlags(Field::flagGlobal); Use what you like best.

Just for reference, this is how selector strings are supposed to look like: https://processwire.com/api/selectors/

Thanks for writing this. It's surely a place where the current docs are a bit lacking in details. You could clarify a bit more that the hooked function (___save()) does need to have those three underscores, whereas the function executed by the hook (helloMessage()) does not (but can). Also getModule() is not really often used in processwire's docs, I'd rather use $modules->get('FrontEndRender') and even this would work $modules->FrontEndRender

PHP isn't running in parallel (besides using ReactPHP), so if it's affecting anything it's certainly not your fault

I think changing the output formatting will be the most reliable way to check if a field is working like our file fields as it's working no matter what you throw at it. I'd imagine anything else being dependent on the actual implementation of each of those fieldtypes.

I can only support @tpr. nette/forms is a really nice package if you don't need a UI. With some upfront time you can really cater the markup to your needs and it'll still be easy/fast to configure new forms. But probably the best part of it is the one-time config for server and client side validation, which is even extendible even though I never needed to add anything. It doesn't come with so many prebuild sets of fields as alpaca forms (I've even seen table editing ), but I've added a few custom Inputfields to my nette/forms installation and it's not to hard to do.

Now that's some truely exciting news

Even overwriting only a single function (now rather two) is not really update save. It's less likely to change, but might still be subject to change.

Using the UTF-8 page-names is exactly for the reason not to replace those characters. There's no option to mix those behaviors by now.

Just as any other configureable module InputfieldPageName can be configured in the modules admin area.

Like this? http://modules.processwire.com/modules/inputfield-ace-extended/