ryan

$pages->get("name=mypage"); isn't a very reliable thing to do just because that query is within the scope of your entire site. Page names are only guaranteed to be unique within the same parent. So you'd be much better off doing one of these instead, which would be guaranteed unique: $pages->get("/path/to/mypage/") ... // retrieve by page path $pages->get(123) ... // retrieve by page ID Since the 'name' is guaranteed to be unique within the same parent, it would be perfectly fine to do this though, where $page is some page with children: $page->child("name=mypage")

Joss, that example you put in there is comprehensive enough that it probably belongs on it's own page in the Wiki. Thanks for putting it together. It's a rather nice tutorial in its own right. Is it possible to move it to a dedicated page?

Thanks for the PR Soma. If you solved this one, I owe you a beer (or a case of beer).

I think nateronn also mentioned this before. This will be one of the major drivers behind ProcessWire 2.4. I'm only concerned about actual bugs at this point for the 2.3 release. But it's a valid point and will make this look nicer soon. If using the same one as before, you didn't actually change the password. In this case, it literally needs the password to be changed.

if("$page->children->product_size") { This is not a valid statement, in PHP or in ProcessWire. If it were valid in ProcessWire, then you could just remove the quotes and it would work. Either that, or you could surround it with "{$page->children->product_size}". However, there is no "product_size" property of PageArray, and $page->children is a PageArray. I'm thinking that maybe you meant this? if($page->child("product_size>0")->id) {

You should be able to get more detail by checking your log file: /site/assets/logs/errors.txt The ideal situation would be to upgrade both to PHP 5.4. But if you can't upgrade the production environment and don't want to downgrade your dev environment, you could set that supportsBlowfish() function in Password.php to always return false. However, I would look at finding a way to get the production environment upgraded because ProcessWire 2.3 is likely the last version that will work on PHP 5.2 (though that's not yet certain).

The exception that you got there would be a bug. I must have broken something during some recent updates to make it pass Nik's test suite. I'll investigate further. But I don't think this is related to your question. You should be able to target the value for a specific language like this (assuming I didn't break that too) $pages->find("title.data$user->language=something");

Creation of markup and CSS isn't technically a design task in the traditional sense, unless the designer literally designs in markup and CSS (a trend I like). Perhaps that comes from the places I've worked, but front-end development was always a development task. The designers dealt with concepts and visuals, not code (markup, css, Javascript and template engines are all code). I think there is more of a blurred line now though, that's a good thing… I've always liked having my hands in both. But I work with a few design firms that outsource development to me, and all provide me with layouts (whether photoshop or some kind of flat image type). I've never had a designer provide me with code... though maybe my experience is isolated there. Photoshop is both a design and development tool. I don't know many web developers that can do their job without some kind of image manipulation tool like Photoshop. So I would disagree with "I should not need a copy of Photoshop to develop". But I know different companies do it different ways. If you've got designers doing front-end development, that's great, but they are working with code, doing development. If they are producing good quality markup and CSS, and really know how to design, they are a "web designer/developer". That term is what defines most of our audience here. Your company should give those designer/developers a raise. So lets say that's your workflow. I agree with Diogo that this sounds healthy… so long as the designers know their front-end code as well as a dedicated web developer. The "logic" that people use in ProcessWire templates is largely presentational logic. If you are trying to follow an MVC pattern, presentation logic is still a component of the view layer. I think this distinction is important. ProcessWire is already handling the business logic. It doesn't really matter whether you are dealing with a PHP API or a template engine, as the tasks are going to be the same. ProcessWire templates can also be used for business logic. Typically we don't want to be processing forms, saving pages, etc., in the places we are generating markup for output, even if you technically can. There are a lot of good approaches one can take to separate concerns. If using an MVC approach, then you would isolate your presentation logic and markup to a separate view, like we do with the Blog profile. (Though in the Blog profile we really do this more for demonstration purposes, as there's not much in the way of business logic.) If you take this approach, you are using your ProcessWire templates as controllers and dedicating other files as views. You can use the TemplateFile() class for views, as the Blog profile does, or you can use some other template engine like Twig, Smarty, etc. I think that this approach may provide the right balance of separation for the environment you've described. But I'm not sure it's worth the overhead unless building some real business logic (like an application) rather than a traditional web site. I'm not sure about the Smarty module, but the Twig module seemed to have the entire PW API available to it.

I think that all the things you mention sound good. A few questions comments though: What would be the benefit of saving content to disk (vs database?). I'm not sure that it really matters to the user where it is stored, so wanted to inquire more about your thoughts here. What would define old entries? I'm guessing in some cases, people would like to just let it go forever (disk space is cheap). Javascript diff feature sounds awesome. Though also have to admit, just being able to toggle between the different versions and see the immediate change (the way you have it working now) is kind of a nice "diff" effect too. You don't necessarily need anything else for a version 1.0. How does it scale? Meaning, what happens when you've got 100 versions. I haven't tried it yet... and maybe you've already figured this out. But I was thinking maybe it shows the most recent 10 edits when you hover the icon, and ajax/paginates them somehow after that? (or opens a modal to a dedicated Process when you click more?) How does one handle deleting versions? I was thinking it doesn't need to be manual or interactive, but just a global time or quantity setting, i.e. "only keep last 50 versions" or "only keep versions for [n] days" or something like that. But having the option to keep them forever is also good… perhaps the behavior when the "[n] days" is left blank. Just supporting text fields for a 1.0 version seems ideal. This probably covers the vast majority of needs. Versioning of files/images sounds fun, but you are right that it's an entirely different task on the development side, since it has to manage files. And these fields aren't just files, but sort order, description, tags… and more in the future. Probably too much work for too little value here. So if it were me, I would just focus on those text fields. I think that the vast majority of versioning needs for files/images could probably be covered just by a file "trash" (whether global or page specific) where one could retrieve old files if they ever needed to… but that would be a different module. To summarize my thoughts: you've already got something great here that is already hugely useful. I'm not sure what more you need to take it beyond proof-of-concept (seems quite functional as-is), but the only thing I would consider is just making sure it can scale time and quantity. And then get version 1.0 out when ready. I think a lot of us can't wait to start using this. If there is anything that I can do to help (code, testing, etc.), I'm at your disposal.

Yes, I think this makes sense. I'll duplicate them there.

Sounds good, I'll setup a default here.

Wanze's example is just demonstrating a bit to get you started. You can hard code as little (or as much) as you want. When we present examples here, it's sometimes easier for people to follow if we hard code some things to make the context clear. But that doesn't mean you have to (or should) do that in your own implementation. Basically, we're trying to teach rather than do it for you, so that you can apply what you learn in a much broader context. In addition to the API page Wanze mentioned, you might also want to look at the /site/templates/sitemap.php file in the default profile. This demonstrates creating a navigation tree for an entire site, and may serve as a good starting point for what you are trying to do.

That error just indicates that there is a name collision when creating a new page. In this case, there is already a page called mariestads-julebrygd and it's trying to insert a new page with the same name (in the same parent). All that would need to be done here is just to make sure that the imported records are unique in whatever is being set to the $page->name field. If there is an ID column of some sort in the XML source data, that would be a good one to use for a $page->name field.

It sounds like you've got a page that needs to be deleted. In your page list, go to: Pages > Admin > Setup > export-site-profile …and delete it.

So long as that variable is in a double quote string (or concatenated to the string). PHP doesn't parse variables in single quote strings. If the variable you are putting in might have characters that could conflict with selector strings (like commas, or |) surround the value in single quotes. like something='$something'. If the variable is coming from user input, be sure to sanitize it. For a string, you'd want to use $something = $sanitizer->selectorValue($input->post->something);

Great module Wanze! Thanks for making this. Definitely going to come in handy.

Teppo, this is really a fantastic proof of concept! Very well put together and seems very much fully-functional to me. Worked great in my testing here. It actually seems like much more than just proof of concept--it's quite stable! Thanks for your great work here. I look forward to seeing this evolve. Let me know anything I can do to help. This is a great addition and perhaps something that should find it's way into the core. A couple of minor optimizations to mention, at line 263 of the main module: // $page = $this->pages->get((int) $this->input->get->id); $page = $this->page->process->getPage(); // if (!$page || !in_array($page->template->id, $this->enabled_templates)) return; if(!$page || !$page->id || !in_array($page->template->id, $this->enabled_templates)) return;

ProcessWire is actually the first iteration of this CMS that doesn't rely on a template engine. And Dictator CMS (the grandaddy of ProcessWire) was entirely template engine based, with no PHP API or PHP support at all. I'm no stranger to template engines. While there are benefits to template engines, my own experience has been that the benefits are largely perceived rather than experienced. There are also some tangible benefits too. But how many of those tangible benefits apply varies greatly from system to system. ProcessWire has a nice API, but most CMSs do not. For many of those CMSs, the template engine is what makes the system accessible (or at least, more accessible). Expression Engine is an example. In those systems, template engines are providing a huge benefit by isolating the developer from having to use a complex or crappy API. Nobody would use these systems without the template engine. But in a system like ProcessWire, a template engine is redundant, less capable, and ultimately more complex layer of overhead. Most of the time, we do not want that kind of extra overhead in ProcessWire. In our context, the only real benefits of a template engine are if you have some kind of syntax preferences (PHP is not always the prettiest syntax) or if you want to have a jail. There are some valid reasons to have a jail, as pointed out earlier… but I prefer education to jail. Still, I understand the reasoning and can't say it's always wrong. Just that it's wrong for a core default. There's also that benefit of perception. If one perceives there are some other benefits to a template engine, they will seek out systems that have them, even if perception isn't always reality. I believe strongly in the benefits of our current approach and API. I feel these benefits are far greater than what comes from any template engine. And I've discussed them at length many times in many places, so I won't rehash that all here. But I've always wanted ProcessWire to support template engines, just not to require one. So I like what I see with the Twig and Smarty modules. Actually, the Smarty module seems like it would be especially simple to work with, since it bolts in so quickly and easily. I hope to see more in this area and am always willing to do whatever it takes to support add-on template engines (we even added a hook or two to support the Twig module). While I personally don't need these template engines and sometimes question their value, I also very much support them in ProcessWire as modules. Perception is powerful, and we're trying to grow our audience. Likewise, there may be some that have template engine preferences beyond just perception. Anything that opens a door for more people is a good thing. While ProcessWire's core isn't and won't be built around a template engine dependency, we fully support use and implementation of them as modules. And I'm also willing to add any new core hooks or capabilities necessary to support the development of such modules.

Lots more dangerous too. Dragging around the fields in a template has no effect on the front-end of a site. It's a totally safe action. Dragging around your pages can break external and internal links, hurt your SEO, or even worse, break your entire site. Move and delete actions are intentionally not as obvious as they would be in an actual file manager. At least, I don't want my clients performing these actions unless they really really mean it. Web sites aren't file systems. In web sites, stuff really shouldn't get moved or deleted very often (it's bad for business). In a file system, these actions are very common. But in a web site, they should be avoided. Though I understand that as developers, everything we do is intentional and we'd like it to behave like a file system for our convenience. But ultimately the admin panel is balanced towards both the client and the developer. The client will be the primary user long term, so feel it's a careful balance. To be honest, I was reluctant to even have a "move" action in the Page List, as it's a lot safer and more intentional to move stuff around using the Settings > Parent field on each page's settings tab.

Same here. I couldn't figure out how to make it compatible with the move action. Spent a couple hours on it and than gave up. We'll eventually figure it out.

Luis, if this is an upgrade, try removing /site/assets/cache/Modules.* If that doesn't do it, double check that when you uploaded the files, you didn't upload them into the existing /wire/ directory. When you upload that /wire/ directory, it has to be a brand new directory. So in an upgrade, you either need to remove or rename the existing /wire/ directory before uploading the new one. Either that or you can upload the new one to something like /wire-new/ and then rename old, rename new once both are there.

In this case, I'm not currently sure how to prevent the circular reference other than disallowing a page from selecting itself. Or rather, having the fieldtype's sanitizeValue method remove the incompatibile value automatically before saving. Not sure if that's what you were looking for?

The list you mention will be very simple from the back-end, so the best starting point is probably to figure out what you want to start from, in terms of front-end framework. Do you want to start from an existing site profile, like the default or blog profile (or another), or do you want to build upon a CSS framework like HTML KickStart, Bootstrap, Foundation, etc. Or you could literally start from scratch, as many of us do. But of the goal is a profile or tutorial, I think it might be better to start from some kind of framework or profile.

Is this a recent discussion? I can't seem to find it.

We don't have the option to place it automatically at the top, just because it has to renumber all the pages when you do that. That wouldn't scale for pages with huge numbers of children. Manual sorting really shouldn't be used when you are dealing with any kind of large quantities of pages. Date, alpha or some other kind of sorting is usually preferable. Manual sorting is meant for things like navigation bars.