ryan

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.

I think it's a fine way to go when there is no way to make the site structure consistent with the navigation, for certain parts (like top navigation or footer nav, etc.) Still I think it's always preferable to keep a consistent site and navigation structure whenever possible. A layer of pages separate from the structure, just for menus, is [in most cases] and unnecessary bit of complexity. But for those times when you will benefit from it, it's a nice pattern to have.

Thanks -- let me know what you find, and I'll do some more testing here too. If you find that it's repeatable, please post a GitHub issue report so that I don't lose track of it.

The reference English translation is actually in the code itself. When you translate a file, it should pick up all the English, ready to be translated. I was maintaining a fake Spanish pack for awhile as a starting point set of files, but probably need to update that as there have been a few additions, though nothing major.

Antti here it is if you want to give it a try. Replace these files with those attached: /wire/modules/Fieldtype/FieldtypeFile.module /wire/core/Pagefile.php Test it out on a non-production setup first, as it does make schema modifications. But once installed, it adds 'modified' and 'created' fields to all file/image fields, and these can be queried in selectors as well. They initially start out at the current date/time. If you modify a file/image description or sort, that updates the 'modified' property. The 'created' property stays the same. Let me know how this works for you? If all is good, I'll commit it to the dev branch. FieldtypeFile.module Pagefile.php

@sam, @apeisa: can you replace the line that says this (in /wire/core/Password.php): if(!is_string($hash) || strlen($hash) <= 13) throw new WireException("Unable to generate password hash"); with this: if(!is_string($hash) || strlen($hash) <= 13) throw new WireException("pass=$pass | hash=$hash | hashType=$hashType | salt1=$salt1"); Let me know what it says? I'm curious what sort of data is in there.

Easier said than done. It's a good idea and a regular need. If it were easy, we'd have already done it.

The issues with specifying CSS at the page level (in the editor) are that it crosses a boundary between content and style. Ideally these things remain completely separate to ensure the long term portability of the content. As a best practice, styling is best kept part of the site's development files rather than it's content. It's also a security concern, in that you are allowing someone to inject code into a page. However, if all the editors are trusted and know how to use CSS styles in that manner, then only you can decide if the convenience is worth the tradeoffs. For instance, on your own blog site (or something like that) it might be totally fine and convenient. But on something bigger you'd want to be careful, as it is crossing a line.

@nik these should now all be working with the latest version of the test suite and latest commit to ProcessWire dev. Thanks for your help in tracking down these issues.

Assuming I understand the need correctly, what I usually do add this to the <head> section of the main markup include: <head> <!-- all your typical <head> stuff --> <?php $file = "styles/$page->template.css"; if(is_file($config->paths->templates . $file)) { echo "<link rel='stylesheet' type='text/css' href='{$config->urls->templates}$file' />"; } $file = "scripts/$page->template.js"; if(is_file($config->paths->templates . $file)) { echo "<script src='{$config->urls->templates}$file'></script>"; } ?> </head> Using this method, if you have a template named 'product', then it could have dedicated CSS and JS files in /site/templates/styles/product.css and /site/templates/scripts/product.js, when you need it. The nice thing about this is that it's just a system rather than hard coded file. If you determine you need something unique for the CSS (or JS) on pages using some template, the you can just create the CSS (or JS) file and have it start working automatically. You can take this further too. For instance, you could use the same technique with page IDs to assign custom CSS/JS files to specific pages.

That error message is coming from this file: /wire/core/Password.php if(!is_string($hash) || strlen($hash) <= 13) throw new WireException("Unable to generate password hash"); It sounds like the server supports Blowfish but when PHP is asked to return a blowfish hash, PHP's crypt function is returning an error for one reason or another. ProcessWire only uses $config->userAuthHashType if the server does not support blowfish. The reality is, it's a bad idea to use anything less when blowfish is available. But in your case, it sounds like we've got the server reporting "I can do blowfish" and then bowing out when we ask it to do so. What you might want to try to do is modify that Password.php file and change this function: public function supportsBlowfish() { return defined("CRYPT_BLOWFISH") && CRYPT_BLOWFISH; } to this: public function supportsBlowfish() { return false; } If that fixes it, please let me know. I can add a config option to bypass blowfish

I'm not sure I understand -- can you clarify? Does it use ProcessWire, or just has similar features?

I think you've probably got it about right in terms of structure, unless your products need to have multiple categories/subcategories. I'd suggest using a different template for category and subcategory rather than the same one. You'd mentioned pretty different output needs between category and subcategory. Not to mention, structurally subcategory requires category as a parent, so you can enforce that with family settings if they are different templates.

It sounds like a bug, so I want to find out some more details on how to reproduce. Specifically, what is the source of $events -- is it a Page or a PageArray? Can you provide the code the came before where $events was generated? Also, do you see any difference if you change it to this? $today = strtotime("2013-02-11 21:34"); $rows = $events->find("event_datetime>=$today, limit=3");

I'm not sure exactly what changes might be necessary to make it work with nginx, but I have no doubt that if you are able to get ProcessWire safely working under nginx, then ProCache should work fine too. However, you may want to remove write access to your .htaccess file so that ProCache can't write to it. That way you are implementing any updates manually (and adjusting them for nginx). I'm curious to know if the ProCache rules work under nginx as they are, or if you have to make any specific changes?

Soma, once we've got 2.3 as the current stable version out there, I'll go through the cheatsheet and figure out what needs to be added, etc.

Thanks for finding that Nik. I've tried to find a simple fix, but no luck so far. It seems that I break a lot of the other tests with nearly any solution I implement, so far. So going to need to find time to get further into this soon. Do you have one of these in the tests?