nik

@ryan: I tried this out a little (by adding support for this to the SelectorTest ) and it seems to be working, well, almost perfectly. When trying to get 'modified' property, the 'created' timestamp is returned instead. They do differ in the database though. Another thing (this could be considered a feature even): when adding a new file, both properties get their values set to the time of the upload, not the time the page is saved. This doesn't really matter, but if you add a new file and write a description for it as well before saving the page, 'modified' property will be set according to the page save leaving the properties with different values although the user might consider having done one single transaction.

@ryan: Now there's a couple of tests on this issue in the test suite. Looks like the in-memory versions are broken too (both with id and subfield notation).

@alanfluff: It must have been because of the version number - I had forgotten to update it in the source. It should be fine now, just pushed the update to GitHub. Sorry! I hope the actual updates are in place though .

Nope, not yet. But I'll try and find a way to reproduce it with skyscraper data. Should be quite easy.

I'm able to reproduce that error message, but only with a broken config. If $config-variable is an object but $config->dbHost evaluates to false, I'm facing the same message (this piece of code here: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Database.php#L62). It's a Config-object represented as a string --> 'Config'. @sbarner: So, are you certain you've got exactly this in your config? It's case-sensitive ("dbHost" I mean). $config->dbHost = 'localhost'; And there's nothing else affecting $config->dbHost after that? One possibility would be an if-clause with assignment instead of comparison, something like this: // this would break things up! if($config->dbHost = '') { // do something different for one environment, or whatever }

Look's like this bug has been fixed only partially. Using the examples from my opening post, this selector works now as expected (giving pages c3 and c4): $pages->find("template=company, tags.title!=t1"); But if page id is being used, the old bug remains. Given that tag page t1 has id 1234, this still returns pages c2 and c3: $pages->find("template=company, tags!=1234"); And this is dev branch I'm using here.

I was planning to add something a bit more at once, but as there never seems to be enough time I decided to release what I had ready. Just pushed these minor improvements to GitHub. Version 1.11: Added: all field and template data shown + cached at template level Added: fields inside a fieldset are wrapped into a new subtree (page data only - fields inside a template are in a flat list)

Actually when using dev-branch, both ^= and %^= are using SQL LIKE and thus both work with short words and MySQL stopwords. Master branch (production version) behaves differently, like described above. @ryan: Was this the intention? The change was made here: https://github.com/ryancramerdesign/ProcessWire/commit/0f0be7b60690db9de4af664dbb5b94ef7e6ecef1#wire/core/DatabaseQuerySelectFulltext.php and it actually obsoletes parts of matchContains() method there. Looks like I hit this behaviour with a couple of tests just yesterday (using ^= and not testing %^= at all as I remembered they're the same thing - not so much black box testing...).

(It's been quite hectic around here the last couple of days - sorry to keep you "waiting"). Well, it seems I lack the capability to split things into pieces more than one person can work on simultaneously.. But let's see. I did some small structural adjustments, again. At the moment I'm thinking of these separate test classes for selectors: ValidityTest - to check that invalid selectors are being reported correctly, and valid ones are accepted OperatorsTest - to have some basic tests for each of the operators (this is the part that has some content there already) SubfieldTest - to test the different kinds of subfield selectors (parent.* and fieldtypes Page, Repeater, MapMarker, Comments + those I'm forgetting atm) SortAndLimitTest - to test various scenarios with sort, limit, start and end I think these would cover most common scenarios at least. Then there are a few more special selectors probably requiring a bit different approach (count, has_parent, include, status, grant_check), especially regarding consistency between in-memory and db queries. And it may be beneficial to test with a set of very complex selectors as well as there just might be something nasty lurking around - at least after some bigger core modifications if not currently. And I think you'd like to be able to do something like that one day. I'm quite keen on trying to get some test coverage report out of the system pretty soon as well (@apeisa: yeah, that sure looks interesting - have to see if that would suit our needs). And after that extending tests to cover functions in Page(s), Page/WireArray and so on will be my target. But I guess it's better to try and nail them selectors first . So, you could basically pick any of those test classes outlined above or just wait for me to submit issues to GitHub . SubfieldTest should be pretty straightforward to do based on OperatorsTest - and there's actually a stub just waiting for you in GitHub already. ValidityTest is another one you could write at once, but that should be done a bit differently from OperatorsTest I think (there's a way to handle exceptions in PHPUnit). Anyway, I'm going to continue a bit with the operators and then head to sort & limit, unless you get there first . Sadly it seems I haven't got too much time to invest on this right now - I hope I'm able to get something done during the weekend though.

..and just under four months later the wizard himself has over 2k likes! Didn't say it aloud myself when he hit the first thousand, so here goes: thanks Ryan! There hasn't been a moment of "nothing to do" for ages for me .

Browser? You're using browsers, graphical ones? No no, I'm using a self-written TCP/IP stack and then: >telnet processwire.com 80 Trying 207.58.138.35... Connected to processwire.com. Escape character is '^]'. GET /talk/ HTTP/1.0 Host: processwire.com User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11 HTTP/1.0 200 OK ... No wonder you're always faster than me with your replies...

GitHub it is then. It's of course the Right Way to do it as well. I think there isn't too much in PHPUnit that couldn't be done pretty easily and more straightforward even, at least at this stage. However, in my opinion there are a few advantages in using PHPUnit instead of a home-grown alternative: 1) It's production ready, so no need to re-invent the wheel; 2) It's a known tool, which could give the project some extra credibility; 3) There are some integration/extension possibilities there already that just might come in handy, for example code coverage analysis (with Xdebug) and Selenium integration. And maybe I should add some more personal ones: 4) It would have taken me ages to come up with a script decent enough; 5) I saw an opportunity to learn something that could be useful in the future. And so on . But, just to be clear, if there comes anything in our way that would stall the progress of testing at least the selectors, I know I won't be missing any tool and will be more than happy to choose another alternative in no time, be it home-grown or not. To write tests using PHPUnit the main thing to know is that any method with its name starting 'test' is considered a test and will be run as such. The tests are located in classes inherited from PHPUnit_Framework_TestCase (or ProcessWireTestCase in this case, which adds a little something there in between). I tried to follow some examples on structuring the tests by creating directory for Selector tests and creating the test case classes there. By the book there should be a test case class for every class that's being tested. But as these aren't really unit tests anyway, I took the freedom to group the tests a bit differently. So right now there are two classes under Selector: BasicOperatorsTest and ContainsOperatorsTest (classnames should end with 'Test') and there could be for example SubfieldTest, SortTest, PagingTest etc. I don't know yet how big each of those would grow so it could have been better to have just one class for starters - especially when with this kind of naming it wouldn't be clear where some more complex tests belong to. But there are other maybe even more logical ways to cut this into pieces, we'll see which direction we're going to take. There are only two test* methods in both of the classes at the moment: one for testing selectors in database and another for in-memory tests. Both methods use a data provider (see the @dataProvider annotation) that returns an array of arrays of arguments to pass to the test method. So basically all you need to do to add a new test that follows the same pattern, is add another array or arguments for the data provider method to return (description, selector string, array of assertions and an optional skip message to mark the test as skipped). More complicated tests can be added as new test* methods as well.

Glad you like it . Do you prefer separate issues on the GitHub for each suspected inconsistency / bug? I guess it's better to have them as issues in case something that's not going to get fixed right away shows up. But I'm ok with sending you an email or whatever as well if some test is failing. The test suite is quite ok for the moment (after few rounds of refactoring) and I will be adding more tests whenever I've got some spare time. There are things I know will have to be changed to test some aspects, but I think they can wait a bit for now. Hehe, I'm using MAMP myself and that's what I did on two different Macs even . Well, maybe I'll just link to a couple of different install instructions found on the web then. Good to know, thanks Ryan.

Maybe something like this then, extending from Soma's example: $titles = array('first', 'second', 'third');foreach($titles as $title) { $np = new Page(); $np->parent = '/path/to/your/parent/page/'; $np->template = 'basic-page'; $np->title = $title; $np->save();} So there's no need for WireArray or PageArray here, nor import() - which has nothing to do with creating new pages but importing Page objects into a PageArray. And if you'd want to import some more data in there at once, take at look at this as well: http://modules.processwire.com/modules/import-pages-csv/

@Pete: Nope, didn't help. Even when I replaced the whole post with a plain text version (with code/quote tags with square brackets around them), divs and other html markup appeared after save. I don't think that has anything to do with js, although I haven't got a clue how this piece of software has been implemented. It looks like others are having same kind of problems as well, see this for example: http://processwire.com/talk/topic/2616-iteration-problem-insert-element-every-nth-loop/

(Sorry tinacious, formatting code and quotes just doesn't work for me atm...) You could do it the way you've described with a little change: if($date > $today) { // now you've got what you're looking for in $event $firstUpcomingEvent = $event; // break out of the loop break; } While the example above would do it, I'd say the best way to go is using a single get() with the right kind of selector . This is all you need: $today = mktime(0,0,0,date("m"),date("d"),date("Y")); $firstUpcomingEvent = $pages->get("template=calendar-event, calendar_event>$today, sort=calendar_event"); Although, it's a bit confusing to me when you've got a date field called 'calendar_event' in a template called 'calendar-event'. I would definitely make a mistake with that kind of setup one day myself . I'd change the name of the field to something else, like 'calendar_event_date' or whatever that makes the selectors understandable. But that's just me, the selector does work as it is. Maybe it's just a snippet and there's some html coming up in the actual template file or something, but just in case: it's a good practice to omit the closing PHP tag (at the end of the file) to prevent accidental whitespace, see http://php.net/manual/en/language.basic-syntax.phptags.php . ( Edit 1: I don't get it, since the forum update editing code and/or quotes just does not work. Is it just me? Using Chrome on a Mac. Edit 2: Let's see if I got it right after second edit... Going to use plain text editor from now on. Edit 3: Nope, not even that works anymore. Without any tags then? )

As briefly discussed earlier with Ryan (http://processwire.com/talk/topic/1560-searching-multiple-fieldtypes/page-2#entry23307), I tried to build some sort of test suite for ProcessWire. The tests aim for selector consistency (in-memory and db) and of course making them free of bugs - once and for all. The beginning of the test suite with instructions can be found from https://github.com/niklaka/ProcessWireTests . I wouldn't be surprised if I had to go and restructure the whole thing sooner than later (more than once even), but that'll do for now. Next I'll focus on writing a basic set of tests to cover at least the most common selectors (as there's currently only a few of the most simple ones there). This testing stuff if somewhat new to me and I've been reading lately a little something on the subject. Hope I got at least something right . Having said that, any help (or constructive criticism) from you my dear friends is highly appreciated. Especially if you'd happen to have any/some experience on testing - but I'll take kind words from anyone . I decided to try where I'm able to get with PHPUnit and so far it looks like it would be very much possible to build something useful with it (no, I'm not exactly surprised as it sure is a proven tool for such a thing). I did take Ryan's idea of using Skyscrapers profile as a base for testing (you're not making changes to it are you Ryan ), but there may be need for some other approach as well, even another Skyscrapers based one. Well, I'll go and write a a couple of more tests now. (PS: If some admin feels this post fits some other area better, please do move it - I wasn't sure where to put it myself.)

I'm not sure I understand what you're trying to achieve, but let's try and fix a couple of little mistakes from the code . echo 'max n vake' . $maxn; There's no variable named $maxn, there should probably read $maxi. $field = $fields->get('$dati_auto[$i]'); You're using single quotes so PHP treats what's between them as a literal string and does not interpolate the variable. As there's nothing more than a variable there, you can leave the single quotes off. To make PHP interpolate the variable, use double quotes as you've done at the very next line. The $language variable shown there is initialized to some meaningful value somewhere as well, right? And yet another variable interpolation thing here: echo "<li><strong>$label:</strong> $page->$dati_auto[$i]</li>"; Should be: echo "<li><strong>$label:</strong> {$page->$dati_auto[$i]}</li>"; (Ah, Pete was faster, so no hurry anymore for me. I'll go on a little more then.) And of course you'd need fields called auto_marca, auto_tipo and auto_prezzo to exists in the template of this page for this to work in the first place. But I think you've covered that already. One more thing, and this is just a preference, not a mistake at all. I like to iterate over that kind of array like this: foreach($dati_auto as $field_name) { $field = $fields->get($field_name); // ... echo "... {$page->$field_name} ...";} But as I said, there's nothing wrong with the way you've done it . (Edit: Ngh.. The editor messed the code totally - had to fix them afterwards. I wanted to see if the post looks alright before posting it and used full editor for that (more options or whatever the button says there). Then submitted the post and code was all over the place...)

Omg, I beat Soma!

News_Year.title=$currentyear I'm on a mobile but I think I got that right - if I understood you right in the first place . Hope this helps!

Just a quick one: did you try using RewriteBase mentioned earlier in this thread? There are many other threads on this very subject here on the forum, try searching with Google using something like "site:processwire.com rewritebase" or "site:processwire.com install 404".

Phew, sleeping is overrated. Coding is much more fun. @Antti: I just pushed a new version to GitHub and the bug you reported should be fixed now. @Pete: As an added bonus I added the option to choose between radios in a container and a dropdown near the save button. This latter behaviour is somewhat experimental as I could use half a year trying to style the dropdown (+checkbox) and still get it awfully wrong. So there it is, plain and simple. Feel free to suggest (anyone?) suitable markup for the dropdown version. I just might give it a try myself someday, but I doubt it will become anything suitable for anyone not wanting to damage their eyes. @Soma: And I even managed to do it at such a time I was going away from the computer for some time. Plain stupid of me. But hey, didn't I say some time ago I'd try to publish stuff sooner than later: "if you’re not embarrassed when you ship your first version you waited too long". Check. And it wasn't even first version I messed up with .

@apeisa: Damned, I did a little 'refactoring' just before committing... Seems I've broken it down, have to take a look at it a bit later (found one bug right away, but it didn't fix the whole issue). Sorry everyone. Fail. And that naming. I couldn't come up with a good name - but it was too obvious. We'll see if this module gets a third name before it becomes stable.

I started a new thread on this modules new version as the name changed. See here: http://processwire.com/talk/topic/2515-module-aftersaveactions/. @Pete: I'm planning on implementing what you're suggesting as an alternative for the container way. Tried it out already and it shouldn't become a problem. @Ryan: Great! Although I took a slightly different route and the new version now works in PW 2.2 as well =).

AdminSaveActions (Was: After Save Actions - guess why the rename?) Admin Save Actions adds the possibility to choose where the browser gets redirected after saving a page, template or field. Admin save actions are displayed just before the save button in a collapsed container. Chosen action can be saved in a cookie for current user by checking "Remember this setting". By leaving this option unchecked upon save, the chosen action will not become the default. Why? Some of you wanted something like this to exists in ProcessWire - and so did I. I've read discussions here, here, here and here carefully trying to cover at least most of the options discussed. I know this implementation wont satisfy all the needs, but I'm looking into adding some things afterwards to cover even more of them. I called the first version of this module PageEditRedirects but decided to to change the name in to a more descriptive one. So that module got deprecated as of now (and does not exists at GitHub anymore). This new version also does not require PW 2.3 but works just fine on PW 2.2 as well. Special thanks A module by Adam Kiss (ListAfterSave) implemented some of these actions a long time ago. Thanks to Adam for letting me use the ideas introduced by his module. There are actually some things there my module isn't going to cover even in future versions. Links AdminSaveActions can be found from the modules section. AdminSaveAction is downloadable from GitHub. (Edit: added link to the modules section. Edit 2: Implemented config option + version bump. Edit 3: Removed feature list - see GitHub.)