ryan

Subfields like "category.id" aren't currently supported by the PageArray in-memory find/filtering functions. Though I think I can add this easily enough. However, "category" should resolve to the id property anyway, so you probably don't need it.

The problem is that page $f doesn't know the repeater item changed. Those repeater items are individual pages themselves. You can solve this by saving the repeater item ($g) rather than the owning page ($f): 1. Replace your $f->save(); with $g->save(); 2. Also replace your $f->of(false); with $g->of(false); 3. Lastly, I also suggest replacing your first line with this: $found = $pages->find("parent=/invitations/$user->name, guests.guest_name=" . $sanitizer->selectorValue($form['oldname'])); Adding that selectorValue() sanitizer in there will prevent problems from occurring if the guest_name happens to contain characters like commas or quotes.

Thanks Martijn, this has just now been fixed in the latest commit.

We still have the Wiki ready to go (http://wiki.processwire.com/). It's just looking for someone to show it some love. I've closed off public post access because of all the spammers, but happy to add any new accounts for anyone that wants to work on this -- let me know?

Do you have template caching turned on? That would negate the use of any cookies set from PHP. When I need cookies and caching, I use Javascript-based cookies instead, since they are client-side and still happen regardless of server side caching.

I'm not sure I understand the 1 week vs 2 week thing. It really shouldn't matter whether the range is days, weeks, months, years, etc. There are no 1-week dependencies that I can see in any of the code in this thread so far. You should be able to provide any date range in your selector. $fromvalue ="2013-07-13"; $tovalue = "2013-07-27"; or $fromvalue = strtotime("2013-07-13"); $tovalue = strtotime("+2 weeks", $fromvalue); Also wanted to add, I have a better solution for this now (on the latest commit to the dev branch). You can now do this, where $item is a repeater item: $property = $item->getForPage();

They didn't used to entity encode those feeds, but looks like now they are. I think I've got this fixed. Please give it a try and let me know how it works for you: https://github.com/ryancramerdesign/MarkupTwitterFeed

As of the latest commit to the dev branch, you no longer have to do this. You can now replace the above bit of code with this: $forPage = $product->getForPage(); That returns the page that the repeater item is for. I also added this, should anyone ever need it: $forField = $product->getForField();

Okay I think I've got this fixed. Would you mind trying it out and seeing if it also fixes it on your end too? It is on the latest commit to the dev branch. https://github.com/ryancramerdesign/ProcessWire/commit/7dab612baa55b7ca02a7d6679e70d1aef4298f8b It involved a re-thinking of what a repeater Page is. I've changed it so that repeater pages are now represented by their own class (RepeaterPage rather than Page). The new RepeaterPage is the same thing as a Page, but overrides the method used to determine when files should be secured or not (which it now delegates to its owning 'for' page) . It also adds 2 methods (see below) so that people don't have to do stuff like this to figure out what Page or Field a given repeater item belongs to. For those interested, these methods now appear on all repeater item pages: $page->getForPage(); // returns the owning Page this repeater item is for $page->getForField(); // returns the Field this repeater item belongs to

That's a bug (glad we have a dev branch). I'll work on this.

It's a good thing.

There will be soon. Just need to figure out how to do it. But that's part of the reasons the $options array is there, so that we can include additional options like crop direction.

Not an ETA yet, but it's something that has been started and I've got a proof-of-concept going, so it's at least in the picture. ProcessWire's performance is pretty strong relative to other CMS platforms and there hasn't been a lot of demand for cache solutions. But I like the idea of a "super cache" because it does feasibly give one the potential for holding up to a flood of requests, like one might get from being linked on the reddit homepage or something.

Thanks for the link, that's a great directory of these frameworks. Found out about a few I'd not heard of too.

Thanks for the updates Nico! How about posting this to the modules directory?

Use of font tags seems kind of rare these days. I'm thinking that something like forecolor or fontselectsize would use span tags with inline styles rather than <font> tags. Though not positive. But you might try adding a span[style].

The goal here is to show ProcessWire in several different contexts to portray a lot of diversity, but that probably doesn't come across yet since we just have one set of screenshots in play at the moment. The way I see it, ProcessWire is a system, not an admin theme. If we're going to show them the system, I want to present it in the way that looks best on the page. I thought Nikola's screenshot was more attractive than mine in this context, but it's still showing the same system (and the Futura theme is beautiful). But what I'd really like is to have several sets of screenshots to rotate in here. So far I've not been able to get anyone else to send me any. Would love to get some screenshots of your admin theme tweaks you posted the other day in there--actually would like to implement those in the default admin theme.

Only fields with the 'autojoin' option set are fetched when a page is loaded. All other fields are fetched on demand. Meaning, $page->body won't actually be retrieved from the DB until you access $page->body. Most fields can have the autojoin option set if you want it (Setup > Fields > your field > Advanced > Autojoin). However, I recommend using that sparingly and only on fields that are used every time you load the Page. The 'title' field is a good example of a field that should be autojoin. ProcessWire does not keep separate modification dates for each field. Though it's feasible that it could. If you went into the DB and added a timestamp field to each field_* table, that's essentially what it would do since MySQL automatically sets a timestamp field on every update. I'm not sure I understand this question, as you can access $page->modified already. Likewise, you can retrieve pages from a selector using the modified property. For instance, if you wanted to retrieve all pages modified in the last day: $items = $pages->find("modified>=-1 DAY");

4. One other thing I added: If you delete an image, it won't leave the crops behind (they get deleted too). Previously the crop files would stick around even after the original image was gone. The field config is defined in InputfieldCropImage.module rather than FieldtypeCropImage.module, so that's why it works. It's more your doing than mine, as I only had to tweak a couple things to make it work. It was an accidental find too. Meaning, I wasn't intending to add this specifically, but noticed it worked through my own error of forgetting to change the fieldtype. It's possible I'm missing something, but it all seemed to work fine here. Of course, the FieldtypeCropImage is still a necessary component. But it's acting like an autoload module, adding hooks to Pageimage and Pageimages.

I think that the error is here: $p = $pages->get("/buchhaltung/buchungen/")->children("title=$c"); $p->delete(); $p is a PageArray (the return value of the children() method), not a Page, and there is no delete() method on a PageArray. What I think you want is the child() method (which returns 1 page) rather than the children() method: $c = $sanitizer->selectorValue($input->post->delpage); $p = $pages->get("/buchhaltung/buchungen/")->child("title=$c"); if($p->id) $p->delete(); Also, you might want to use the 'name' or 'id' property rather than the title. The reason for that is that 'title' is not guaranteed to be unique, whereas 'id' is guaranteed to be unique system-wide, and 'name' is guaranteed to be unique for all children of a given parent. $name = $sanitizer->pageName($input->post->delpage); if(strlen($name)) { $p = $pages->get("/buchhaltung/buchungen/")->child("name=$name"); if($p->id) $p->delete(); }

Antti, it looks like this is a result of output formatting being on, so it's doing a string comparison rather than a time comparison. This is not intended and not a detail people should not have to account for, so I'd consider it a bug. Thanks for tracking it down. The bug is only for in-memory finds on date fields, not database finds, as it's working how it should there already. I've put a fix in the latest commit to the dev branch of you want to try it out. It shows two files updated, but the only one that matters here is /wire/core/Array.php https://github.com/ryancramerdesign/ProcessWire/commit/393e420fc8ab60670dc4c874dd8436789be2897c

Clouds move for me (chrome in OS x, and safari on iPhone). Though Soma is very good with details and its possible he's got the quantity and speed of clouds hooked in to your local weather conditions.

I think you can just replace the module.

Another factor is that I don't think the MapMarker works when placed in other tabs. I think gmaps probably just needs to be visible when the editor is rendered in order for everything to work optimally.

To test if cache is working put a sleep(5); in your template. View the page--should take 5 seconds. View it again and it should be instant, as that sleep never gets executed. Again, make sure you are logged out. Don't bother with FieldtypeCache. That's only useful in specific situations, and they are pretty rare. I will probably remove that module from the core at some point.