Leaderboard

Cropping direction has been added to the latest commit on the dev branch. Example of usage: $image = $page->image->size(300, 200, array('cropping' => 'north')); // or you can use this shorter syntax $image = $page->image->size(300, 200, 'north'); That would make it crop towards the top of the image. Possible values for crop direction include: northwest, north, northeast, west, center, east, southwest, south, southeast or a blank string to disable. If you prefer, you can use short versions like 'nw' for northwest or 's' for south, etc. Crop direction can also be used with the width/height functions: $image = $page->image->width(300, 'north'); PW now supports this shorter syntax for crop direction, and also with quality and upscaling. If you specify a string for the last argument, it assumes you are specifying a crop direction. If you specify an integer, it assumes you mean a 'quality' setting. If you specify a boolean, it assumes you mean an 'upscaling' toggle on/off. If you need to combine multiple options then of course you should specify an array, as before. This behavior applies to the size(), width() and height() functions. If interested, more details are in the function comments. Thanks to interrobang for providing the implementation of crop directions.

Somebody help!!! Pete is being attacked by a furry animal!! :o

Hi, I use ProcessWire under NGiNX on both FreeBSD for production and Fedora for development. My security configuration is as follows: ### SECURITY - Protect crucial files location ~ /\. { deny all; } location ~ /(COPYRIGHT|LICENSE|README|htaccess)\.txt { deny all; } location ~ ^/site(-[^/]+)?/assets/(.*\.php|backups|cache|config|install|logs|sessions) { deny all; } location ~ ^/site(-[^/]+)?/install { deny all; } location ~ ^/(site(-[^/]+)?|wire)/(config(-dev)?|index\.config)\.php { deny all; } location ~ ^/((site(-[^/]+)?|wire)/modules|wire/core)/.*\.(inc|module|php|tpl) { deny all; } location ~ ^/(site(-[^/]+)?|wire)/templates(-admin)?/.*\.(inc|html?|php|tpl) { deny all; } I can share rewriting and php-fpm configuration also if required. Regards, Neil Darlow

I take the same approach as Soma, which is to use browser tabs when I need to keep tabs on more than one thing at a time (like the Page List while editing another page). Basically I'll be in the page tree, and CMD-click the 'edit' link, when I want to keep my current Page List handy. I think there are a lot of good and welcome ideas here, and I'd like to do anything I can to support implementation of them in other admin themes. For the default admin theme, I feel like I've got to keep it immediately understandable and infinitely scalable. It's got to be something that will accommodate any situation. I have no doubt that other implementations are possible that would have more appeal to some (especially power users), but it would be a compromise in some other respect. What I'm trying to avoid is a sidebar tree because that gets awkward when things grow. I've been turned off by the way that Silverstripe and MODx handle this. Likewise, I'm reluctant to introduce any kind of frames in the default admin theme (other than modals) or accept the overhead of executing PageList on every request. I do like what Diogo demonstrated about a sidebar that pops out only when you hover (or click) it, but only if it were a top (or bottom) bar instead that can span full width. But there's lots of baggage to consider. Example: if taking the frame route, adding a new page wouldn't be reflected in the PageList. If not taking the frame route, then PageList is getting executed on every request. There may be simple solutions to these that I'm not aware of, or there may be other issues to consider as well. If anyone is interested in working on an admin theme (or variation of one) that accomplishes any of what's been mentioned in this thread, then I'd be very interested and glad to help in any way I can. If there's anything that needs to be added to the core in order to support, I'll add it too.

Just recorded a video of a larger Site I've done some already know of (in this forum). Since a long time I wanted to share something, that maybe of use to others, so here it goes. It shows some technique I use often to give shortcuts to editors when editing content on the page. It's ideal to use for summary entries to give them a direct edit link, or for data pages that have no real view and are located somewhere else in the page tree. Basicly it's simple and just requires to add Fancybox js to the front-end, and you may already have it, or if now use another lightbox that has iframe capabilities. Also if there's not lightbox plugin you need in the site, just load them conditionally using $user->isLoggedin() check. Then generate simple edit buttons/link where you like, and add a "?id=1001" to the url PW admin edit url (/processwire/page/edit/). You can do this without fancybox modal as the default basic-install shows, but using fancybox can make the experience a lot better. To have the navigation of the admin not shown you just add a &modal=1 to the url. Code to generate the year link seen in the video is: if($user->isLoggedin()){ foreach($chart_years as $year){ if($year->editable()) { // if editable by user. echo "<a class='editpage-inline' href='http://" . $config->urls->httpHost . $config->urls->admin . "page/edit/?id=". $year->id ."&modal=1'>edit ".$year->title."</a> "; } } } Then in your JScript you would add fancybox functionality to the links like this. $('a.fancybox-iframe, a.editpage-inline').fancybox({ type: 'iframe', centeronscroll: true, autoScale: true, width: 900, height: '80%' }); Minimal effort, maximal effect.

Edit 2013-01-09: This module is deprecated - see the next gen version here: http://processwire.com/talk/topic/2515-module-aftersaveactions/ - - - After following the discussion on multiple save buttons and default action after page save I decided to give it a try. The result (or an early version of it to beat Soma ) is a module called PageEditRedirects. The module, inspired by this post in particular (and another module by adamkiss), adds four options to choose from when saving a page: stay in editor (default) go to the page list add a new sibling page view the edited page The options are always collapsed and the chosen option is saved into a cookie so that each user's preference will be remembered. Probably should add a checkbox "Remember this setting" (unchecked by default) so that a one-time use of another option doesn't get sticky. Module can be downloaded from https://github.com/n...geEditRedirects and wont be available from the modules directory just yet (because of the required PW 2.3). So, consider the module just an alpha version or a proof of concept as it hasn't been tested nearly at all (need to check it doesn't break Antti's Adminbar for example). Edits: * Added link to an early post on the subject. * Added a little more explanation on what the module does and doesn't do. * Removed the note on needed core changes (Ryan did those already).

Welcome to the forum ohthanks! I recommend using pages instead. Maybe something like this: product-page - table-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - table-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - table-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) - row-page (data-template) fields in the template: - data1 - data2 - data3 - data4 In the table-page (parent) it is used for the headers. The row-page (child) it is used for data. The template doesn't need a file, only used for storing data. Only populated fields in the table-page (parent), filled with header names are used for the table headers Now you know wich fields to use from the child pages. Each child page is a row in your html table. --- For large amount of data, you can use the import CSV to pages module. ---- I like to use the MarkupAdminDataTable. look in: /wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.module it's straight forward & not that difficult to understand. here some sort of example: $table = $this->modules->get("MarkupAdminDataTable"); $table->setEncodeEntities(false); $table->setSortable(true); $table->headerRow(array('name', 'of', 'header', 'items')); foreach($table as $row) { $table->row(array($row->data1, $row->data2, $row->data3, $row->data4)); } echo $table->render();

Chrome Php Logger Module to log useful details directly in your Chrome JS console. You can inspect most as objects and see infos or values. To enable logging with this module you have to enable debug modue in config.php. If debug is set to false in config.php, it will not output any log. Important: It is not recommended to enable it on live stage, as it reveal infos you might not want everybody to see, although it's not obvious as it requires the ChromePhp Extension installed and enabled. - render time - memory consumption - cpu usage - current user infos - current user roles - current user permissions - current page with all its fields and their value and field settings - page cache/loaded on request count - fuel - modules loaded - Server vars etc. - Cookies - Requests - mySQL query log When installed you can also use ChromePhp static methods to output your own data in all your templates or modules: ChromePhp::log($page->somefield); Note: This module requires the ChromePhp Extension installed to see the log in the Javascript console. More infos can be found on http://chromephp.com Download: Modules Directory: http://modules.processwire.com/modules/chrome-php-logger/ Github: https://github.com/s...ChromePhpLogger

I have just finished the first draft of a new tutorial on the wiki. http://wiki.processwire.com/index.php/Basic_Website_Tutorial I know it needs tightening a bit and possibly some more screenshots, but my main concern at this stage is whether it works technically; in other words, if someone follows it, will they actually end up with the finished site? The aim of this tutorial is to go further than the Planets small project walk through. It starts post installation by cleaning a few things out, adding a couple of modules and so on. It then creates a site structure from scratch, creates a site settings system (site title, banner, meta keywords and so on) and populates the new site structure with the results. Finally, it creates a new article template with new fields and adds the page. The idea was that I could cover in basic detail: How Template Files relate to Templates Creating various field types (including images) Getting information from the current page and another page (using $page and $pages) Talking about a few other concepts like how information is stored Demonstrating the power of not having a templating system by default And lots of other bits and pieces. This tutorial produces a demo site that is ready to accept other tutorials - slideshow, news system, etc - without having to start from scratch again. The site design does not use a framework, and is simple and clean but familiar - could be the basis for many site types. Anyway, initially I am just looking for comments on the technical side. So, if anyone has time, can they try it and see if they actually end up with a site, or have I forgotten anything? Bearing in mind that I am very new to PW, I could easily have got things wrong somewhere. Once I am happy that it actually works and that I haven't said anything in it that is technically wrong, then I will go through the writing with a fine tooth comb. Thanks in advance to any guinea pigs out there! Joss

Ok the while is over. I just committed an update to 1.1.5 to support alternative markup for specified templates. https://github.com/s...default-options Added 3 new options: "xtemplate" => "folder|placeholder", // specify one or more templates "xitem_tpl" => "<span>{title}</span>", // default markup for page with this template "xitem_current_tpl" => "<span>{title}</span>" echo $nav->render(array( 'max_levels'=>2, 'selector'=>"limit=10", 'xtemplates' => 'placeholder|folder' ));

Luis, I am very impressed!

Quick and dirty? There you go with a simple module, but maybe not the real and best way as if it could be implemented with a dedicated page custon fieldtype. I thought about having a module that hooks after Page::save and reads two page fields, each is setup to select the template the other lives in. Template: user -> Page field: teams_select Template: team -> Page field: users_select teams_select can select user template page and vise versa. So now you'll need to check on every save those two templates and fields and remap them. This requires to go through all pages and make changes. This is like many to many but with not mapping table. Maybe I don't see anything obvious. But I think if you not go crazy with amount of pages, it should work well. Example code in the Page::save after hook: Removed previous code. Added gist snippet: https://gist.github.com/4335296 Not tested, but it should works. Maybe not the best but you know it.

Actually, that works even for the developers, who by the time they have finished the site have completely forgotten the bit they did at the beginning ... Most sites are never going to be so complex, but some will, and being able to guide a user through a search/browse process in such a way as it speeds them right up will benefit both the untechy user and the dev who is lost in their own genius creation... Talking of which: Soma, I have a module idea for you that sort of relates to this: Basically, It is the ability to create a drop down on the admin bar to which you can add links to the "new" link of parent pages. So, if you have a page which is the parent of your news articles, a link to its "new" link can be made and named "News Article." So, rather than scroll through your ever growing list of pages, you can just hit the button. Possibly an addition to the template - a check box or something that adds it to the menu? Sorry, haven't thought this out fully. Joss

It's reduced Martijn to incomprehensible sentences!

Looks amazing Luis, I'm really impressed with this.

Just as a general thought about UIs generally (rather than this one in particular) there seems to be a problem with them being what I would call enterprise ready. Basically, doing things like cross linking between articles where you may have thousands of them, or digging out an images that was on a page several hundred back, or just searching for information from one page to copy into another. I am not totally sure what the solution is that addresses that issue and is also neat and easy for the site with just 20 pages in it. One thing I do know is that clients hate it when they get confronted with a search - great, if you know exactly what you are looking for, not so hot if you can only just remember .... (not that I am old or anything.) These are problems that have plagued just about every system I have worked with, with the possible exception of a couple of Crays .... Joss

For sure I can, mighty Pete!

For your beginning/ending matches, you might also try using the %^= and %$= operators. They are the same as ^= and $= except that they bypass the fulltext index and the limitations (and benefits) that go along with that.

Soma - off the top of my head you wouldn't want to do it with JS as you might only want particular drop downs to be non-click on the parent (confusing for the end-user I know, but I've seen it before!). I know it's not exactly best practise to mix and match what can and can't be clicked at the top-level of drop-downs, but people will want to be able to do it nontheless I guess one way to achieve this would be to add another field by default that's a simple tick-box that says something like "Simple Navigation Placeholder" or something that can appear on every page template by default, maybe in the Settings tab? That way it's a simple check for a tick in that box per-page when looping through the output. If not, and we assume that there is just a module setting to make all top-level drop-downs be non-click then that could just be a simple check for that setting in the module config and loop through. I've just realised what you mean with the JS as I'm typing this (d'oh) but I was still envisaging that behind the scenes Google could still see a URL to the top-level even if you're telling the browser for the end-user not to be able to click a top-level menu item, so I just wanted to suggest a few options you've likely already considered

In Finland most people pay with their online bank, each of them have little bit different payments gateways so it usually took something like 4-8 different gateways for each online shop. And that was the easy and cheap part: merchant also needed to open account on each banks and create agreements for online payments with each bank. Paypal is not that popular and neither is credit cards. But, few years ago payment integrators started popping and it has been much nicer to implement these. One agreement, all the banks + credit cards and more exotic payment methods. This is what most seem to use nowadays here in Finland: http://suomenverkkomaksut.fi/ (their name means something like: "Webpayments Finland") and it is the only payment method I have implemented for the shop so far: https://github.com/apeisa/PaymentSuomenVerkkomaksut I have also implemented PaymentExample to show how to create payment methods in PW shop: https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentExample.module and this most simplest "invoice" payment method: https://github.com/apeisa/Shop-for-ProcessWire/blob/master/PaymentInvoice.module Those are good ones to take a look if you are planning to implement payment methods.

hmm. Tried it, doesn't solve the problem though. hmm N°2. Might have actually solved the problem. I had to reset Safari and now it works… Go figure. Thanks Soma.

Hello, Apeisa: thanks for your valuable input and contributions. I've looked at the module you created and it seems like a terrific solution -- all ProcessWire! Now that I have compared using your module side-by-side with the PW/FoxyCart arrangement, I think that with a bit more your module gets the vote. Going the FoxyCart route, we are using native PW and hooking out for payments. With your module, we can do more inside PW, but still go out for payment gateways. This is the only remaining hurdle. How are you handling gateways now in your live shop? Thanks. Matthew

Welcome DV-JF Don't worry, you're not alone What are you using to make the menu hovers/dropdown? Bootstrap? 1. No, there no option to have placeholders. 2. You could do that with JScript (prevent click etc) I'm playing with implementing some placeholder template option. Still have to figure out the details. But since I don't really need it and am cautious to not add too many options, this could take a while.

http://ace.ajax.org/#nav=production We're on the fourth line

Okay, I have been playing with MediaWiki:Common.css - fun! I have increased the font size from 0.8em to 0.85em I have added a bit more line height to h2, h3, h4 and h5 I have added more bottom margin to P I have indented UL a little more I have added a drop shadow to the TOC, images and my side bar template. (you can override it on images by wrapping them in <span class="nostyle></span>) I have put a dotted line round the code and added a bit more background colour. So, hopefully it should be a bit more readable now! Time for lunch. Joss

HI ziusurda When you are looking through the Database itself, one thing worth noting is because each field you create in the Admin (Setup > Fields) has its own table, the data stored is very clean. This makes it very easy to deal with in your Template File in the /site/templates/ directory of your installation. Any stylisation is up to you. It is also worth noting that the DB structure allows every field to be reusable. They are not permanently associated to one particular template, but can be associated with many. So, you may create an article_meta_keywords field that you want to use in lots of different templates since it is a very common element. When you create a template in the backend, you can add whatever fields you like from the drop down list, so this is not only possible, but very useful! I have just written a full tutorial that explains some of these issues. It sounds like you may not need to do the entire thing, but reading it through might put some of this into context. http://wiki.processwire.com/index.php/Basic_Website_Tutorial I am still cleaning it up, but a lot of the info is there! Please let me know if there is anything in it you find confusing - I will sort it out. Joss

Joss, just think of the template as a single thing that groups all those. Then you just have to refer to them like "the template file", "the template fields", "the template settings".

Hi Joss, First of all, I think your tutorial is fantastic. It really provides an excellent overview of ProcessWire and helps people unfamiliar with the system get acquainted with it very quickly. I also think it is well written, fun and easy to follow. So, answering your question, I've gone through the whole tutorial, following every step, and I successfully ended up with the website I was supposed to get. I didn't find any problems at any stage of the process. I've also decided to upload the demo to my server so that you can see the result I got. Here's the demo: edit: link removed I hope that helps. Claudio

Just pushed an update. update to version 0.0.3, some improvements and refactoring - Improved a lot on some page/user fields parsing to give better and deeper results with page fields and file fields. Also shows now fields that are empty and writes "null" in the log. - Fixed issue with some in admin request getting logged still. I can image something with getrusage() on your hosting having a problem? Not sure though what else.

Part 3: The Client and Invoice Management. Not finished at all but handling the data is almost ready. https://youtu.be/d6lWyfk53mg

Hi soma, thank you Yes, I´ve implemented the following: http://datatables.net/blog/Twitter_Bootstrap And you are right, lots of work But the main part is already finished, as I mentioned in previously posts, I started to develop the app in PHP/MySQL., think round about 6 months ago before I discovered PW. I´m now just porting it to PW. So no more needs to think about the core functionality. Once i´ve finished I benefit from a deep insight into PW and know what could be done with PW. Well at this moment I don´t really know what couldn´t be done with PW

Not even one year ago there weren't any repeaters in PW. And still, we were all happy

Welcome to the forums ziusurda! You don't really need to look on the database to work with PW, everything you need is in the administration area. There's where you create your templates fields and pages. To output the content on your website you also need the templates files. But since you are curious about the database: All the pages are on the table "pages" and only keep info like "id" "name" "template" (foreign key with id of template), etc. The page table doesn't hold any fields, because each field has a table of his own, and each row holds the value and points to a page. edit: wow, you were quick onjegolders!

To give you more of an example, you create fields for everything in Processwire so you may create a template "event" For your events, you want to create A date A venue A category Multiple images Files To do this, you would first create the fields, selecting the type of field needed (there is much more information available in the docs) then you go to your chosen template and assign the fields to that particular template. Say that you have a date field called event_date. You could output that in your template using $page->event_date You will use the $page variable whenever you are accessing data from the page you are currently on. If you need to get a field from another page, you would use the $pages variable.

Hi Ziusurda, You need to setup your templates and fields in the admin section of your website and then use the API to output your content in your templates. Take a very simple example: You create a template called "basic.php" <!-- Basic template--> <h1><?php echo $page->title; ?></h1> <h6>Created by: <?php echo $user->name; ?></h6> <div class="body_copy"> <?php echo $page->body; ?> </div> Then in the admin, go to Setup->Templates and click Add, basic.php will show up, you can then assign fields to this template (you can add new fields at Setup->Fields) Then create a page on the page tree and give it the template "basic". Now fill in the title and the body. If you go to your website and view the page you created you ought to see the content you have outputted. This is of course a very basic example. The API is very powerful and will enable you to output almost any content in almost any way you like.

Oh crazy, I will look into the admin data table more now. I would have never thought about doing it that way. I think after coming from EE matrix setups for so long I just try and use repeaters to solve everything. Thanks for the insight. You guys are great.

// output the 5 authors with the most posts sorted by post count $authors = $pages->find("template=author,posts.count>0")->sort("-posts.count")->find("limit=5"); foreach($authors as $a){ echo "<p>$a->url $a->title ({$a->selec_page_image->count()})</p>"; } This seems to work, but only if you make the sort and limit after the find. I'm not sure what exactly happens, but if you put sort inside first find it will throw error, now it works if added afterwards. The last find is to limit it to 5. Note limiting has to be after the sort, otherwise you get a mixed result obviously.

It seems that "$=ie/die" issue has to do with several things. Buggish behaviour, I'd say. I'll try to explain some of the things that are happening with operators ^=, $= and *= inside the core and database as well. MySQL fulltext searches are able to match either whole words or word beginnings - so no way to match a word ending with a fulltext search only. PW tries to anchor search term to the beginning/end of the field value by adding a RLIKE with some regex magic. While this works nicely in the beginning on the value, it quite often fails when matching end part. Actually, when it doesn't fail, is only when searching for complete words (the very meaning in the first place I suppose) OR the search term is a predefined stopword. Yes, this does sound a bit backwards, but that's how it's implemented at the moment. Stopwords ("ie" being one!) are filtered out by PW, thus leaving only that RLIKE - which matches on its own (this is why $=ie matches "Élodie"). Additionally PW forces the search term to exists (by adding a '+' operator to the beginning) and tries to find partial matches (by adding a '*' operator to the end). This is problematic because the wildcard operator only matches word beginnings and that will never happen for a word ending shorter than the whole word (this is why $=die does not match "Élodie"). And as MySQL doesn't include short words in the fulltext index at all, there's no way those searches will ever match even a whole word if it's short enough (using "^=Le" doesn't match "Le p'tit"). Well, I guess here's enough explanation for Ryan to get a hold of this when he has time. Hope I got all of the above right... But as I said before, when using fulltext searches, it's all about whole words (mostly at least). And words long enough. And not in the stopword list.

Yes, DaveP has the right of it. Apart from being courteous and helpful by replacing the content with "This content is no longer available, however, you may be interested in these related articles ..." or something along those line, you can also leverage the visitor who, after all, has landed at your site. You should do something with them! This is good marketing practice dating back long before the internet. When readers would write to Magazines or Publishers asking for an old article that was no longer available, the standard practice was to send them an apology and enclose a recent copy of the magazine as a consolation. One new reader and satisfied customer. This response felt personal and direct - it felt much more than some automated reply (even if, in reality it was not far off being automated for the day). Modern internet publishing has huge amounts to learn from the print publishing industry. Joss

I recall reading (can't remember where, sadly) that the best way to deal with this in SEO terms is to leave the page published, but change the content after the event has happened - ie explain on the page that the event was in the past and include a short report on how it went. The reasoning behind this is that a page about a popular event can generate incoming links (traditional links or social mentions) in a short time, so there's no point wasting them. You can also add a comments box on the page and ask attendees how the event went, generating a bit of UGC as well. You can also link to upcoming similar events and pass a bit of Googlejuice on.

still developing but here is a little preview of the accounting and the system settings module. sorry for the bad quality, first time screenrecording on the mac. the videos show the actual frontend, every data is generated from there. my aim is to use the backend from PW as a maintenance system. in the settings module video you could see me creating "mitarbeiter" (employees) , they are created as $user, so every employee got his own login data and you could assign the supposed role according to what he is allowed to do and see in the system. enough words. Part 1: the settings module https://youtu.be/dMhri_H3UXY Part 2: the account module https://youtu.be/sds9kNcFp7s

JJS, I think what others are trying to say is that you can't take the code from Wordpress plugins and easily integrate it into PW. If you want to use PW then you need to use PW framework and forget about Wordpress. Wordpress' PHP does not work with PW. They are two completely different systems. There are some PW modules created by the community that will work with what you are desiring, like putting the site into maintenance mode or language translations or tagging. But for other features, like a members only section, you are going to have to dig into the forums and learn how others have implemented into their sites. Just ask very specific questions and you will get the answers. Break your project down into what you need and ask away!

I think there are a few things to bear in mind here: You will need to know a fair amount of PHP to proceed. No CMS will allow you to simply port functions from another CMS by replacing X with Y - the functions will usually interact differently with the core code. A clumsy example is that it's essentially like taking wheels from a quad bike and trying to attach it to a monster truck - yes they're both wheels but they are incompatible and there will be a lot of effort involved in making them work together. It may well be easier to add your required functionality to the shopping cart module diogo mentioned: http://modules.processwire.com/modules/shopping-cart/ - again though you will need to look at that source code and be able to code PHP to continue If you're happy coding PHP, there are several topics to help you on your way to understanding ProcessWire modules Firstly, read up on the documentation on the site - you will need an understanding of how the system works first: http://processwire.com/api/ Next there is some useful information on creating modules here: http://wiki.processwire.com/index.php/Module_Creation and here: Finally, the cheatsheet is handy to have to hand: http://processwire.com/api/cheatsheet/ Let us know how you get on.

Hi Teppo, Thanks for all suggestions! Anyway this attribute: $template_obj->filename Returns me an absolute path, that's why i must do a string replace In the next few days nights i will complete the basic functionalities ! USSliberty

Updatery I just pushed v 1.0.3. to the master to https://github.com/s...nic/ColorPicker added support for default value added reset link to set back to default color some cleanup and added readme finally updated first post

Can you try with 33% 34% 33%? That's what I use and haven't had an issue

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!

I'm not sure. It's strange indeed. I tested a little and it seems if the user is "guest" (not logged in) it fails to get the persmission check, but ONLY if checked in the hook function. In the init function the check works. Could be a bug. However I recommend to do a $user->isLoggedin() check to see if user is logged in at all first, and also user $page->editable(); to determine if user has edit right on the requested page. Also my suggestion is to use the logged in check in the init, so the hook doesn't get executed on guest users int he first place. Right now this hook is executed on every request. So it would look like this: ... public function init() { if($this->user->isLoggedin()){ $this->addHookAfter('Page::loaded', $this, 'changeView'); } } public function changeView($event){ $page = $event->object; if("admin" == $page->template) return; if(!$page->editable()) return; $view = $this->input->get->view; ...

Hey nice start! Thanks for posting. I see where you're going with this, and maybe it can be of use for people. Some feedback: You extend class "Process" here, and I'm not sure that's the right one in this case. Process modules are meant for admin pages that are associated with a page in the admin like the page tree or editor. You assign it to it if you create a new page with the template "admin". The execute method is then the default process that's called when you look at the admin page you created. Process modules are usually also not autoloaded because of that reason. I know it works, but it's not meant to be used for hooks and such, as far as I know. Not sure this is intended but maybe it makes sense for some other module you will want to create in correlation to this. So you'd extend Wire or WireData. See the wiki artikel by Ryan about modules, that will tell you a lot! http://wiki.processwire.com/index.php/Module_Creation I'm not sure but I thought you'd have to use addHookAfter to make it work, not sure what addHook really does... not sure on that one atm. Some syntax you used is a bit strange and to make it short ("fuel") isn't official, and kinda old. It still appears in the core and modules and is a relict. The right and simple way to use API in modules is using $this->pages or wire("pages"). As for the module, I copied and cleaned it up a bit (removed comments for better overview), that will maybe help you out some to see how someone experience would do it. You see some that could help not executing the hook at all if you do some checks in the init() already. You can already check if a GET var is set or permission are correct. That's all for now, I'll let you figure the rest <?php class Views extends Wire implements Module{ public static function getModuleInfo() { return array( 'title' => 'Views', 'version' => 90, 'summary' => 'Add the selection of the view of a specific page', 'href' => '', 'singular' => true, 'autoload' => true, ); } public function init() { if(!$this->user->hasPermission('page-edit')) return; //if($this->input->get->view){ $this->addHookAfter('Page::loaded', $this, 'changeView'); //} } public function changeView($event){ $page = $event->object; if("admin" == $page->template) return; $view = $this->input->get->view; $view = $view ? $this->sanitizer->name($view) : $page->view; if($view): $tname = $page->template->name; $page->template->filename = str_replace($tname, $view . "-" . $tname, $page->template->filename); endif; } }

Thanks to you too Soma, and Diogo and Apeisa and all the other people who make this such a welcoming place for newcomers and help out when we inevitably get stuck. I agree that Ryan sets the tone, he's unfailingly helpful and polite and a bonafide genius at just about any web issue I've ever come across! I do wonder, like a few others, how this place will evolve when it grows, will we still be able to maintain the same "intimate" feeling? (Joss I need your help here with the wording!) I agree with Pete that there will probably need to be moderators for different forums. I love this community! PS: I also think the timing of Soma's post is spot on. It does feel like PW is growing by the day.