ryan

Thanks for sharing this with us, looks good! Please post to the modules directory (under the site profiles category) when ready. As a small, though not really necessary optimization, that big switch statement might convert nicely to something simpler: $names = array(null, 'one', 'two', 'three', 'four', ...and so on); $column[$key] = $names[$value];

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

Exceptions are catchable, not hookable. I could probably add a hook to manually trigger in PW's main exception handler. Though if a DB exception occurs at bootstrap time (which is when you'd likely see it, if it occurred), then any modules wouldn't yet be loaded. This would also introduce the potential of infinite loops, like if any of the hooked functions themselves triggered an exception. It would be more likely to occur in this case (the last resort exception handler) since an exception at this point is a fatal error and means something about the system isn't working.

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.

The tooltip() is something that's part of the most recent jQuery UI versions. We're using the latest jQuery/jQuery UI in 2.3. I don't think that there is a tooltip() in the version of jQuery UI used by PW 2.2.

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.

Antti is correct that it is assumed as the default template when you only allow one. If you select more than one, then it will allow any of them to be used, but will select a default for new pages based on whatever the last child used.

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; }

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.

Thanks Antti, I'll get this fixed here early next week. For now, replace filter("template=organization") with filter("template.name=organization");

Thanks for sending the database. This helped me to track it down quickly. The issue was that you've got a role named "edit". Because roles themselves are just pages in the tree, that name is overriding the URL segment "edit" used by the module that lets you edit roles. It's attempting to literally load the page living at URL roles/edit/ rather than the role editor. I will find a way to prevent these from getting mixed up in the future. But for now, your best bet is to either delete or rename your role that is currently named "edit". The way to do this is to go edit the role from your Page List tree, rather than from the Access tab. i.e. click Pages > Admin > Access > Roles > edit, in the Page List tree. Rename it from "edit" to "editor" or something else if you prefer.

Nico, one other minor point. I'm having a little trouble differentiating the numChildren quantities in the Page List from the page titles, just because the font and color appear to be the same between them (as in your first screenshot). As a result, I'd recommend a minor tweak of making the quantity number visually different in some way. Usually, I've just made this number appear a light grey to differentiate it.

I actually did something similar on one of those villa sites, so that I could randomly pull from pages having the highest quality images. I have a Pages::save hook that saves the average width of all the photos on the page to a hidden integer field. That way I can use $pages->find() to find villas with best image quality (or at least, largest images) and sort by that, etc. In your case, you might want to do the same thing, except store the height. If all the pages have the same number of images, then you could do combined height. If they are differing numbers of images, you'd probably want to do average.

Very nice Nico. I like how clean it is, and the background color relative to the white inputfield boxes is pretty. My first thought was "where are the breadcrumbs?", but then I figured out it was in the footer. It's a nice variation and actually looks great. Though I'm having a little trouble with it in Chrome just because Chrome uses that space to display live messages (loading type messages, etc), which initially masked that the breadcrumbs were there. Still it might just be a matter of getting used to it. But I'd probably find it more usable to have the breadcrumbs at the top rather than the bottom. I'm not suggesting you change it, because that's just subjective on my part. However, the one thing I ran into that you may want to change is the foreground color for when rolling over an asmSelect list (see attached screenshot). Also, please add to the modules directory when you get a chance. Thanks for the nice work here.

I completely agree with the things Joss said about scalability. But it's not such a big task to move from one server to another either (hosts like ServInt can even do it for you). So I wouldn't let scalability drive the decision unless your scalability needs are short term or recurring. If resources and redundancy are similar, I think it's worth paying a little extra for dedicated. If you get a seriously major cost, resources or redundancy benefit from going VPS, then I'd probably do that. Though I'm not sure that resources on a dedicated and VPS are apples to apples, so personally I'd sacrifice slightly on resources to have dedicated if I could get the prices in a similar range. I have (via my clients) both high end VPSs and dedicated servers in a similar price range. Both perform beautifully. But I feel a little better about the dedicated machines because the resources just seem a little cleaner... no worries about what other high traffic sites we might be paired with, burst memory/CPU, etc. Just raw resources ready for anything.

You won't be able to do this at the DB level because width/height is not stored in the DB. As a result, you won't be able to query the DB based on height of an image unless you manually store it yourself in some other field. However, I think you could probably do a $page->images->sort("height"); at runtime.

If there aren't any viewable children, then count($page->children) and $page->numChildren will be 0. Keep in mind that ProcessWire doesn't include unviewable pages in $page->children unless you add "include=all" or "check_access=0" to your selector. So there's really no reason to cycle through the pages and check if they are viewable unless they aren't viewable due to lack of a template file. Also keep in mind that a page is viewable or not viewable within the context of a user. So just because they are viewable to you doesn't mean they are viewable to an anonymous user browsing your site. So if you want to see how it will look to other users, logout and then view the page (or view it in another browser where you aren't logged in).

Have you tried installing to localhost or somewhere else, just to see if there is a host issue? Sometimes mod_security and related can cause some unusual things to happen. Because the behavior is unique and unusual, it does make me wonder about external factors at the host or even a potential database corruption. So you might try running a DB repair just in case. If you'd like, PM or email (ryan at this domain) a copy of the database (or the whole profile) and I can check it out. You definitely don't have to start from scratch.

I've taken a look but am not sure I fully understand what the module does or how to install. Though it looks like there is a lot there and quite extensive, so looking forward to learning more. Could you add some additional description and instructions to the module page? If you'd also like to post any screenshots of example output to this thread please feel free. I can copy them into the module page so that they appear there too.

Tested out and is works great! Seems like a nice remix of some other themes and I like the color similarity to the default admin theme too. Everything seems to work very well and look good throughout. The only comment I would have is a little initial confusion about the logout button, since it's right next to the search box. I also have a little bit of a preference to have the "site" button offset from the top navigation in some way. But those are just personal preference and nothing more. Overall a great theme!

Years ago when I was doing hosting research Wiredtree and Knownhost came up as having good reputations at webhostingtalk.com, which is where I've always gone to research these things. Good to hear these are still recommended by folks. That's where I originally found out about Servint too. All other things being equal, I think it's good to choose a host with a data center relatively close to you geographically (ping times can make a difference). Though overall history and stability are still the most important to me.

It is possible, and I've thought we'd eventually do this but it just hasn't come up before now. Fieldtypes can modify their own schema by keeping a schema version in their field settings. Both the comments, and files/images fieldtypes do this in 2.3 to support new features. So will take the same route with the integer type to support the things you've outlined. Should be able to visit this soon after wrapping up the new version. Btw, the way I've handled this in the past is to create the field in PW, then go into phpmyadmin to tweak the details. But I'd rather people be able to do this all in PW. Still if it's something you need today, it's generally safe to modify a field_* table schema to suit a specific need.

I don't think there's any intention of replacing the logo with PW, but we just need an alternate square logo for the situations when a long horizontal logo doesn't fit (like the wiki). I agree that a mark (something other than PW) that can go with the logotype, or go by itself, would be great. But a branding challenge too.

Looks nice! I look forward to trying this one out!