teppo

First of all, Soma, this looks VERY nice! Will install it right now One thing that might be worth mentioning is that since Windows doesn't have getrusage() implemented (correct me if I'm wrong) this might cause some problems in Win-environment. Might be worth checking if it's available first and possibly even providing an alternative solution?

Amazing news, Ryan -- congratulations!

That sounds pretty much right. After moving PW from public_html/folder to public_html things should (mostly) work instantly, but one thing you will need to take care of are in-bound links; if you've created links to local content, they're probably relative and pointing to /folder/whatever-link-target/. You could either change these links directly from database, install Page Link Abstractor to handle this for you or use this little snippet by Soma. Another option, of course, is to export a page profile and re-install PW at public_html with that. This won't take care of the link problem, but in that case it would be quite easy to replace all "old" links in MySQL dump before running install process.

Hello there! Just wanted to say that I like what you're doing -- I've actually built something quite similar and found it very useful for (especially) larger projects, so I'm certain that this kind of module has a lot of potential I'd also like to make some suggestions, if you don't mind: * First of all, you might want to consider adding a separate directory for view files -- or perhaps making this configurable via module settings. Currently there's a small but still existing chance that view and template names could conflict. Making this user-configurable would also make this module usable out-of-the-box for those of us who prefer their own folder structure instead of flat templates directory. * Second suggestion / observation is that the way you're currently handling template names might not work as expected for templates that have been set to use alternative template filename via advanced template settings. I'm not sure if you would really consider this a problem, but I felt I should mention it anyway, in case you didn't remember that this kind of option existed. Anyway, with this setting in some cases a) multiple templates might have same filename and b) filename might not contain actual template name at all. This might cause problems, since your code seems to expect that it always does: $template_obj->filename = str_replace($templateName, $view . "-" . $templateName, $template_obj->filename) To be honest I'm not even sure that I understand why you're using str_replace() there -- wouldn't it better to simply set $template_obj->filename as $view . "-" . $templateName? This way alternative template filename, if given, would simply be ignored and view filename would always be consistent with actual name of that particular template. * And finally a quick comment on something quite subjective: code readability. The cleaned up version Some presented above is actually quite a bit easier to read and understand, partly because those comment blocks are (somewhat unnecessarily) taking some serious screen estate, but also because it seems generally speaking more polished. One very specific thing I'm having hard time wrapping my head around is your variable naming convention: $templateName = (string) $page_temp->template; // We pick the template name... $template_obj = &$page_temp->template; // ...and the template object associated. In that short code sample you're already using two naming conventions, first camel case and then delimiter separated. Picking one of those and sticking with it will make your code more predictable and readable in the long run. Trust me, I'm really not trying to be condescending here -- this is just one of those little things that will really help other programmers understand (and appreciate) your code. And that's it for the nagging. All in all it's really nice to see people posting (especially) these kind of proof-of-concept modules here. Pushing boundaries is always admirable, and that's exactly what you're doing here. Keep up the good work!

The obvious problem with this approach is that you need to understand how caching works and what results it can have; ie. after adding these headers some users won't see new versions of changed files until a year later, which could result in quite a few strange situations. Of course you could say that your files never change, which may or may not be true (or if they do, all related filenames also change.) For me, at least, it just doesn't work that way. That's also why I don't think something like this should be enabled by default -- although I do agree that PW could perhaps provide an easy mechanism to set something like this up Here's another (rather good) article about expires headers by Christian Johansen. Highly recommended, if you're going to play around with those.

Slightly off-topic, but did you guys know that PHP, since 5.3.0, also includes goto? Comeback of BASIC programming style! --- Seriously speaking, that xkcd comic at the bottom of manual page linked above pretty much summarizes how I really feel about this..

First of all, you'll get more descriptive error messages by turning debug mode on in /site/config.php. It's very useful while developing, but you shouldn't keep it on after a site has been made public -- in error situations like this it'll output way more information than you really want visitors to see. Problem here seems to be that you're using PDO commands while what you should be using are mysqli ones with $db->query(), since it actually utilizes mysqli under the hood. More information about this can be found here: http://dev.mysql.com....choosing.html. Another (minor) problem is that you're using event as a constant at that last row (that $rows[0][event] should be $rows[0]['event'].) With following changes your code should work properly. Note that I've also added extra check to the end of the script to make sure that some events are actually found. Originally you were only checking if a mysqli_result object was returned.. which doesn't necessarily mean that any data was found $day = date('d'); $month = date('m'); $table = "timetable"; $rows= array(); $results= $db->query("SELECT event,time,location FROM $table WHERE day = '$day' AND month = '$month' ORDER BY month ASC"); if ($results) { // loop through the result set and inspect one row at a time while ($row = $results->fetch_array()) { array_push($rows, $row); } } if (count($rows)) { $event = $rows[0]['event']; } else { // no data found. you might want to add some kind of error message here. } ...

Sounds very unlikely. Could you provide us some information about how things work in the server end; what configuration settings does each site have? Also: is there a possibility that file upload related PHP settings (such as temp dir, upload_max_filesize or max_file_uploads) could be site-specific? And one more thing: have you tried watching Apache error log while doing uploads -- does anything strange show up there?

If you wish that content to stay same site-wide, easiest (and probably most logical) solution would to add field for that content on your home page and let the user edit it there. As an example, let's imagine that your content is plain text (or pretty much anything that doesn't need to be iterated through) and you've created a new field called "header_content" for it. After adding that field to your home template, you could do something like this in your site-wide header file: <?php echo $pages->get('/')->header_content; ?> I hope this answered your question!

This module adds basic capability to restrict page rendering to selected number of IP addresses. Note: this is only meant to be used as an additional security measure in addition to typical username/password authentication or something similar, not on it's own! Currently individual IPs (127.0.0.1), IP ranges (127.0.0.1-127.0.0.255) and CIDR format (127.0.0.0/24) are supported. You can also decide whether restrictions should apply to a) admin area and b) authenticated users. By combining these two options you could create a site with public access restricted to selected IPs while still allowing users outside those addresses to have full access after authenticating. Better description can be found from README. And once again: all comments, bug reports, feature suggestions etc. are more than welcome! So far everything seems to work as planned, but I haven't had the chance to test this nearly as thoroughly as I'd like (that's also why this little cutie is flagged "Beta" in the modules directory..) https://github.com/t...erIPRestriction http://modules.proce...-iprestriction/ How to install Copy PageRenderIPRestriction folder to your /site/modules/, go to Admin > Modules, hit "Check for new modules" and install Page Render IP Restriction. That's it. How to use Default out-of-the-box settings don't introduce any restrictions. You can edit module settings (Admin > Modules > Page Render IP Restriction) to include those IPs you wish to allow access to your site for. Once you've filled in at least one IP address and saved module settings restriction will be immediately effective. Please note that if you fill in at least one IP address and check both "Restrict admin access" and "Restrict access for authenticated users" you will no longer be able to reach Admin without valid IP. Make sure that you've tested everything properly before turning those options on (and avoid turning them on at all unless you're 100% sure that you know what you're doing)

You're right, it doesn't

You've got one extra ")" near the end of that row, right before last PHP end tag. Try this instead: <meta type="robots" content="<?=($page->no_follow ? "nofollow" : "follow")?>,<?=$page->no_index ? "noindex" : "index"?>" />

I'm not sure why you're converting that date to Unix timestamp, but that's probably why this is failing. Try something along these lines instead: wire('db')->query("UPDATE pages SET created='2012-11-15' WHERE id={$page->id}"); The type of db field created is timestamp, which doesn't by default accept Unix timestamps (...) as it's value.

There seems to be a bug in ProcessPageType (dev branch) that affects at least user list: renderList() tries to render MarkupPagerNav with params $pages and $pagerOptions, which fails since $pagerOptions is by default null and MarkupPagerNav expects an array. Following changes seemed to fix this, at least in this case. Haven't had the chance to test further yet -- currently on a lecture, can't spend too much time debugging/testing.. - protected function renderList($selector = '', $pagerOptions = null) { + protected function renderList($selector = '', $pagerOptions = array()) { This came up while adding users to a site (26th user => page won't render.)

Couldn't agree more with Adam. If what the client wants is exactly what Joomla, WordPress or some other system already has to offer (very unlikely, but possible) that's fine by me -- honestly, I've absolutely no problem with that. Actually most of time it'd be waste of time and money (my time, their money) to reverse-engineer an existing solution. Not to mention that it's just no fun at all. One thing ProcessWire is very good at (and many other systems seriously lack) is flexibility. As a ProcessWire user you can freely discuss with a client what she really needs, throw in wild ideas and if you both agree that those ideas would benefit the client more than some existing plugin/module with tons of unnecessary features, bells and whistles you can just build it -- without any unnecessary hassle and with remarkable ease. This way you're actually selling solutions, not features. Of course with ProcessWire you can also be sure that whatever you build with it is most likely more secure, way more flexible and much easier to maintain than anything you could build with pretty much any other platform. And just for the record, this comes from someone with years of experience maintaining WordPress installations. ("Years of testing", yeah right -- more like "years of hastily fixing bugs by replacing them with new ones.") All that said there are probably situations where you should either consider going with another system or just ditch the case. Sometimes it's just not worth it.

Subdirectory shouldn't cause any problems, I've been forced to do this couple of times without any trouble. Regarding shared database you should take into account that ProcessWire tables cannot be prefixed, at least not without (lots of) very ugly hacks. I'd suggest that you first of all make sure that no other system wants to use same table names. On the other hand I'd also like to suggest that you at least consider getting separate databases for each system, unless that's absolutely impossible for some reason. Makes things easier, less error-prone and (most importantly) more secure. This subject has been discussed here in more detail.

@mindplay.dk: if I'm following your post correctly, you're saying that by default trailing slash should be added to pages which can (currently) have children and omitted from pages which (currently) can't? I do see where that's coming from, but I still have to disagree here, mostly based on the previously mentioned fact that those things (family settings etc.) can be changed quite easily while URLs changing is generally speaking a bad thing. What you're saying about files and folders is absolutely right; in this context files/folders act exactly as they would in, say, pretty much any UNIX style operating system. Thus /foo/bar/ would refer to folder /bar/ in another folder /foo/ and /foo/bar to a document called bar in folder /foo/. Up to this point we're probably seeing things exactly the same way. That's also where things get slightly more complicated: I prefer to think that each ProcessWire page really is in a (virtual) folder, so when you're accessing /foo/bar/ you're actually getting served default file in particular folder; in this case /foo/bar/index.* (suffix doesn't matter here.) There's nothing wrong with this, it's always consistent, very common and has been used for many, many years already all around the web. Even if that particular page had only one file and thus didn't really need to exist in a folder, this is still completely valid. If pages that can't currently have children had to be accessed as files instead of folders, strictly speaking that should also mean that same address with trailing space added should not work -- otherwise they would be folders and not files, and like you said that's a different beast altogether. Just give it a try in whatever OS you're currently running. Most likely if you create a folder /foo/ and try to access it as foo (without trailing slash) you're still redirected to correct folder, but if you're trying to edit / view a file called foo and add that trailing space you'll only end up with an error ("foo/: Not a directory" or something similar.) To sum this up current behavior is imho very much consistent with how the OS beneath your site actually behaves and that's another reason it should not be changed (unless you're actually suggesting that user accessing /foo/bar/ should only get 404 in case that admin has decided that bar can't have children, thus making it a file instead of a folder.) See where I'm going with this?

Sorry to bring an old topic back to life, but there's something I've been trying to make sense of lately regarding module naming: what should one call a module that is clearly related to other module, but still technically speaking very different from it? This problem seems to show up quite often especially with Process modules that require hooks etc. I'm currently working on something that is directly related to Process Page View and I'm having some trouble deciding whether to name it a) something completely different (Page-something perhaps?) or b) Process Page View [insert-specific-feature-here] even though it's not really a Process module itself. What do you folks think? Or am I just overthinking this? Also: I'm currently a bit worried when I look at the modules page of my test site and already see quite a few "module groups" with only one module in them; "Admin", "Comment", "Custom", "Lazy", "Schedule" and "Multisite" to name just a few. This isn't a big problem yet, but it does imho somewhat undermine whole module group concept. I don't have an answer on how to fix this, but I do feel that something needs to be done -- and preferably rather soon. Edit: for some reason what Ryan said up there ("Though I would suggest that when a module doesn't fit in the above, it should start with the class name of the core class or module it is hooking into (not unlike the 'Page' one above). So if you are adding hooks to the Pages class, then start your module with 'Pages'.") didn't really sink in before I had posted this. If I'm getting this right, it would mean that if my module adds hooks to Process Page View it should be named after that -- thus it's name would start with Process, even though it's not a Process module. Still doesn't sound quite right considering technical differences etc. but perhaps it's the right way.. Guess I'll have to think about this a bit more. (Also the worries I mentioned above about current module naming conventions, or lack of them, still seem valid.)

Agreed. Family settings are easy to change and if URLs are based on those (or actually any other variable that could potentially be altered later) you're going to end up with multiple URL variations for one page, which can't be a good thing no matter how you look at it. In my humble opinion it's much better to stick consistently with one than alter it based on each specific scenario. I also believe that (again for consistency) URLs without trailing slashes should always indicate files, though based on what @mindplay.dk said way up there ("it makes every page look like it's a folder - which the majority of pages are not") the whole concept of "file" in this environment might be slightly shady..

Looks really nice, nothing wrong with simplicity. By the way, was that "£2000" option in your contact form actually supposed to be "More than £2000"..? Also noticed that clicking the logo results in 404 error and link next to copyright goes to current page. Minor, but thought I'd still mention them.

... yeah, that's what you get for changing things while on mobile. Now it should be fixed

Thanks Antti - link fixed