ryan

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.

So long as it was ProcessWire's FieldtypeRepeater that created them, it shouldn't matter. What version of ProcessWire are you running?

Makes sense to me. I'll add that.

This is true for any fieldtype. It just means that any default values required by the module shouldn't depend on the config form being saved the first time. Though there are some fieldtypes that don't become worthwhile until configured (page, repeater, etc.)

Yes, anything that you are inserting into HTML. For instance: <input type="anything" value="this needs to be entity encoded" /> <input type="anything" any-attribute="this needs to be entity encoded" /> <textarea>this needs to be entity encoded</textarea> <h3>this needs to be entity encoded</h3> (The text "this needs to be entity encoded" is the user input, not the tags) Anything in HTML like this needs to be entity encoded, unless you want the browser to interpret it as markup. Usually you don't want user input to be treated as markup by the browser, because it gives them control over the page.

A simple rule to remember is: Any data input from the user needs to be entity encoded before outputting it back to a browser. What is entity encoding? It means taking some special characters and converting them to a format that isn't interpreted by the browser as anything but text. We care primarily about characters used for tags, like "<" and ">", characters used for single or double quotes (especially when values might end up in HTML tag attributes), and ampersands "&". These are the characters that can mean something more than just text to a web browser. But you don't even have to think about this if you just remember to entity encode any output. There are cases where you don't have to entity encode, like if you've already typecast something as an integer, or already run it through one of PW's filtering functions that removes special characters... $sanitizer->pageName() is a good example. But if you want to play it safe, just entity encode everything you are outputting back to the user... there's no harm in it. One way to tell if entity encoding is working is to enter a value like "<b>test</b>" in your form field. When you get it back, if it reads as test rather than <b>test</b>, then you've got a problem. No. $sanitizer->text() filters input for storage, not for output. It limits length and prevents linebreaks, among other things. While it strips tags (unless you tell it not to) it doesn't entity-encode any characters. The reason is that you don't usually want to store entity encoded text, unless it's meant to be stored as markup, like TinyMCE (in which case, none of this applies). So ideally, your sanitization would go something like this: // these values are for API use or storage $firstName = $sanitizer->text($input->post->first_name); $lastName = $sanitizer->text($input->post->last_name); // these values are for output back to the user $outFirstName = $sanitizer->entities($firstName); $outLastName = $sanitizer->entities($lastName); // you might prefer to bundle these into an array When it comes to outputting values that came from the user, the $sanitizer->text(); is certainly a good idea, but it's not required. It's not going to make the text any safer for output than $sanitizer->entities(); will on it's own.

I wasn't able to duplicate this before, but will give it another try. One thing I want to mention is that you've got some extra unnecessary code in there. There's no reason for you to go delete the files separately. What you want is this: $pa = wire('pages')->find("template=video,include=all"); foreach($pa as $p) wire('pages')->delete($p, true); Note the second "true" argument to the delete function. That makes it recursively delete any children too. Otherwise, if your pages had children, they wouldn't be deleted. Another approach you can take is to trash them. Then when you later empty the trash, they should all be deleted. foreach($pa as $p) wire('pages')->trash($p);

The Thumbnails/CropImages module seems to be working here. For those that it's not working for, can you describe further about what's not working and how to reproduce? Are you seeing any JS errors or anything like that?

True, if you don't have control over the structure. In my experience, what's good for the user, and good for the structure, are closely tied together. And it tends to hold true regardless of scale. So I try to base my structure around what's good for the user, and that usually ends up being ideal for everything else. I'm sure there are exceptions though. I think this is okay so long as you don't run into a situation where the same rendered page is being delivered at multiple URLs. If you are dealing with lots of products with multiple classifications, a good approach is to throw them all in a bucket (i.e. /products/) and then relate with categories via page relations. In this manner, you aren't maintaining a separate menu, but building upon existing page relations. I usually have a template called 'redirect' that has nothing but a title and URL field. It's good for handling external links, or even occasional internal links as navigation placeholders. Like you mentioned, this puts it in your page tree. Usually that's what I want, but I tend to only have the need for the 'redirect' template occasionally. With the unknowns in terms of structure that you are dealing with, I think the approach you are taking with separate menu makes sense. It probably also makes sense in this case to go with a more bucket-oriented structure for the content (like the /products/ you mentioned).

I deal with servers set for iso-8859-1 quite regularly, and have never had an issue. PHP isn't exactly UTF-8 native, so we basically treat everything as if it were UTF-8 even if PHP doesn't. But there must be some instances where it does matter, as you've found. I will add the init_set('default_charset', 'utf8') to our initialization. Thanks for pointing this out.

This is true. Currently the autocomplete does not work in FieldsetTabs. It basically has to be visible when the page initializes. I'm not totally sure why, and if this is specific to jQuery UI's autocomplete or something about our usage of it. That ui-autocomplete-input class is one assigned by jQuery UI rather than us.

$page->numChildren is a whole lot faster and more efficient than $page->children->count(). In a case like this, I would stick with numChildren. It's okay if it's occasionally wrong with published or otherwise non-accessible page inclusions. Also $page->children->count() is one of those things you really can't use at the large scale, because it has to load all those pages. If you just need to check if a page has accessible children (regardless of amount), you can do: $hasChildren = $page->child->id > 0; To count all visible children: $numChildren = $pages->count("parent=$page"); I'll add a $page->numChildrenVisible property in the next commit.

Just wanted to reiterate what Wanze said about this: <input type='text' name='first_name' value='{$input->post->first_name}'> This is a major security hole. For example, try submitting this in the first_name field: '><script>alert('Gotcha!');</script> ...and if you can do that, you can do some pretty bad stuff. Definitely entity encode user submitted input that gets output again. Wanze's example: $v = $sanitizer->entities($input->post->first_name); echo "<input type='text' name='first_name' value='$v'>"; If you are running an older version of PW that doesn't have the $sanitizer->entities() method (a fairly recent addition) then do this: $v = htmlentities($input->post->first_name, ENT_QUOTES, 'UTF-8');

Mostly repeating what's already been said. But if that disclaimer page is always going to be off the root, regardless of whether on your development or production server, the I would just do this: <a href='/disclaimer/'>Disclaimer</a> If the site may move around from one subdirectory to another (like between development and production, as is the case for me), then I'd do this: <a href='<?=$config->urls->root?>disclaimer/'>Disclaimer</a> If you want to account for the possibility that the disclaimer page may move, then you'd do this (where 123 is the ID of the disclaimer page): <a href='<?=$pages->get(123)->url?>'>Disclaimer</a> Though note that you are then talking about more overhead in this last example, relative to the first two. So it's rare that I do this, unless it's a page that needs to move often (don't think I've run into that situation).

Eventually we will support this type of OR expression in selectors. But currently you can't do this: (max_date>=$today OR max_date=0). So the current strategy of your setup does not lend itself well to pagination in ProcessWire. What I recommend doing instead is one of the following: Have a separate checkbox for "frontpage_always" or something like that. When checked, it is always used, regardless of max date setting. Rather than checkbox toggles, use page references to provide options like: "Frontpage till max date", "Frontpage always", and possibly others. Another thing to note is that you don't need to convert $today to a timestamp (though it doesn't care if you do). You can just pass in the YYYY-MM-DD string and it'll be fine with that too.

That part I underlined and bolded above is revealing. What type of hash is indicated by $2s? It's not documented with PHP. Blowfish uses $2y, $2x and $2a. I incorrectly assumed that the '$2' set was reserved for blowfish, and looking at this, clearly it's not. It looks to me like it must have fallen back to some kind of DES encryption, but I honestly have no idea what it is. I'm just glad we had that check in there to throw the error, and glad you came here to report it. I've updated the isBlowfish() function to specifically check for only $2y, $2x and $2a and assume anything else is not blowfish. Can you try out the attached Password.php file to replace /wire/core/Password.php? Password.php You will have to reset the password for any accounts that have this unknown hash, as that hash is not portable across systems. You can reset a password from the API like this: $u = $users->get('sam'); $u->of(false); $u->pass = 'new-password'; $u->save(); Or you can just do it from the admin when logged into a superuser account. One other thing to note is that if your passwords are defined on a PHP 5.3.x or newer installation, and then migrated to an [older] PHP 5.2.x installation, the passwords will no longer work. This is because PHP 5.2.x doesn't have the ability to generate blowfish hashes (at least not the kind that are useful for passwords). So if our live server is PHP 5.2 and your dev is 5.3 or newer, only set your passwords on the live server. I also want to recommend moving any PHP 5.2 installs to 5.3. We will be dropping support for PHP 5.2 either in ProcessWire 2.4 or 2.5, as we move to PSR-0 and namespace support.

I agree with JeffS. You could definitely build this in ProcessWire. But no matter what you build it in, it's largely a custom application that will require significant code on your part. That is, unless there is a software that focuses on these things in particular (which might be Moodle, I don't know). In addition to looking at Moodle, a full blown framework might be another path worth considering. If after evaluating the different options, ProcessWire looks like the simplest way forward, we'll be glad to answer any questions and get you started on the right path to building it.