nik

Regarding the location of $page->render(): it's implemented as a hook in a module. What else could it be, this is ProcessWire . See wire/modules/PageRender.module.

Well that sounds odd. I don't see how it would be possible to get that message without $config->demo having a value that evaluates to true (https://github.com/ryancramerdesign/ProcessWire/blob/d453a76b1f1721ab43e1c81553e212d95699a942/wire/core/admin.php#L36). So, apparently in site/config.php things are ok. But do you have any custom code touching $config->demo, for example an if-clause of your own? One with a single equals sign even (which would set demo mode on), like this: if($config->demo = true) { // do something } I think you'd remember if you had set $config->demo to something truthy on purpose, anywhere on that site (have you?) .I can't come up with any better ideas now, but still wanted to give it a try. I hope you'll get it solved!

Hehe, somehow it did feel like there's an easier way as well.

Gabi, this one's a bit tricky as PW does not maintain accessible information about the original page when another page gets rendered - which is what happens when showing the Recent Posts widget. So, as it is, the widget does not know which page it's being shown on and thus can't exclude that page from the list. See Ryan's comment here on a very similar question. In that other thread there's a general solution (via a module) to make the original page accessible. To solve this particular case you don't necessarily need a module though, but you can do the very same thing right before rendering the widgets, here (site/templates/main.inc, line 138), like this: Wire::setFuel('originalPage', $page); After this you can exclude the original page from the list by modifying the selector here (site/templates/widget-recent-posts.php, line 14), like this: $originalPage = Wire::getFuel('originalPage'); $posts = $pages->find("template=post, id!=$originalPage, sort=-date, start=0, limit=$limit"); I haven't tested this but I'd say it should work.

Let's see if I understood you right. "1010" does not look like a title, but more like an id, so I'm assuming you've got a structure like this: /cities/ /munich/ /berlin/ /stores/ /store-1/ /store-7/ /store-12/ /store-17/ /store-22/ Every store-nn page is using template "store" which has a Page field called "city", allowing you to choose a city for this store. Now if this was the structure and you were on page /berlin/, you'd like to find two random children of /stores/ where you've chosen "city" to be Berlin. This should do it (not tested though): $children = $pages->find("parent=/stores/, city=$page, location_category=1065, sort=random, limit=2"); foreach($children as $child) { // ... } And if "city" really was a text field but otherwise I got your intentions about right, you only need to change "city=$page" to "city=$page->title" in the selector.Probably this isn't exactly what you're after, but hopefully it helps you to get there.

I'm not quite sure why this would be any slower when using functions, but here's a couple of things that you could make a bit more effective. Some of it is mostly cosmetic though. This bit of code: $category = wire('pages')->get("/kategorije/$category/"); foreach($category->children as $subcategory) { $subcategories[] = $subcategory->id; } $array = implode("|",$subcategories); $articles = wire('pages')->find("subcategory=$array, template=article, sort=-date"); Could be written like this (letting the core do what you done yourself): $array = wire('pages')->find("parent=/kategorije/$category/"); $articles = wire('pages')->find("subcategory=$array, template=article, sort=-date"); The other two functions have the same bit of code, but with $subcategory->name. I would have thought that doesn't even work.. does it? I think you meant the same thing in all those cases anyway. Then, if you're calling the same functions for the same categories and they all do the same subcategory-thing commented above, it would be better to construct the subcategories just once and use the same array three times. Just give the subcategory array as an additional parameter to the functions you're calling. Maybe there's something there I didn't see right away, but I hope these help even a little bit . The effect isn't necessarily huge as ProcessWire does a good job caching previously fetched Page objects, but I guess it's worth a try anyway.

Yes, old passwords still work after an update in ProcessWire 2.3. New password hashes (new user or an old user changing her password) are just different in a way that is incompatible with older versions of ProcessWire. So no going back to 2.2 (without resetting passwords) after a password has been changed or new password has been created.

Doesn't look like an AdminBar issue to me. I Did a really quick test with 2.3 & AdminBar and everything seems to work great. Was able to upload images, edit descriptions and reorder images right there before saving. Using MAMP with PHP 5.4.4.

(I'm slow, so probably some of this has been said before, sorry.) One reason would be complexity, like Antti said. Adding one level of abstraction on database level doesn't sound like it's going to make things faster, does it? But I must admit I've been thinking about field naming for a minute of two myself without being able to come up with a solution that feels like it's perfect. I've even gone down that "templatex_fieldy" route more that once and it really fits in sometimes, not that I'd recommend it in general though. There are multiple ways of doing things and while it really is a good idea to have generic fields like you've described, it's not necessarily the way to go all the time. And I don't think any of the previous comments were meant to imply that. This I have to disagree with, a bit . I wouldn't describe a repeater "just a container", but that may have something to do with the fact that I've had to debug the code in the early stages of repeaters to solve a performance issue. It sure is a container for *data* but not so much for fields (yes, it's possible to look at this from another direction too). So, in my opinion, complexity is the key once again. I do like the idea of "max items" option for repeaters and that actually would give you one kind of namespacing by setting the limit to 1, but I wouldn't use that as a solution for the problem you've brought out. Not in large scale anyway. Actually what bothers me most with this is probably the name; if the fieldtype is designed for repeating content, shouldn't that alone be good enough reason to at least reconsider whether it's a good fit for namespacing? Yes, I was also a bit surprised to see how easily this conversation went down one particular route. There was more in the topic that just the example you used. Unfortunately I can't give you any more tools to handle things like namespacing or preventing excess of fields than the other guys did. But that doesn't mean I'm thinking there's only one way to do things. I think grouping of fields in the admin does solve a part of the problem (via tags or prefixes) but also I have a feeling there necessarily isn't an easy way to have a short and neat list of reusable fields if the site itself is complex. I'd be happy to see someone prove me wrong though .

Updated version of this module just found its way into GitHub. Now there's a config option "Enabled templates" letting you choose the templates you want the "References" tab to be added to (when editing a page with those templates). If no template is chosen, "References" tab is always shown. Templates with system-flag are always skipped, like fields with system-flag have been from the beginning.

See http://processwire.com/talk/topic/2740-problem-with-access-rules/ That explains it I think.

@arjen, @isellsoap: I'm not quite sure if it became what you were thinking of, but this conversation was the inspiration behind this: http://processwire.com/talk/topic/2967-pagereferencestab/ At least it's something you could use as a base for something more if it's only half way there at the moment.

I did think of other ways to approach this, but couldn't come up with anything clearly better than what I have now. Initially I was thinking of a fieldtype, but somehow I don't (yet) like the idea of a fieldtype with no data of its own. Actually, I don't quite understand what you're saying about how you've solved this yourself . Page select? Where? Still this is just one possible approach and I'm more than willing to change it to something else if someone would come up with a silver bullet or something like that.

Page References Tab This little module adds a new tab, References, to the page editor. There it lists pages referencing the page that is being edited (title, path, field). There are also links to view or edit the listed pages (if they're viewable/editable). Only fields of type FieldtypePage are considered to be references and system fields are not listed at all (roles, permissions). It's nothing much, but as the subject has turned up a couple of times in the forums, I decided to give it a try. So watch out what you're asking! Screenshot Links Modules directory: http://modules.processwire.com/modules/page-references-tab/ GitHub: https://github.com/niklaka/PageReferencesTab

This should be working now on the latest dev. Ryan commited a fix already .

It's sure sounds like a bug. I think it's best if you filed this as an issue on GitHub. That way it definitely gets the attention it needs from Ryan. And I'm going to try and make the test suite cover at least some basic access checks as well.

Are you running the latest dev version? There are some selector bugs fixed there so I'd suggest you try that first. I'm on a mobile now but I can check tomorrow if there are changes affecting this. Unless someone else gets there first .

See Wanze's ProcessBatcher module, I think that would be helpful to you: http://processwire.com/talk/topic/2811-processbatcher/

Welcome to the forums! I think Wanze meant $config->debug = true; You could also try and delete module cache files (in case you've copied site/assets/cache as well): rm site/assets/cache/Modules.*

Looks like that approach should work, at least when there aren't hundreds of private or draft articles. And that allows you to use sort and limit too in the last find(). Actually any other approach would work better in the long run than iterating over the complete list, I guess .

I'm going to jump in, hopefully not just to mess things up . One dirty way to achieve what you're trying to do would be going straight to the repeater items. This gives you the top 5 highest mountains across all reports: $topFiveMaxElevations = $pages->find("template=repeater_mountains, sort=-stats_maxElev"); Technically repeater items are pages and thus you can use find() as you'd do for normal pages. But as I said, I'd consider this a dirty way because it relies on the internals of the repeater fieldtype. It does get you there but at what cost, that I don't really know. And if you'd need any data from the parent page (the report itself), you'd need to get it via getForPage() which returns the page a repeater item belongs to. And like Soma pointed out, there's some redundancy. That could affect the top 5 lists the very moment some mountain ends up in two different reports (unless it's absolutely impossible scenario?). No matter which method you use to collect for example the altitude data, you'd probably need some check to filter out duplicates. And that would make things a bit more difficult as you wouldn't be able to limit to 5 results right away. Oh well, just wanted to mention it. Actually that's what the manual says it will do . See http://php.net/manual/en/function.usort.php where it says "The comparison function must return an integer less than, equal to, or greater than zero" with an additional caution on using for example floats. Your solution is fine though, now you've got it returning integers. Hope I was being helpful, rather that confusing. Time to get some sleep now.

No, unfortunately you can't. That's the "either-or selector" mentioned in roadmap for ProcessWire 2.5+ (Winter 2013/2014). Those examples from the documentation SiNNuT refers to do mention the or-operator, but it can't be used quite like this. "Or" is fine within a single selector but currently there's no support for having an "or" between two or more selectors, it's always "and" which is denoted by a "," (comma). On the other hand, if you don't need native pagination for the results of this kind of query (and there won't be too many results!), you could use something along these lines: $results = $pages->find('fieldA=xy'); $additionalResults = $pages->find('fieldA=z, fieldB=x'); // this leaves no duplicates to the PageArray $results->import($additionalResults); The resulting PageArray can be also sorted and sliced to get exactly what you need. But again, by now you've already fetched all the matching pages from the database into memory, so this is merely to tidy things up - or the core of a custom pagination of course. // sort first by fieldA ascending, then by fieldB descending and leave only 10 items starting from index 50 $slicedResults = $results->sort('fieldA, -fieldB')->slice(50, 10); So for small amount of data there's quite an easy way to get around it. But for larger amount of data you'd need to come up with another kind of method, probably one that depends on the nature of the data you're dealing with.

Welcome to the forums Rene! I think the compatibility check explains it: you'll have to make site/config.php and site/assets writable. On a *nix system it would be something like this: chmod a+w site/config.php chmod a+w site/assets And after the installation make site/config.php not writable again as instructed. (chmod a-w site/config.php, for example). Oh, you did say Windows . Well, still you'd need to make those writable, I'm sure someone with Windows will join the conversation and give you more specific instructions.

Did you try this in your .htaccess already? RewriteBase /processwire-folder/ And then try http://mywebsite.com/processwire/ That would be the url if you didn't change it during the install.

@sevarf2: You hit the same bug I did a while back . See here: https://github.com/ryancramerdesign/ProcessWire/issues/147 So you can either: 1) use trackChange() like WillyC showed you or 2) force the save of (only) the imagefield with $m->save('imageverify') or 3) update to a more recent version of PW where this bug has been fixed (dev branch) and use plain old $m->save() like you were trying to in the first place.