Leaderboard

I think this makes sense to do it the way renobird suggested, with an asmSelect. It should be easy to do, so I've put this on my list for when I get back to the office.

This probably needs to be in the "Wishlist & Roadmap" forum, but I'll post it here in case anyone has another solution. I need to be able to select more than one label field when creating a page field. In this particular case, I need to show the user's name, as well as the university ID#. See screenshot for clarification.

Were those results obtained over an internet connection, your local lan, or testing on localhost? I did some benchmarking of my own a while back and as part of that I benchmarked static file serving times on Apache2 and nginx. I was getting times in the order of 56μs per read from Apache2 and far less on nginx but that wasn't over the internet. FWIW, here are some apachebench results for default installs of PW on Apache2... ...the "failed attempts" are false-positives as the default site homepage has a random image. (Apachebench assumes all reads will lead to the same sized data and flags all following reads that return different size pages as "failed requests".)

Change this: foreach($titles as $title) { if($page->children('title=' . $title)->count() !== 0) break; ... } to this: $children = $page->children("include=all"); foreach($titles as $title) { if($children->has("title=" . wire('sanitizer')->selectorValue($title))) continue; ... } That "include=all" in the children call ensures that the children are included even if in the trash. It's also better to just do one $page->children() call here, because every time you pass in a unique selector to children(...) it executes another query. This way, it's only executing one query. The wire('sanitizer') call isn't technically necessary for the page title's you've given, but I put that there just in case your actual page titles might contain commas in them. But honestly it would be better to use the page "name" property rather than title, since it is limited to a small set of characters, guaranteed to be unique for the parent, and more appropriate for this type of thing. If you use $page->name, you could optimize it further by changing the first line to: $children = $page->children("name=" . implode('|', $names)); You could do this with title too, like Pete was mentioning. But it's a little harder to account for the page titles in OR selectors since there is such a broad set of characters allowed in titles.

Hi antknight That wouldn't work - like I wrote that would produce an error 500. However, I found the cause of the problem in the .htaccess file: #Options +FollowSymLinks Once I commented out this directive, the problem disappeared. I found the solution here: http://www.wallpaper...pache-t718.html And a general explanation of the directive here: http://www.webmaster...orum11/1962.htm I hope this helps others with the same problem. /Allan

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.

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: parent.name=about parent.name=about|contact parent.title*=Something parent.body*=Something|Something Else parent.title|parent.body*=Something|Something Else parent.template=basic-page parent.template|template=basic-page|fancy-page // and I think this is the one that @nik requested: parent.title|title*=Something Pretty much any combination of stuff can be used with the parent selector. Previously, you could only use id or path. As an added bonus, you can now also perform partial matches on a page name: name%=something name^=some name$=thing parent.name%=something parent.name|name%=something parent.name|parent.title|title%=something|something else These new features are available via the latest commit to the dev branch (upcoming 2.3).

Make sure you are logged out too. Pages aren't cached for you when you are logged in. There are other factors that can disable the cache, but most under the template settings. And of course a page is only cached once the cache has been generated, so if you are hitting a bunch of pages for the first time in an hour then it's likely none of them were cached. In general, cache is only used for the 'guest' user. I am working on a so called super cache module that bypasses both MySQL and PHP. It uses the apache rewrite engine to pull cached urls directly from static files.

For pages that you want to automatically direct to the first child, I would make them use a template that has this in it's code: <?php if($page->numChildren) $session->redirect($page->child()->url); If you add a new child page, and they aren't sorted by date added (descending) then the newly added page isn't likely to be the first child. If no default sort is selected, then it'll add it as the last child. So if you wanted to redirect to last page (rather than the first) then you'd want to do this: <?php if($page->numChildren) $session->redirect($page->child("sort=-sort")->url); By the way "sort" is just a name representing the order that pages have been dragged/dropped to. That's the default value if a page doesn't have another field selected as it's default sort field. The minus sign "-" in front of it represents descending sort. Without the minus sign, it would be ascending. Since you want to select the last page, that's why it's "-sort" rather than "sort". Or if you wanted to make it select the most recent page added by date: <?php if($page->numChildren) $session->redirect($page->child("sort=-created")->url); The above is also descending since most recent added would be the highest date.

(can someone check this for accuracy and let me know any changes I should make - I am very new to PW) I wanted to create a simple select drop-down, but there isn't one in Processwire by default. Reading the forums, it became clear this was for very good reasons and that you are expected to use pages. But I couldn't find clear instructions how to do this. So, having worked out how, I wrote myself this little tutorial: ##################### Processwire by default does not have a simple select field. The reason, given by Ryan the developer, is that a plain simple select field is not related to the database, so you have, in effect, some of your data in a flat file - sort of - which is not good practice. The preferred way of doing select fields is by using pages for the values and the Pages field to list them in your form. If you just want a simple on/off state, use a checkbox, but if you need more options, then this is the way. Creating Pages for Select Fields These pages must be published to be accessible by the pages field but are obviously not wanted on the website. First, create a dummy template (a tempalte with no associated file) called something like "selects." Give it two fields - the normal title field and a text field called select_value Create a Top Level (child of Home) page called Selects (or something friendly). Give it a blank dummy template. Make this page hidden. Create a child page and call it something that will work for this group of selects - perhaps call it "Yes No." Again, give it a blank dummy template Create three children under this - one called Yes, another called Maybe and a third called No. Use the dummy template "selects" that you created earlier. In the select_value field put a value - in this case the most obvious would be yes, maybe and no! For ease of use, make sure these values have no spaces or anything clever. These three pages will be your select values. How to add to a template Create a field using the Pages field type. Call it something like "yes_no_maybe_selector" Under the details tab, select the single/null option. Under the Input tab, select the Yes No page as the parent. This will then display your three children in the select. Choose either Radio or Select. Add this new field to your template in the usual way. How to output into your template.php The field is called in the usual way, remembering to call the particular value from the select page. So: $page->yes_no_maybe_selector->select_value; The chances are that you are going to use this as a condition - if "yes" do something, if maybe do something else and if "no" do something else again. IMPORTANT: You cannot set a default state - so you will always have another option - Null. So, if you are only wanting to do a two way selection, then you are probably better off just doing a simple checkbox. In this example, therefore, we will effecting have Yes, Maybe, No and Null - that is no, twice! Never mind.... First, lets add it to a variable: $yesno = $page->yes_no_maybe_selector->select_value; Now, we can set up our variations. if ($yesno === "yes") { echo "Say Yes"; } elseif ($yesno === "maybe") { echo "Shrug your shoulders"; } elseif ($yesno === "no") { echo "not a chance"; } else { echo "nada"; } Note that the last option is effectively the null option, so something is being outputted, even if it just some blank space which saves potential errors or silly bits of markup (well, in my case that seems to happen!) And that is it! Joss

Hey all, I'm releasing a new admin theme called Elegance. I tried to keep the look and feel of ProcessWire, but with a modern clean and robust touch to it. Special thanks to nikola, soma and adamspruijt, because I've used components from their themes that I liked (hope u guys are okay with it ). GitHub: https://github.com/u...ganceAdminTheme Direct download link: https://github.com/u...hive/master.zip

Hi, just had some free days and build my first admin template. I'm open for any ideas how to improve it. You can download it here: GitHub Greets, Nico

I'm quite new to ProcessWire, but I'm already there where the fun part starts I'm trying to build a module which fires when a page with a certain template is saved. It should create a set of four child pages of this page then. Each of this four pages has a template which has the same name as the page title. It works so far, but there is a problem when this page is deleted afterwards. The error message is: "Duplicate entry 'filialen-3235' for key 'name_parent_id' I suppose that if a page is moved to the trash, it is saved again, therefore the function runs again. Somehow I have to suppress the trigger if the page is moved to trash, but I don't know how. Thanks for any hints! My code looks like this. I'm sure it's pretty inelegant. public function init() { $this->pages->addHookAfter('save', $this, 'createPages'); } public function createPages($event) { $page = $event->arguments[0]; // if template of page does not have id 46, do nothing if($page->template->id !== 46) { return; } // four new pages should be created $titles = array('child1', 'child2', 'child3', 'child4'); foreach($titles as $title) { // if page already exists: break if($page->children('title=' . $title)->count() !== 0) { break; } // else: create new page $newPage = new Page(); $newPage->template = $this->templates->get(strtolower($title)); $newPage->parent = $page; $newPage->title = $title; $newPage->save(); } }

Thank you all so much for your really fast support! What an amazing community this is! Yesterday evening I came up with if($page->status === 8193 || $page->status === 10241) ... as a temporary solution, because I wasn't aware of $page->isTrash Thanks, Soma! At the end, I followed ryan's advice: I'll stick with $page->title, because $page->title is anyway needed when the new pages are created. In my case, that's not problematic, because the four child pages should always have the same names/titles, without any spaces or special characters. The reason why I set up this module is: I have a client who needs a bunch of microsites. Every microsite has the same pages (home, imprint, contact... etc.). Because some of the placeholders are used on one or more of these pages, it's more comfortable for the client just to edit one page (the parent of the four childs). With this plugin, the client has not to take care of creating the child pages himself (in fact, I have set appropriate permissions, therefore he even can't create or edit child pages). Now, he is able to create all of the microsites with just one form - with the help of ProcessWire! Great solution in just two days altogether. I like this system so much, I'm sure it will have a bright future.

Yes there is, see http://processwire.c...rd/#entry21465. Do you still like it? (Edit: I'm slow...)

Pete, this might be good help also: http://processwire.com/talk/topic/1901-possibility-to-login-user-through-api-without-knowing-password/

Sounds like the bug has been fixed in Chrome, and we're just waiting for an updated release now. http://code.google.com/p/chromium/issues/detail?id=143354

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. +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.

I am just as interested in the supercache as you guys, so will be continuing to work on it and hope to have this ready by the time 2.4 rolls out. 22ms vs 160ms -- I'm actually surprised the difference isn't greater. There is a lot more difference in what is actually happening then those numbers indicate. But there are also a ton of different things that can affect those numbers, so am thinking it depends where and when you test. If performance optimization is key, you want to make sure you are using a PHP cache like APC or eAccelerator, etc. You'll also want to use PW's built in template cache and MarkupCache where appropriate. Making sure that PHP has enough memory to do it's just and that MySQL is optimized for your traffic situation is also going to make a difference. A supercache can't be used on any page that needs to consider GET variables, session variables, cookies, randomization, etc., so it's not a substitute for a well tuned server. But it's a great addition either way.

What about it? Sorry, I have no idea what you mean, so am trying to determine if there is something I need to fix.

Another way to approach the modal option is to just add an extra class to your body tag when it detects modal: <body class="<?php if(input->get->modal) echo "modal"; ?>"> Then just hide the elements you don't want on the modal view: body.modal #sidebar { display: none; }

Welcome aboard If we assume that these will be the only four child pages then you could do this maybe (untested): if ($page->children()->count() > 0) { break; } else ... Or if there could be more child pages then the other way would be: $skipchildcreation = 0; foreach ($page->children as $child) { if (in_array($child->name, $titles) { $skipchildcreation = 1; } } this way you could use the variable $skipchildpagecreation to skip page creation or not - the important thing is you need to iterate through the child pages to determine the page titles. EDIT: I think there's a third way that is a bit like you're trying to do iterating through the $titles array (which looking at it now should work), but off the top of my head you could delete that foreach and do something like: if ($page->children('title=' . implode('|', $titles)) { ... the | symbol in selectors acts like an OR from an SQL query. One thing I've run into recently that I thought was just me is a selector bug in the Dev branch but I'm pretty sure that doesn't apply here anyway.

There isn't such a thing, at least yet. But if you allow only one template then it is assumed.

Strange - now i added a new "FieldsetOpen" field and a FieldSetClose was added automatically. Before that didn't happen, don't know why... (maybe i just did not recognize it somehow). So my question is answered: The FieldSet (Close) is added automatically. Edit: I tried to reproduce how it happend and i guess i have added the FieldSet (Open) and didn't recognize that the FieldSet (Close) was added automatically. Then i tried if another FieldSet (Open) would work as FieldSet (Close) and because it did not work in that way, i deleted it - and i deleted the automatically added FieldSet (Close), too - but didn't recognize that it was there. So it was no bug in there somehow in a special scenario - everything works fine!

good work Nico. I just tweaked the breacrumb for myself, I use the breadcrumb really often and so I moved it to the top. For those interested. Open the main.css in /templates-admin/styles Search #main add: margin-top:32px; Search nav add: margin-top:32px; Search #breadcrumb change: bottom:0px to top:0px;

I think I found the problem. It was just a TinyMCE thing. Uploaded a new version on GitHub. Should work...

I suppose this is down to scalability in the end. If you have a very clear idea what you need and how much power you want, then a dedicated machine might prove a very controllable option. If however, you may want to increase scalability, then a VPS or cloud solution may give more versatility, both in price and power. Although things like Amazon can be pricey, I like the idea that you can scale DOWN as well as up! Also, there is the clients' needs (business-wise rather than technical). If they have no need for a dedicated server for themselves as such, then they may or may not be happy being tied into a developers machine; if the relationship goes sour, it gets very, very complicated. I look at this from the point of view of buying a car from a dealer. When you buy, it makes sense to take advantage of the dealers servicing options and so on. But you can choose to make that a contractual relationship or a casual one - if you just tend to use them out of habit rather than because you have welded yourself to them, when they mess up you can simply go somewhere else; you don't have to first of all get the car and the car keys back from them. In my main business (music production and writing), clients use me because they like me, not because they are contractually or technically bound to me. If I tried that, then they would go elsewhere pretty damned quick! I think at least part of the IT world has got itself into a mess because it has tried to enforce client loyalty rather than keep the client by offering good services and building a good relationship.

Hello kongondo & welcome to the PW forum. Whilst I agree that Ryan's produced an amazing product in ProcessWire I think it goes beyond just the software. Of the CMS devs I've been involved with Ryan's the one project lead who has been the most open, from first contact, to meaningful contributions towards the site, docs, forum and code. Some others have been open, most friendly, but none to the same degree. Consequently he's attracted a welcoming, talented & professional group of people to the project and I've learned a lot from being involved here.

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 writing this. There's many ways and different use cases, and that's hard to write everything down to not get to lengthy. Some thoughts. This technique with pages and a page field or without can be used for various things. You can build such helper pages to build a select on the frontend only and render the options in a foreach. Doing it this way you benefit from being able to add and move options in the admin page tree, and allow the editor to even edit or add to them. And all stays in the same manner as all other pages. I can tell my clients "well there's the pages that make these options and they know how already". Being everything accessible through API so easy, would make it easy to even build some little tool in the backend to manage those options outside the page tree, to go even further. Also those page references are great for doing categories, tagging, ingredients, .. whatever. And later those pages can be even used in your site and make them accessible and give them a template. There you then show all pages that have a reference to the currently viewed category. I've for example created a whole shop where the navigation are the categories and articles are just linked to some category and display when browsing the category tree. And best of all it stays flexible and can be adapted or expanded in no time with no limits. One could write down a whole book solely on this subject as it's endless, but guess nobody would buy it. Creativity is what I enjoy in PW. One thing about selects having a empty option. This is simply to be able to "deselect" it in the admin. So if you use page field select for doing something on the frontend you would use usually check for if not empty to determine if anything at all. So your example could aswell be like this: if ($yesno) { // anything selected? if($yesno == "yes") { echo "Say Yes"; } elseif ($yesno == "maybe") { echo "Shrug your shoulders"; } elseif ($yesno == "no") { echo "not a chance"; } } No need to write === here, == is sufficient I think when comparing strings. You do triple === usually on comparing objects.

A pretty neat quick reference to (modern) PHP. With info for beginners but it can also be of use for those already 'in the know'. http://www.phptherightway.com/