searching multiple fieldtypes

[nik]

Per @nik's request (from awhile ago), I've expanded support for the parent field selectors that you can use with $pages->find() and related functions. You can now pass those functions selectors like this:

// and I think this is the one that @nik requested:
parent.title|title*=Something

Thanks Ryan! I may even go and get rid of the little tweak I used to get around this . Actually after trying out some not-so-clean solutions for this I finally came up with a really simple one (which mostly seems to be the case with PW anyway). I had an extra page reference in the template I needed this selector for and then a tiny module to set it to parent whenever the page got saved ($page->fake_parent = $page->parent). This way I was able to use a selector like "fake_parent.title|title*=Something" with PW 2.2.

Thanks Matthew, these API improvements are one of the most fun parts for me. Though I think the next step will be to get comprehensive unit test library specific to PW selectors, so that I can go in and add or tweak stuff, and be able to make sure I'm not breaking anything.

+1 for the unit tests! And once the selectors are covered and some kind of a test suite is up, I'm sure there are other parts of the core that would benefit from a little unit test here and there. Just to make it easier for you to refactor whatever needed as you go on building and improving ProcessWire features and versions.

While the implications on most used parts of ProcessWire core are revealed pretty fast, there are these must-work-but-would-not-want-to-touch things like localization and internationalization also. Just to name a couple.

I'm also willing to help you out with writing those tests if you'd like. Would offer a helping hand with the whole test suite as well, but I'm not experienced enough with that kind of stuff to get it right at once I'm afraid.

[ryan]

While the implications on most used parts of ProcessWire core are revealed pretty fast, there are these must-work-but-would-not-want-to-touch things like localization and internationalization also. Just to name a couple.

I agree those will also be useful down the road. Though from this side, those are a little harder to break, so the more immediate need is a test suite for selectors. This is also needed to maintain consistency between selectors that result in DB queries, vs. selectors that occur in-memory. Because they are handled by two totally different things, this is a common point of inconsistency. They aren't even 100% consistent right now, but I'd like to aim for it, and tests are necessary prerequisite for this.

I'm also willing to help you out with writing those tests if you'd like. Would offer a helping hand with the whole test suite as well, but I'm not experienced enough with that kind of stuff to get it right at once I'm afraid.

Thanks! I'm not particularly experienced in this area either. But I think our needs for a test suite are different than those of traditional TDD. We need something like what you and I were originally working with, but taken a lot further. It needs to be a site profile built for the needs of running these tests. It would contain a diverse range of pages and fields, and the template file(s) would perform the tests, looking or anything unexpected. One thought is that we might build it on top of the existing skyscrapers profile since that already contains a good number of pages and fields, along with intelligible test cases to work with.