ryan

I agree with what Adam has recommended here. In my sites, I usually create a /config/ page that is hidden, and then place all my selectable pages under there, like /config/countries/, /config/states/, etc. Note that you don't want your actual 'country' pages to be hidden, just the main '/config/' (or /countries/ if you are using that). The advantage of keeping these as pages is that it's easy to add/edit them, and it's easy to setup a template that could list everything in a particular country, for example. Viewing /countries/france/ can produce a list of all pages that have it selected... a huge benefit. If your sites have highly relational structures like this (with indexable URLs) your search engine performance will benefit greatly, and it's just really useful to have for may reasons, taking almost no work on your part.

It sounds useful! I'm looking forward to seeing what you come up with. Note that there are still more API variables I have to cover in the docs: $users $config $roles & Role $permissions & an individual Permission $fieldgroups & an individual Fieldgroup $templates & an individual Template PageArray I've held off on $roles, $fieldgroups and $templates because I want to tie fieldgroups and templates together like they are on the admin CP (currently they are separate on the back end). For roles, I'm planning to make them assigned to templates rather than pages (as the default option), so waiting to finish that before finishing that part of the documentation.

ProcessWire will support .html extensions. You just have to make them your page names, i.e. "about.html" rather than "about", or look for them in urlSegments. I've actually done this before, though for specific pages (like /sitemap.xml), not on a site-wide basis. But I don't see any problem with it conceptually. There is one implementation problem in that PW2 enforces slashes at the end of the URL. However, I think I should be able to make that part optional as part of each template's advanced configuration. Actually, I'd meant to make that optional even before this question came up. So let me work on that part, and I think this will be an easy addition. As for the value of keywords, I think you guys were talking about two different things. I think Sevarf2 is talking about meta keywords. Meta keywords have never been used by Google, and they were thrown out of most other major search engines about a decade ago. But meta keywords are still valuable if you are running your own spider, perhaps something indexing across multiple platforms on a very large site. But excluding that, there's not much point in using the meta keywords tag. I think it's better to leave them out-- A spammy meta keywords tag can still hurt you, even though a meta keywords tag can't help you. I think Adam was referring to keyword density, like the fact that key words/phrases have to be present on a page (or links to it) in order for it to be matched by Google. And the strength of those keywords can relate to where they are placed in the markup (i.e. <title>, anchor text and headline's carry more weight, for starters). And then there are some formulas about density, but they are a matter fine tuning as well. Roughly 80% of SEO is what happens on other sites, not yours (i.e. who's linking to you), so I usually tell people to just focus on making the site highly accessible with high quality semantic markup and content, and focus on making it something that people would want to link to, and leave it at that. My experience is that the best results come from logical URL structures that are highly readable and contain keywords. I don't think that Google actually ranks based on keywords in your path, but they certainly highlight them in the SERPS, which is worth it right there. I would be surprised if there was any benefit to using ".html" in your URLs on a new site (as opposed to an old site). At one time, I think there was a benefit, just like there was a benefit to using subdomains over paths. Such benefits don't last because they just exploit a temporary vulnerability in Google's algorithm. Ending with ".html" is kind of a legacy thing, present on sites that have been around a long time. Benefits from ".html" might be a side effect of the age of sites where they are used, when in fact it's the age that drives the result. Where I think the real benefit would lie is if you are trying to maintain old URLs that end with ".html". If you've had a page at /page.html for a really long time and it's well indexed in Google, it's to your benefit not to change it. While technically Google should transfer page rank to your new page (via a 301 redirect), it doesn't always work and/or throws you in the sandbox for a little while. Other times, it works as planned, but it's a risk on a high traffic page. So if you are trying to maintain legacy URLs that end with ".html" there is most certainly an SEO benefit to keeping them at ".html". But on a new site, I think I would avoid using ".html" in your URLs. I don't see any real world evidence that ".html" influences performance, and I don't view dust crawling as being applicable for the type of pages we are talking about. But lets just assume that there was some benefit. Using .html in URLs that aren't actually composed of static files that end with ".html", with the intention of swaying Google, would likely cross the line on their webmaster guidelines (short term benefits lead to long term pain). I would avoid .html in your URLs unless it's literally a static page where the file extension drives the mime type. Otherwise, it's trying to deceive Google a little bit, and that's never a good long term strategy. All of this is speculation of course, I don't know anyone working at Google, but I do enjoy the subject! If you know something more about this, please keep the conversation going.

777 can be a security risk on a shared hosting environment, especially if they aren't jailing accounts from one another. 755 would certainly be preferable if it worked. Many hosts will run Apache as your user account, in which case 755 will be just fine. If you are in a shared hosting environment that isn't particularly secure, you may want to just limit write access to your account and whatever account apache runs on. That won't necessarily keep out PHP running on other people's accounts, but it's better than global rwx. However, nearly all the shared hosting accounts of worked with lately have been pretty well jailed from each other, making these considerations not as much of an issue. But the number of hosts I work with are also fairly limited, so this may not be a universal statement.

These are good questions, and perhaps a video would be a good way to demonstrate some of them. But the goal is not to give you a different way of thinking. Instead, the goal is to work with your existing way of thinking and development style. The goal is to get out of your way and support you rather than tell you what to do. Each template is a PHP file and you use it in the same manner that you would use any other PHP file. The only difference between a template (PHP) file and a regular PHP file is that ProcessWire provides you with some API variables giving you access to the data specific to the page being viewed. There are other things it gives you, but just understanding that point is the main thing you need to know. Whether you use the API variables is entirely up to you. It's certainly feasible that your templates could be nothing but HTML (though maybe not that useful, except for something like your 404 page template). Adam did a good job of demonstrating a template as a PHP file, because you can see that 90% of what is in his template is his own PHP code that isn't necessarily specific to ProcessWire. In fact, I don't recognize some of the classes he's referencing because they are his own. He uses the API functions vars/functions where appropriate to pull in the data he needs, and then uses his own PHP code (and it looks like some of his own libraries) to output it in the manner he wants. Your own templates need not be this advanced, nor do you need to know as much PHP as Adam does to make effective use of templates. In fact, I think you can even make very effective use of templates without knowing much PHP at all. But for people that know PHP and have a way of doing things, ProcessWire is not going to get in their way. Because templates are PHP files, what a given template looks like and how you work with it is a bit of an open ended question. There is no right answer to that question, as so much of it comes down to your development style. ProcessWire is really designed to work within your existing development approach rather than trying to dictate your approach. For instance, some will use templates as just HTML files with occasional API variables to output a value for a given page. <html> ... <div id='bodycopy'> <?=$page->body?> </div> ... </html> Using templates in this manner, you don't need to know PHP, and you might not even know you are using it at all. While the other end of the spectrum is to use template files as MVC controllers, or controllers for another PHP application, and then grab their output, i.e. <?php $out = new TemplateFile("./includes/my_markup.html"); $out->set('headline', $page->get("headline|title")); $out->set('body', $page->body); $out->set('sidebar', $page->sidebar); $out->set('navigation', $pages->find("parent=/")); echo $out->render(); Note: The TempateFile is a class included with ProcessWire that you can use if you want to... it's what ProcessWire uses to render it's templates too. A more common approach is for your template to include a header (of HTML and/or PHP), output a content area, and then include the footer (of HTML and/or PHP): <?php include("./head.inc"); ?> <div id='bodycopy'> <?=$page->body?> </div> <div id='sidebar'> <?=$page->sidebar?> </div> <?php include("./foot.inc"); ?> Another approach is to populate placeholder variables and then include another file to output them: <?php $headline = $page->title; $bodycopy = $page->body; $sidebar = $page->sidebar; // render a ready-to-output subnav <ul> list $subnav = $page->children()->render(); // get photo from current page if available, otherwise get it from homepage if($page->photo) $photo = $page->photo; else $photo = $pages->get("/")->photo; // make the photo 300x200 $photo = $photo->size(300, 200); // main.inc is just HTML and outputs the vars we populated above in the right places include("./main.inc"); But these are just a few examples of many possibilities. What I woud recommend is getting familiar with the templates that are included with the basic site profile. Then post questions about any parts that don't make sense, and we'll be happy to help. When you are feeling comfortable with the basic site profile, send me an email asking for the skyscrapers profile, and I will email this to you. This example goes a little further than what's in the basic site profile, but I think it's good to understand the basic profile first. Also, if you want, tell us what other CMS platforms you've used and I can explain what's similar and different in how you use templates in ProcessWire. Thanks, Ryan

There is actually an API variable called $user. It provides all of what you've mentioned. I will do my best to add documentation for it on the site today. Thanks, Ryan

Also don't worry because I totally understand the need for a date-based publish/unpublish, and that's why it's on the roadmap. My intention was just to show a way that you could do it today if you wanted to. Also, I'm always looking for opportunities to post examples.

I agree with Adam.

Okay i think the problem might be the 766 permission. Most likely Apache is running on a different account than yours. 766 will be fine for config.php, but I would suggest changing /site/assets/ to 777, because it sounds like PHP requires "x" in addition to "rw" in order to be able to mkdir().

Adam is right on this. The fact that the installer is finding that the directories are writable, but mkdir() and chmod() are failing indicates something must be disabled. But the way around this is to create the directories and make them writable yourself. Let us know if you need help identifying the directories to create and/or how to make them writable. Thanks, Ryan

Strange, I've not heard of this before. But can you check these things: Make sure there isn't actually a directory called /ProcessWire/ (leftover from the zip). If there is, delete it. Try doing the login page with a trailing slash, I.e /processwire/ rather than /processwire. Try a fresh install, just in case. If none of these do it, can you post what PHP ver and your phpinfo result if possible. Thanks

Hey guys, this has been posted: https://github.com/ryancramerdesign/ProcessWire/commit/4bc0e1136b067bd663426a544a207aab6704147d Includes the expanded JS title->url converter too. thanks, Ryan

Thanks for locating the problem. I broke it earlier this week and fixed it but looks like I must have not committed the updated js file. I will post this when I get back to my computer, within the next hour or so. Thanks!

A page can have multiple parents in the hierarchy (parent, grandparent, great grandparent, etc.) of course, but each page only has one direct parent. On the other hand every page can have any number of relations which are also pages. You could think of them as parents or categories but the use/terminology depends on what the relations are used for. Pages are essentially the same thing as nodes in Drupal. Though I don't like the term 'node' because it confuses the heck out of my clients (the people that ultimately have to use the CMS day to day). You can use a page for whatever you want, it doesn't have to be a literal page on the site. Though every page has a URL, which you can think of as it's GUID. Whether you choose to render content at that URL or not is up to you. I prefer URLs as a globally-unique identifier (GUID) because that's the way search engines treat them, possibly even penalizing the same content at multiple URLs (a part of my full time job is search accessibility and optimization). But of course ProcessWire will let you pull content from anywhere and do whatever you want to with it, but it at least associates that content as having a primary association with a page's URL. You are right that you can select multiple pages using any of it's properties, and then process them in any way you want. To generate a site map, see these: http://processwire.com/talk/index.php/topic,26.0.html http://processwire.com/api/include/ Note that there is definitely overhead with what ProcessWire does in translating selectors to queries, finding them, and creating resulting Page objects. I think it's well worth it. But if you are used to selecting just what you want in SQL and generating a giant site map directly from that, you might be disappointed in the performance if dealing with lots and lots of pages (and/or lots of autojoined fields on those pages). If I'm generating a site map for a large site, I'm usually caching the output so that it doesn't have to be generated on each view. While I've done my best to optimize all of this, I'm sure there is still lots of room for optimization. For instance, I am pushing an update today or tomorrow for better caching selectors and their resulting PageArrays. I'm always tweaking this to make it better/faster, and the more eyes on it, I think the better performance we'll get out of it. Yes, namespacing is badly needed for those that plan to include ProcessWire for it's API from other apps and CMSs. But to do that, we have to drop PHP 5.2 support, and I don't think it's safe to do that quite yet. Thanks, Ryan

I came to the same conclusion as Adam looking at this. I've not seen the DOCUMENT_ROOT show as something different from checking the dirname(__FILE__) before. But clearly it's possible for that to happen, since we're seeing it here. So it's something that ProcessWire should probably be on the look out for. But I think it might be best for me to do more research and make sure this isn't an anomaly just specific to your server. So in the short term, I do think it's best to set the rootURL manually in the /index.php file. But will do more research here, unless anyone else knows if this is a known situation on some servers. Thanks for the debugging you did in finding this.

This topic has been moved to FAQs. [iurl]http://processwire.com/talk/index.php?topic=44.0[/iurl]

I will add this to the roadmap as a module (most likely a Fieldtype). But also wanted to follow up with the strategy that I use, and the reason why the need for a publish/unpublish by date has not come up before. It's because this is so easily accomplished with the API. It also gives you more control over how you want to react to such dates. Here's how: Lets say I added a datetime field for publish date and/or expire date to the page's template. That template checks it's dates before it outputs anything. For example, lets assume we added a datetime field to the job_advert template called "expire_date". When we edited a job advert, we selected an expire_date of February 1, 2011. The job_advert template might have code like this: <?php if(time() > $page->getUnformatted('expire_date')) { throw new PageNotFoundException(); // or print "sorry this posting has expired" if you don't want a 404 } // print the job advert Note that the getUnformatted() function above is necessary because ProcessWire will return a formatted date according to the format you specified when you created the field, "January 21, 2011" as an example. So using getUnformatted() is a way to ensure it returns a timestamp that you can use for comparison with other timestamps (like that returned by PHP's time() function). (Btw, that getUnformatted() function works with any field, returning text fields without entities or runtime markup, etc.) Lets say that you also wanted to move the job advert to the trash since we now know it's expired: <?php if(time() > $page->getUnformatted('expire_date')) { $pages->trash($page); // move it to the trash throw new PageNotFoundException(); } // print the job advert Next lets assume that you didn't move the page to the trash, but you are just leaving it where it is and not disabling it or anything. If that's the case, you'll want to check that it's not expired when you links to your job adverts. So here's what your list_job_adverts template might look like: <?php $now = time(); $jobs = $page->children("expire_date>$now"); foreach($jobs as $job) { // print the job listing, being confident that it's not expired } If you had both expire_date and publish_date fields, then you'd find those jobs with something like this: <?php $now = time(); $jobs = $page->children("expire_date>$now, publish_date<=$now");

Nicolasbui, Thanks for your feedback. I am impressed at the level with which you've looked into ProcessWire. I am sure there is lots of room for optimization and improvement in many parts of the software, as the code is all quite young. And finding ways to optimize it is one of the most satisfying parts in my opinion. It's also one of those things that I am very thankful to have people like yourself helping me with. I would like the software to be as optimized as possible. I agree with you in theory about using a nested set model. While I've not spent a lot of time using the nested set model, I am fascinated by it. But let me explain why I believe the adjacency tree model is preferable in ProcessWire. Then, please correct me if you think I'm wrong on any points. • I view the nested set model as a compromise for the structure because it would take it far away from the methodology of the API. Currently, the structure matches the terminology and methodology of the API, maintaining a good level of consistency between DB and API. I believe this makes it more accessible for one to understand should they want to break out of the API and into MySQL. While it's rare for someone to need that in producing a site, I think it may be more common for people developing modules. • With the queries used for page rendering and common API use, there are very few in ProcessWire that would actually benefit from the nested set model (at least from my understanding of it, and in the sites I produce). And, I may be wrong on this, but I can only identify one page render dependent query that would see a possible performance boost, and this query is most commonly executed only once per request. Not to mention, it's already quite fast, executing in 0.0003s (average, on my server with a page 3 levels deep). • On the sites that I run, the database is rarely the bottleneck. Of course, this will depend on how you are using the API. But most of ProcessWire's queries avoid the tree entirely and are instead focused on the fields that make up a page. • Should the query mentioned above ever become a bottleneck due to a change in the API or new needs, etc., the plan is to index page paths in the database or in the file system cache. While a compromise to support speed over normalization, the result would be faster than the nested set model. Of course, it would also be more expensive when moving a page, but an okay compromise. • I think the nested set model may show measurable performance improvement in ProcessWire with sites that have very deep hierarchies. However, such a level of depth is unusual on web sites and not that practical to manage. I don't believe I've ever gone more than 4 or 5 levels deep in a hierarchy, even on a very large site. Even if you see a URL deeper than that (at least on my sites), there's a good chance it's one or more urlSegments used for branching and not an actual page in the hierarchy. These are the reasons why I think the current model is preferable in ProcessWire, but there may be more benefits to the nested set model applicable to ProcessWire than I realize. Let me know your thoughts. I'm always interested in creating a new branch to experiment if it makes sense. Thanks again for taking the time to look at ProcessWire in this depth. Thanks, Ryan

Thanks for your report, I think this makes sense and will put it on the issues to fix list. I guess that I've never had to revert back to blank for this, but it's clear we need to be able to do that.

I agree with Adam. It does sound to me like something is going on with the apache configuration because where would /var/www/ be coming from if it didn't exist? I'm guessing it must be somewhere in the apache config. If you'd like, post your phpinfo or email it to me, and that may provide some answers.

Not yet, but we'll be making language packs for the admin, and it'll be pretty easy to do (well, the code side of it). The language part I'll need help with. I wasn't sure how many would be interested, so that wasn't high on the list before, but there does seem to be interest so it will probably be implemented sooner rather than later.

I totally agree, I think that's a good suggestion. I'm adding it to my list.

Sounds like we were typing at the same time. Your reply was waiting right after I posted. It sounds like you are talking about just the image sizes used in the rich text editor. In that case, ProcessWire is not resizing the source image (it's creating copies), so you are good there. But my understanding is that you think it should limit the size of the image that shows up in the textarea, so that you aren't trying to scale an image back that's 5x bigger than your screen. I think that makes sense, good idea.

Thanks for the feedback! In Mozilla-based browsers (and in IE8) you can resize directly in the editor. In webkit based browsers, you can't resize in the editor because Webkit apparently doesn't support selectable divs (or whatever method is used by TinyMCE). However, you can still resize easily just by clicking the image, clicking the image icon, and then the popup should still let you resize. Then click "insert image" and it'll put in the image resized and resampled at your dimension. Regardless of what method you use, the result will be the same, and the code it runs through on the back end is the same. Regarding image size, I always recommend uploading images in the largest possible size you might ever need, so that all of your resizes are starting from a really high quality source. Typically you don't actually use them at that size in your output. Instead, you specify the dimension, ProcessWire will create the resized version and cache it for future use. For example, this is how you might print out a gallery of thumbnails that links to larger sizes, like you might use with lightbox script: <?php foreach($page->images as $image) { $large = $image->width(500); $thumb = $image->size(100, 100); echo "<a href='{$large->url}'><img src='{$thumb->url}' /></a>"; } You can create as many size variations of an image as you want. I believe this is preferable to having it resized to some target dimension in the admin because all of your size variations can start from the source.

Kristof, thanks for your message. Good to hear from Belgium! If you are looking for front-end user interaction like you see with Drupal, that's something that ProcessWire doesn't emphasize very heavily at this stage. In part, because I am a fan of Drupal for that type of site. That will change with time as more and more ProcessWire modules become available. On the other hand, you certainly can do any type of front-end features that you want if you don't mind some development. An example can be found on the Templates and API forum where a user asked about how to save contact form submissions as pages. And there was also a question about how to setup pages that users could login to: http://processwire.com/talk/index.php/topic,22.0.html http://processwire.com/talk/index.php/topic,17.0.html This sort of stuff is pretty easy to do in ProcessWire, but to do these things you have to think of ProcessWire as a tool that you can make it do whatever you want, rather than as a ready-to-go solution. With time, we will provide lots of good starting points for these things, including multiple site profiles.