rajo

I can't. I just pulled the latest dev branch. I export a field that's not required and it shows required:"". I change its setting to required and it shows required:1. I change it back and it show required:"". IOW, it works for me as designed.

I don't agree. I believe the simplicity of the PW backend metaphors is powerful, easy to understand, and easy to navigate for any level of user. Additionally, it's possible to use the powerful API to bolt on a parallel source-file-based approach (see my earlier post about upgradewire). I'm not done making it complete, but I think then you can have both ways, without disrupting what's in place, oh so zen, and yet accommodating of other development models. I know it's far from complete and it's "different" than most proposed methods here which tend toward being integrated instead of on-the-side (i.e. modules and such, instead of stand-alone PHP), but I was expecting more discussion of my proposed approach here. A little vanity, maybe. Seriously, what am I missing in my proposal which would leave the current integrity of the system in place and allow for alternative development style that meet the requirements this thread is about? Speaking to YAML approaches, I thought it would be simpler and more functional to have an API like the one I made in upgradewire, where the model changes are expressed functionally instead of statically. It's about finding the middle way to expressivity, to have a lingo that's both declarative and functional.

That's what I thought but was afraid to believe Then I ask the same question as teppo: Wouldn't it bog down under data volume?

djr, off the cuff, I'm not quite following where you're headed. Are you discussing changing the pw model, or the need for tools to manipulate the metamodel? Your 2 points about getting the template and field models to live in text files for source control sound like my proposal and my upgradewire tool, but thereafter I lose you. I continue to be convinced that it's possible to use source code (php) to maintain site models and use PW's API to apply the model to a site (DB).

Thanks cstevensjr. Now I know to do that. And I did.

Hi Ivo, I'm fairly new here, so, caveat emptor... I don't quite understand your question, but here's a possible answer When you define a field of type "Page", you get to select the following: Details tab > dereference as > Multiple Pages Input tab > Input Field Type > ____ . Here, I tend to choose AsmSelect*. This shows the selected values like the list of fields in a template admin page. Is this what you're asking about? Jean

I came across this earlier <https://processwire.com/talk/topic/5673-how-to-assign-users-to-page-field/?p=65747> and thanks to Soma I worked around it. I just came across it in a different context and forgot and spun my wheels. Unless I'm really misunderstanding, there's a defect in the lack of symmetry between using TypefieldPage in selectors in the $pages->find() vs. PageArray->find() and there should not be. Plainly, the following code should not behave like it does. The find() against the PageArray should return the same result but doesn't in the 1st example using name instead of ID. // a problem with TypefieldPage in selectors $selector = 'tags=plain'; echo "using \$selector : {$selector}\n"; $res = wire('pages')->find( $selector ); echo "using \$pages->find : {$res->count()}\n"; $res1 = $res->find( $selector ); echo "using pageArray->find : {$res1->count()}\n"; // versus $tag = wire('pages')->findOne( 'template=tag,name=plain' ); $selector = "tags={$tag->id}"; echo "using \$selector : {$selector}\n"; $res = wire('pages')->find( $selector ); echo "using \$pages->find : {$res->count()}\n"; $res1 = $res->find( $selector ); echo "using pageArray->find : {$res1->count()}\n"; /* output: using $selector : tags=plain using $pages->find : 1 using pageArray->find : 0 using $selector : tags=1343 using $pages->find : 1 using pageArray->find : 1 */ It's because the find/matches/(filter) methods work differently in Pages than in PageArray. I don't think this should be so. FYI, in this case, I'm building a form where tags can be assigned as a filter. It works well using tag->name if the filtering is against $pages, but not if it's against the results of $pages->find(), which I need because I need 2 layers of filtering. On to using tag->id... Did I mention I freeeekin' loooove pw? I do I do!

That's right, apeisa. While I'm learning the metamodel of templates and fields, I use the admin to create new ones, then I look in the database, in the Fields and Teamplates and other tables to see what was written by the admin, then I emulate that in my scripts. But in the long run, once I've "mastered" the models, I only create those xx_xx_xx.php scripts and they modify the fields and templates and document the evolution of the site in a repeatable, transportable way. Thanks for your interest.

Resonating with this thread, the need for some continuous integration tools, and more, I've created a new topic to point to crude tools I just published on github. They go in a slightly different direction than where mindplay.dk is headed, but hopefully they help the cause. See https://processwire.com/talk/topic/6779-continuous-integration-profile-management-etc-redux/

Hi all, I have been looking for a way to manage deployment of new sites, as well as versioning of the pw data model on sites already deployed, working with teams, etc. I've enjoyed the discussion on a few threads : https://processwire.com/talk/topic/6707-update-live-site-from-staging-server https://processwire.com/talk/topic/2975-team-development https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes but so far, I have not found what I'm looking for, so I built two tools and have put them on my newbie github site for all to use and/or peruse. I hope they are relevant to this community. They are crude and only have been exercised in my relatively finite world of Windows/apache dev. See https://github.com/jeanrajotte/schlepwire and https://github.com/jeanrajotte/upgradewire Both "apps" are not designed to be modules, integrated into pw, but rather external simple apps serving their specific purposes, possibly usable in automated build systems via curl, for example. There's a bit of a diatribe in the upgradewire README.md about the goodness of keeping the model in version-able source files, as distinct from operating the pw admin to maintain fields and templates, even if these changes are being recorded, as mindplay.dk seems to be doing. That's really the philosophical thrust behind these efforts. It's a beginning. I hope it's of interest here. Again, thank you for this superb framework and this generous community. Jean

Soma, thanks for following up. You're right, it works with ID. I can see it in the PageComparison code. It does boil down to the fact that the selector roles=name can find the role in question, but the selector->match.... logic ends up comparing role-path with role->name and fails. This solution is better than enumerating the role paths when there are is than one language. And it's better than adding an extra checkbox field to the user. So, big thanks.

Hi all. In the end, the question wasn't really answered and I'm running into the same problem. Template "space" needs a space_owner field who's a registered user. When I do 1-2-3 below, one can't save a new "space" page because of same error, namely that the user page selected from the Page field is not accepted at page save time. (1) Define a "space_owner" field to select a single user page, with a selector like this: 'template=user, roles=space-owner, check_access=0' . The field saves properly. I don't have a problem w/ the dropdown, I've defined a pretty_name Text field which I added to the user template and use it as the label field. (2) Add this space_owner field to the "space" template. no problem (3) Create a new space page. The select (dropdown) shows the correct list of users based on the selector. Pick the user page. Save the space page: boom! After much tracing, I see the "culprit" lives in the selector comparison methods. The selector fired to populate the dropdown properly, but fails to validate that the page being saved in the field came from the same result list... PageComparison->matches() uses page->path and page->id, but not page->name. And after all, "/en/processwire/access/roles/space-owner/" is not equal to "space-owner". I'm not sure what the fix is, but it's not symmetrical that the exit test fails for a match that succeeded. I see 2 workarounds. 1) change the selector to use the path, but then it's dependent on languages, like so: roles=/en/processwire/access/roles/space-owner/|/fr/processwire/access/roles/space-owner/ or, 2) forgo the elegance of using "role" as a flag on the user and add a checkbox field to the user template to indicate who's a space-owner.... And still assign the user role to space-owner for real access reasons. Thanks for reading this through. I think it's a defect.

re: The break/continue error. Is it me or is "continue" *always* a PHP error if you're not in a loop, which is the case at line 342 right now. No?

Hi, noob here. Maybe this has already been addressed, but I can't find it in the forums. Also, is this really where one may file a defect report? Anyway, implementing a multi-language site. I started out single language. Created body, summary, headline fields in some of the templates. Created pages w/ templates, populated some of these fields. Then I tried to change, say, summary, from Text to TextLanguage and got 1 green and 2 red bands at the top when saving: Field type changed Field type change failed. Database reports: SQLSTATE[HY000]: General error: 1364 Field 'data1027' doesn't have a default value Error changing fieldtype for 'test', reverted back to 'FieldtypeTextLanguage' (Woah! They're formatted here! I might see data getting clobbered during a field type transition, but this is an good ol' error. With a field that's already used in templates, I can't edit the field unless I remove it from every template. With a brand new field, just pressing [save] again works clears the error. Basically, changing the field type toward multi-language doesn't work, yet it's allowed. p.s. Niceties galore! What a superb CMF!!!