ryan

Very cool, it looks like the 2 languages work beautifully in this example. This is the first time I've seen such a solution in place, nice work. I also like that the language-switching links stay on the current page, so that hopefully Google will index the whole thing in both languages (using the url segments). My only concern would be about whether this might confuse Google (or other search engines)–I suppose that would only confuse Google if GoogleBot maintained session cookies… and I don't know if it does. But if it does, you might be better off requiring a form POST before setting the session cookie to change the language, setting the cookie with Javascript, or forcing the language URL segment to always be on the URL for one of the languages. The last solution mentioned there would be the best but also be a little harder to implement. If you are interested, I can describe how to do it. But if potential confusion to the search engines is not a concern, then you don't need to worry about any of these as the site appears to function beautifully for the user.

This is an excellent idea. This is what PW uses for cleanup when you delete a page. For a site-wide cache clear of images, this may work very well. But on a really large site, it may be slow (or run out of memory) since it'll involve loading all the pages on the site. So for the image cache clear that I'm writing, it's going to most likely just stick with hunting in the file system and confirming that it's a variation based on the existence of the full size image.

Great–glad that worked with minor changes. Thanks for the follow-up. I'm thinking we should adjust the date-based selector strings to automatically run strtotime on any strings passed to it that aren't all digits. That way we wouldn't have to use strtotime to build the selector in instances like this.

Thanks for the kind feedback. I know what you mean about the terminology for templates. A template might be described as a page type (or content type) in other CMS projects. Despite the literal definition, the word 'template' can evoke a file rather than a type. I think this is because of the way the term is used in other CMSs. But in PW, the file is just a component of the template. It's an important connection, but one that I get tripped up on wording sometimes too. Maybe the best way to describe it as the "template's file", clarifying that the file is owned by the template. I would refer to it as an "output file" or a "view", except that they are not always accurate… Your template's file might just as easily be a controller that's calling upon other views. I guess it just depends how you are using PW, and there are plusses and minuses to not being too specific with the terminology. Perhaps we will come up with some better terminology at some point, so lets keep thinking.

Thanks for posting this. 1&1 is a large hosting provider, and if they require modifications to the default htaccess in order for the site to work, this is really good to know about. I'm sure this will be helpful to others. I'm just wondering if there is anything I can do to avoid having it not work in the first place at 1&1... it's not safe for me to assume a www redirect in the default .htaccess file, or to apply a rule like that based on the status of HTTPS. They must have an unusual configuration at 1&1. I will do more research into this.

Thanks for posting! I'm sure this will definitely help out many people looking to install on IIS. I need to link to this post in a couple other spots too.

Thanks for the followup and glad to hear it's working well.

Thanks for posting. I'm guessing this part is necessary because 1&1 is defaulting to PHP4? (and this forces it to use PHP5?) AddType x-mapp-php5 .php .html .htm AddHandler x-mapp-php5 .php .html .htm There are some security considerations with making HTML documents run through PHP, so unless you need that, you may want to remove the .html and .htm extensions from being parsed by PHP. Why are these lines necessary for 1&1? RewriteCond %{HTTPS} off RewriteCond %{HTTP_HOST} !^www\.(.*)$ [NC] RewriteRule ^(.*)$ http://www.%{HTTP_HOST}/$1 [R=301,L] Is looks like this redirects a non-www hostname to a www hostname (we're doing the opposite with processwire.com). Thanks, Ryan

I don't see your template here, but it came through in the email I got. I've never used output buffering in my own templates so don't know if there is some unusual side effect resulting from that. PW is already output buffering everything in your template, and you are output buffering on top of that. Should that matter? I have no idea. But so far that's the only thing unusual I can spot about your template. Does the problem occur only on pages using that template, or on others too?

Thanks for your feedback. This is an interesting topic, and I'm not sure that I totally understand what you are saying, and may need more context. But looking at the diagram you linked to, it reminds me of why ProcessWire was built in the first place. I'm equating their 'sections' with templates in ProcessWire. But their definition of templates are also something separate beyond that, and 'entries' are a separate entity from 'pages' (if I'm understanding it correctly). While the terminology is varied, this is what I was describing as one of my fundamental problems with EE and Drupal. I'm not suggesting it should be a problem for you or anyone else, but for the sites I develop and the way I develop them, I don't like extra layers of complexity that fall outside the context of the front-end. Not specific to Symphony, but consider: channels, nodes, taxonomies, categories, sections, entries, resources, and on and on. Taken in the context of the front-end and boiled down to their core, they are all pages or behave like pages. Looking at the big picture, IMO these are all unnecessary complexity and that's why ProcessWire is designed exclusively around pages. Earlier versions of PW and Dictator have been split out into more layers (not unlike that diagram, and even using some of the terms mentioned above). Over time I've found more benefit to reduction and simplification. Far more benefit than to the occasional and potential flexibility of keeping them separate. if you get deep into the API, you'll even see one hold-out: Fieldgroups (aka sections in Symphony) are separate from Templates in the API, but not from the admin. And that will probably change eventually too as we work to simplify more and more. The goal with PW is not to solve all needs, but to solve most in the simplest way possible. I like to wander into concept and theory, so please forgive me for straying off topic a bit. It sounds like you are talking specifically about building forms... though I still haven't figured out how to connect that with the diagram. But we don't have a form builder (other than the one used by the admin). The form builder is scheduled for version 2.3 of ProcessWire. So this type of feature is on the roadmap, but multi-language functions are coming first. The form builder is not next on the priority list only because it's not something that necessarily provides more flexibility, just saves time (i.e. you can implement forms of equal flexibility and power without a form builder). The challenge will be to do all this while continuing to make the system simpler, and we'll get there.

It should be fine to remove all of those. I would suggest disallowing indexes just for security (keeps prying out of directories without index files). But if indexes are already denied, then all good. The ErrorDocument stuff is just an optimization to keep the favicon.ico and robots.txt requests from getting sent to PW. It is fine to remove those. The FilesMatch is a secondary measure and it should be okay to remove. Several of the RewriteRules are doing roughly the same thing. The php_flags are just optimization and are fine to remove. Likewise DirectoryIndex is fine to remove.

Adam, can you try clearing your cache: Admin > Modules > Page Render > Clear Cache To me it looks like a permissions issue. So if you get errors when clearing the cache, or if it doesn't work, you might want to try and remove all the dirs below cache/Page/ manually. i.e. rm -rf /site/assets/cache/Page/* I think Almonk also wrote some shell scripts that do this. Let me know if the error persists after clearing the cache.

Okay good news, this is now available in the latest commit of 2.1: https://github.com/ryancramerdesign/P21/commit/da6418cedeede89b7039341536641e5080fea144 To use it, you have to add a ".count" to the end of your field name. Using your example from above: $children = $page->children('images.count>2'); The reason you have to use ".count" is because without it the operator is comparing the image's filename. While I could redirect the ">", "<" and related comparison operators to the count, I wanted to find a consistent way to do this throughout the system, and adding ".count" to the field name seemed the most logical way to do it. You can use this with any multi-value field: files, images, page references, comments, etc. You can also use it with a page's children, i.e. $children = $page->children('images.count>2, children.count>0'); Note that all pages have a 'children' property, so it can feasibly match any page. But maybe not all pages in your system use a template with the "images" field. PW doesn't attempt to match pages that don't even have the field, so if you did this: $children = $page->children('images.count=0'); ...that will only match pages that have an images field with zero images. It won't match pages that don't have an images field. This is for consistency with other selectors. Please let me know how this works for you and/or if you run into any errors with it. Thanks, Ryan

Hi Stephen, Welcome to the forums and good question. Here's one way you could approach it, assuming all those posts were under the same page (like /blog/). I'm somewhat limited on time right now, so this is written in the browser and not tested, but I can follow up with more detail later if you'd like. <?php $blog = $pages->get("/blog/"); $startYear = date("Y"); // this year $endYear = 2009; // or whenever you want it to end $now = time(); for($year = $startYear; $year >= $endYear; $year--) { for($month = 12; $month > 0; $month--) { $startTime = strtotime("$year-$month-01"); // 2011-12-01 example if($startTime > $now) continue; // don't bother with future dates if($month == 12) $endTime = strtotime(($year+1) . "-01-01"); else $endTime = strtotime("$year-" . ($month+1) . "-01"); $entries = $blog->children("created>=$starttime, created<$endTime"); // or substitute your own date field $date = date("m-Y"); echo "<li><a href='./$date'>$date - " . count($entries) . "</a></li>"; // output the month and count } } Then you'd use the same template to list the entries when a $input->urlSegment1 has a date specified in it. Basically you'd cycle through the $entries found above and link to them. This is rough and just approximate. I'll be glad to follow up with more detail... but wife is telling me to get off the computer.

I've got an update for you in 2.1 which makes this available. I'm going to run it through a little more testing tomorrow, and if all checks out I'll commit this to the 2.1 source.

Well PW 2.1 is very close to becoming the current stable version. I have a few details to take care of, but think it's just about there (perhaps by the end of the month). I'll keep the 2.0 branch going for bug fixes but probably won't be adding new features to it... this is already the case.

Thanks for the feedback, glad that you are finding a lot of sites to be a good fit to develop in PW. I've not yet had the opportunity to try out Symphony, but had heard good things about it (and like what they've done with their site). Still glad to hear that PW makes it easier to manage page content. I remember several years ago there was a fairly impressive new blog platform that came out called Symphony (not sure where that went)... and then there is the Symfony framework (different spelling). A little confusing, but it is a good name. Even though I've not used Symphony, I have used quite a lot of other CMSs. EE was one of the more frustrating to me because there was so much to like about it (people, CodeIgniter, design, company), that you are willing to go further, invest time into it and look past some of it's strange ways. So the "deal killer" moments came later and were a little more frustrating. I think those "deal killer" moments are different for every person, so it's not to say anything bad about EE other than relative to what I was looking for (and I'll still use it when the project requires it). But now you have to invest money in it before you can even try it. I suspect this is why they don't have a free demo version of EE2 anymore (they did for awhile). With the current CMS landscape, one probably isn't going to be willing to invest the time to figure their way around the odd complexity of EE unless they've already bought it (IMO). And once you've invested that time to really learn it, at least it doesn't let you down–it gets the job done. But it hurts that portion of the audience that seems convinced they are locked-in and incapable of learning anything else.

Well it's actually easy to identify the resized versions because they always follow a common format of filename.123x456.jpg (or substitute another width/height and image extension). Whereas the originals have the same filename, but without the .123x456.jpg part. So the cache clear will be pretty straightforward to write... it'll just look for any images that have that last part and a corresponding filename without it. Then it'll remove all the versions with the .123x456.jpg in the filename. But tracking them down requires a regular expression, so it's not something you can do so easily from your OS (unless you are good with unix file commands... I wouldn't know where to start). So assuming that the full size versions you already have in there are good, then you should be able to resize them to a different dimension. That leaves you with just the extra/unnecessary files you want to delete. Do I have it right?

Adam, ProcessWire doesn't actually resize your original image, so they should still be in tact. All you have to do is change the resize dimensions and it should be creating the new sizes from the original. But if you want to go in and delete all the extra files for sizes you aren't using anymore, give me a couple days. I'm working on an addition to the FieldtypeImage module for that (an image cache clearing module).

I don't think as much about the mathematical stuff (as much as the SQL stuff), so I'm glad you guys are looking at it in this perspective too. Ultimately we're translating to SQL logic and the 'making sense' part is preferable to mathematical rules since selectors are a form of data queries rather than mathematical statements. But ProcessWire selectors are something new and aren't based on any existing standard, so we're kind of defining the standard here, and that's what I really like about these discussions. The more thinking that goes into the details like this the stronger it will be.

I was just reading this post on how to make breadcrumbs in ExpressionEngine (http://bit.ly/hello_crumbly) and how you basically have to resort to a plugin to do it for you. It reminded me of some of the problems I had with EE when I was trying to use it and develop in it awhile back. One being that URLs aren't a primary/unique key to a page, natively in the system. Imagine ProcessWire with only it's root level pages and url segments, and that gives you an approximation of what you have to deal with in EE. I'm not saying it's wrong, but it's a different approach, and one that I found frustrating to work with. The post also made me realize I didn't have anything on the site demonstrating how you might make a breadcrumb trail (other than in the default site profile). It's really a simple thing (at least, relative to EE), so figured I'd post here. : <?php foreach($page->parents() as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } You may want to output those as list items or add some >> signs between items, but as far as code goes, the above is all there is to it. What it's doing is just cycling through the current page's parents till it reaches the homepage. Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through: <?php foreach($page->parents()->append($page) as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } The reason this is so simple is because every page is anchored to a specific URL and those URLs are representative of the site's actual structure. Pages in PW are actually uniform resource locators (URLs) whether on the front end or the back end. Because of that, there's no guesswork or interpretation to be done. In EE and Drupal (as examples) that data does not natively live at a specific URL. Instead that data is off in a separate container and the ultimate URL (or URLs plural) where it lives–and will be presented by default–are not as cut and dry. Yes, you can install plugins or go through strange taxonomic/channelistic/cryptic trials to approximate the behavior in other systems. And yes you can use url segments and pull/render any other pages you want in ProcessWire according to your own needs. But I'm talking about the fundamental and core system differences. This difference goes far beyond simplicity of generating breadcrumbs–it is a factor that translates to simplicity throughout the API.

Thanks -- This logic has been updated in the latest commit.

PW is treating that literally exactly what it says: id != 5780 OR id != 5800 If you read that logic, you'll see that it can't ever exclude pages from that. But it's a bit of a mind game, because I think people actually see this, even though it's not what it says: id != 5780 AND id != 5800 Anyway, the proper way to state such a condition in a selector is: id!=5780, id!=5800 But what is the point of a OR "|" in a negative condition? Considering your example, it seems the "|" in a negative condition is useless. I'm thinking we should have the PageFinder engine consider the "|" (OR) an AND when in a multiple value negative selector ... because this seems like a more natural/expected behavior. I had assumed it must be a bug when first trying it, because I was looking for the same behavior you were until I realized PW was actually doing what it was supposed to... though this behavior seems futile. I'm going to change it unless anyone else wants to weigh in on this or catches some logic I might be missing?

Are there any hidden files in there? try this: ls -alR /site/assets/

Adam not sure why that would happen. Can you rename the /site/ dir? Are there any files in there (/cache/Page/ or /sessions/) that don't have the right permissions?