ryan

It was dropped before going into the core just because timestamp is already the native storage state of all date fields. When output formatting is off, date fields are always timestamps. When output formatting is on, you can get the timestamp of any date field like this: $page->getUnformatted ('field_name'); So I figured that having an output formatter that returns an unformatted state probably wasn't worthwhile.

Use something other than $user for this: $user = $sanitizer->username($input->post->user); That overwrites the $user API variable in your template file, so better to use something like $username or $name or the like. It's probably not the issue here, but still something to fix just for good measure. What is the URL in your browser window? When you access that URL independently of a login, do you get something different?

AlexV, what was the output of your $selector (in the <h2>?). The code looks good to me, but I don't know the full site structure either, so don't necessarily have the context to relate it to that.

No problem I don't mind adding this. Though am thinking this is one where it would be more efficient for us to just suppress the error (with a leading @). Just committed. I think this will fix it, but please let me know if you find this doesn't resolve it.

I like your idea of adding a "wire" template language! We can just stop referring to it as PHP and then all of the sudden people will see: wow this is a really easy template language.

Thanks for testing Apeisa and Sinnut. Right now the intended audience is us, as you might guess from the included blog entries. But once everything is worked out with it, the intended audience is folks that want to write blog entries and don't know how to do any development. That's the audience that we have no connection with at all right now, but is WordPress's biggest audience. I'm not too worried about this audience understanding the PHP side of it, because I want to make it technically unnecessary for them to have to do anything at that level. But in order to best support that audience, I also think there needs to be some abstraction on the code side. I did start out with a structure a lot more like the basic profile. But after working with it a bit, decided to build this in the best and most efficient way I knew how. We're already covering the basics in the default site profile, but don't have anything out there that shows how to build something for larger scale. While this isn't particularly large scale, I decided to approach the profile from a development perspective in the same way I'd approach a site I'm building for a client. Though I'll usually bundle some of this stuff into modules, distancing it from the site templates. I may still do that, but still debating the merits of it in this case. Another factor here is that I wanted to support really easy theme-ability, where you'd never have to make the same change in more than one place. If you want to make this thing run on Twitter Bootstrap rather than Zurb Foundation, all you need to do is replace a few classnames at the top of the file (in the constructor). If you want to make all images follow HTML(5) rather than XHTML syntax, then you only need to change it in one place, and so on for any tag. I didn't want to commit 100% to one CSS framework over another, so trying to keep some things abstracted here so I could swap in another framework without having to change the code. For the sidebar widgets, I'm thinking about taking a module approach for those rather than a template one. That way people could install a new widget (as a module) in one shot rather than having to add a template, add fields to it, and create a page for it.

Here's the first version of the blog site profile. I was wondering if anyone could help me test? To install, download a brand-new copy of ProcessWire (it must be the latest commit). Then remove the 'site-default' directory that it comes with, and replace it with the one in the attached zip file. Then load in your browser to begin installation as normal. Edit: see this message for the latest version. Thanks, Ryan

Just a quick note about output formatting. You always want it on before outputting anything. This ensures that when you output $page->title (for instance) that characters like '&' will get entity encoded to '&', and the like. Whereas, if you were setting values to the page, you'd want it to store '&' rather than '&'. So updating an earlier example, you'd want to do this: echo "<a href='{$p->url}'>{$p->title}</a> " ; // output formatting should be ON here since you are echoing output. // now you want output formatting OFF, since you are setting values and saving a page: $p->of(false); // same as setOutputFormatting(false), shorter syntax. $p->subway_station = $pages->get("/subway_station/sub_st_0111/"); $page->save();

Make sure that you aren't outputting anything the call to $session->redirect(). In order for a redirect to work, it must happen before any output is sent. Also, make sure to sanitize your 'id' variable by typecasting it to an integer: $session->page_id = (int) $input->get('id');

I've always thought that the "template engines make it easy for non-programmers" was a myth, as it really just comes down to semantics and what characters you think are easier to type. But the reality is that template engines give you something like a jailed environment, and that increases the comfort level of some people. The prospect of limitation becomes an asset in that context. It means it's going to be harder to break things, and there is going to be a ceiling on what can be learned. I don't ever want to be in a "jailed" environment with a low ceiling, but also kind of understand the appeal to someone that may have never stepped beyond the likes of EE (which has come crossover with our audience). As we work to broaden the audience for ProcessWire, an alternate template engine for those that desire limitation here may help us to capture new audiences. There is also just the word "PHP", which scares off some, regardless of what is real or what we do. ProcessWire is always going to be an PHP API-driven environment at it's core, but I'm not opposed to adding on template engine(s) as an option for those that want them, in the future. It's something that's not at the top of the list on priorities, but it is something we'd like to eventually offer. They are a little more tricky to implement in PW vs. a system that is built purely for tags. The reason for this is that ProcessWire templates are executed directly by PHP rather than by ProcessWire itself. ProcessWire just hands off some API variables to the templates and lets PHP and the template execute natively. It's nice, fast and efficient. (Other systems like EE actually execute PHP code in templates using eval(); which is slow and inefficient… they hope you won't be using much PHP). The way we'd have to implement a template engine in ProcessWire, while still retaining the speed, is with compiled templates. The template using template-tags would have to be compiled to a native PHP template before it could be executed. Lots of these new template engines are designed to work that way anyway, so not a big deal, but just outlining how it would be done.

You could also do this in your homepage template: echo $pages->get('/path/to/page/')->render();

Try this one: $invoice = $this->modules->getModuleID('ProcessInvoice'); $invoicePage = $this->pages->get("template=admin, process=$invoice");

Can you suppress this error with $config->debug = false; ? If not, we may need to add a version check before calling debug_backtrace.

So long as the servers can share a common file system (or give that appearance), you should be able to set this up. For instance, your /site/assets/ could be a symlink to a dir on another server. But PW needs to be able to scan this directory for files, open files that are in it, and place new files into it when it needs to. PW uses PHP functions like move_uploaded_file(), copy(), rename(), getimagesize() and others to act upon the files in /site/assets/ as needed, which is why they must be accessible as if they were local.

This looks pretty awesome Nico! You should start a separate thread for this release. It looks like it provides one of the important capabilities we want to add in the future, and this answers a lot of questions on how it can be done. Though it looks like it may require that everything be writable on the user's web account, and this isn't the case with any of mine at least. But that can be solved by having the module go through and perform its installation via FTP (which is what the WP installer does I think). I see the unlink_recursive function, which the name of which scares me a little. I'm sure it's completely safe, but just wondering about the option of having it archive (perhaps to some other dir) rather than delete stuff? Either way, this looks like a high quality and ambitious module, nice work!

Marty, I can't take on more work here, but am always available to talk you through how to do anything. I'm guessing that one of the other guys here that might have availability will contact you offline. But if not, post some more detail on what you are trying to do and we can talk you through how to do it (or how to estimate it if that's what you need).

If the content you want to add consists of fields that would be applicable all users, then it's preferable to add them directly to the user template. But if it's content that is only going to be applicable to some users, then may be better to make them child pages.

Right now the field is basically following the rules of PHP's URL filter. I can experiment more with this to see about adding mailto. It does make sense as a possible configuration option as there are many places where you might want to use mailto where you'd also use a URL.

Thanks for the feedback everyone. @Soma: I'd like to support themes, but not really sure how since /site/templates/ pretty much is the theme. I may end up moving some of it to a module so that the theme aspects can be better isolated, but not sure it's the best way to go. I've taken a different approach with the development of this to maximize markup reusability. I'll be curious to have some more eyes on this and see what you guys think is the best way to maximize the flexibility too. @Apeisa: I didn't observe this issue in iOS, but unfortunately I didn't have any other mobile devices to test with. I'm trying to get the profile to be as good of a starting point as possible, so am removing most Foundation-specific classes that are stylistic in any way, so those gradients will be gone in the next version you see. @Teppo: Trackback support isn't there now, but sounds like a good idea for the future. I don't know how to implement it at present (and have never used them), so will do more research. The blockage of the back button is intentional to prevent double posts and allow for potential single-use validation keys. However, the form should have everything they entered in it without them having to click back. Though if they enter an invalid email address, it'll remove it. Error messages have never been comprehensive here, but will be improved as upgrades are made to the Comments field, separate from the blog profile. Thanks, Ryan

There are a number of ways to do this, but for the purposes of an example, lets look at your first one: Brand. Lets say you've got your brands as pages here: /brands/acura/ /brands/audi/ /brands/ford/ ...etc. Your search form might look like this: $checkedBrands = $input->whitelist('brands'); if(!is_array($checkedBrands)) $checkedBrands = array(); foreach($pages->get('/brands/')->children as $brand) { if(in_array($brand->id, $checkedBrands)) $checked = " checked='checked'"; echo "<label><input type='checkbox' name='brands[]' value='{$brand->id}' $checked> {$brand->title}</label>"; } And your search processor might look like this: $selector = ''; if(is_array($input->get->brands)) { $brands = array(); foreach($input->get->brands as $brand) $brands[] = (int) $brand; $input->whitelist('brands', $brands); if(count($brands)) $selector .= "brands=" . implode('|', $brands) . ", "; } $vehicles = $pages->find("template=vehicle, $selector"); Now when it comes to showing something like models, you'd either want the models to have a page reference selecting a brand they relate to, or you'd want to make the models children of the brand. That should make it fairly easy to determine your models once you know the brands: $models = new PageArray(); foreach($brands as $brand) { $models->import($pages->get((int) $brand)->children); }

I'm not sure I understand the question 100%, but I think we need to take a look at the code that actually generates the selector (rather than just the code that generates the form). Also, while developing search engines, I always find it helpful to output the selector that is being used. Once the site is finished with the development then I remove it. But to do this, you may want to add something like this at the top of your search results: <?php echo "<h2>" . htmlentities($selector, ENT_QUOTES, "UTF-8") . "</h2>"; ?>

I don't understand what you mean about "denounced by phishing hotmail", so might need more explanation there, but understand the rest. Whether it's a security hole depends on your hosting environment. If you are in a shared hosting environment and accounts are not fully jailed or virtualized from one another, then a directory set to 777 will be writable by other users that also have accounts on the same server. But in this environment, just changing to a different permission doesn't totally solve the problem either, because the other users can still write to your directory so long as Apache is running as a shared user. Still, the user would have to be on the same server and have an account just like yours, so the culprit will be easy to spot for your web host. Given that they haven't identified a "who", I think it's more likely that you have another software installed on your account (WordPress compromised?) and that any writable directories are being taken advantage of from your own account. Either that, or someone guessed the password for your PW admin account. So check into these possibilities. Either way, inquire with your host what permissions they recommend to make files writable to your CMS. Then update the relevant settings in your /site/config.php. You'll also want to adjust the permissions for files already on the system. I'll be happy to tell you what to do, but we need to know what permissions your host says to use, as what applies to one system may not to another. Best case scenario is that Apache is running as your own user account and that we can remove all write permissions except to you. But even that won't solve a hacked WordPress or compromised password.

The term "block" implies generated output or some understanding of what the final output is. PW is meant to be totally markup and output independent so there is no concept of anything relating to generated output. It may be web-based, but the content it's managing might not be. It's the opposite of something like Drupal. I'm not saying the other systems have the wrong approach, because there are benefits and drawbacks to different approaches. But I've been working on this blog profile for ProcessWire the last couple of days and my mind is entrenched in blocks at the moment. I'm not sure if this is exactly what you are trying to achieve, but what you guys are describing sounds kind of similar to the "widgets" sidebar in the blog profile. There is a multi-page reference field called 'widgets' on the homepage. You select (asmSelect) from different widgets (pages) that you want to appear in the sidebar (i.e. Recent Comments, Recent Posts, Twitter Updates, etc.), and then drag them in the order you want them to appear. All the pages in the site inherent these widgets. When other pages in the site have their own 'widgets' field, it gets prepended to the list of widgets inherited from parent pages. Though I'm thinking about making it override rather than inherit, as I'm just trying to find the easiest to understand solution for new users. But regardless of where it ends up, it was pretty easy to setup: // inherit and append widgets $widgets = $page->widgets; foreach($page->parents as $parent) { if($parent->widgets) $widgets->add($parent->widgets); } // output widgets foreach($widgets as $widget) { echo $widget->render(); } I'm guessing this is still different than what you guys are talking about, but figured it might at least add to the conversation since it sounded somewhat similar to what's already been mentioned.

Currently ProcessWire only attempts translation on page names. There is some overhead with doing it, so we avoid it where possible (like with filenames). If there's more demand for doing this, or if we find ways to make it happen without extra overhead, it would certainly be a consideration down the road.

Not currently, but will keep this in mind for a future version.