Leaderboard

In some previous posts, I demonstrated a simple proof-of-concept CRUD “application” for PW using jTable. I really wanted to use DataTables since it is older, wiser and with a huge fan base. One thing I wanted was for the CRUD system to be as simple as possible and possibly be Excel-like (more below). With DataTables plugins, you can perform stuff like inline-editing and Auto-fill. The latter works just like in Excel and allows you to quickly populate cells (quick copy). But that’s as far as it goes. Google led me to other Table management systems. Some of the front runners include jqGrid and SlickGrid. SlickGrid is nice and using virtual rendering can display millions of rows with ease. Its support for displaying data delivered on demand (Ajax/server) is minimal; it requires you to download all your data before it starts manipulating it. Someone has created an Excel-like extension for it allowing copy-pasting between SlickGrid and Excel. Awesome! But, it still didn't rock my boat completely, especially the Ajax content issue. Then I stumbled upon Handsontable, a new kid on the block that describes itself as “a minimalistic Excel-like data grid editor for HTML, JavaScript & jQuery”. Though relatively new, it is as Excel-like as you can get. You can copy-paste from/to Excel [single to multiple cells and multiple to multiple cells], use the usual shortcuts (Ctrl-A, Ctrl-X, Ctrl-C, Ctrl-V, Ctrl-Y, Ctrl-Z - i.e., undo/redo, etc., and tab navigation, etc.), use Auto-fill (vertically and horizontally), freeze cells/columns, make cells/columns read only, Right-click context menus, insert/delete rows and columns, perform inline-editing, etc. Double awesome! Handsontable (HoT) is minimalistic but comes with a rich API. However, most of the implementation is down to you (sounds familiar?). It will render the Table and provide you with Methods/Events/Options to manipulate it. You just have to provide the data as an Array or JSON defining your columns and containing your data. Soma has a DataTable module that is currently read only; you cannot edit the displayed data directly in the table. It is also in lazy development . So, I started toying with the idea of using HoT as an Excel-like CRUD system (module) for PW. I wanted something that could quickly and easily do mass editing (Batcher-like). Imagine quickly creating basic pages/records by copy-pasting from Excel. Or quickly changing records by dragging (Auto-fill) or pasting new values over old ones. Well, the result can be seen in the screencast below. I’d like to hear your thoughts whether this is something that I should consider developing into a module; something that could be used by Superusers. Depending on implementation, it could be used by other users as well. All HoT needs is data. What you do with that data is up to you (the developer) and your code! This can be very dangerous if not implemented correctly, of course! You could easily delete important records! However, HoT does not touch your database! Deletions, insertions, etc., will not alter your database unless you specifically write the PHP code to do that. All it does is send data to the server via a method your specify (post, get, Ajax, etc.), and even that is your implementation. You do not need to implement deletions or additions. You can use it for updating content only or as read only, but where’s the fun in that ? In the screencast , apart from the table itself, all the other implementations are custom - the buttons, selects, auto-save (can be tricky? can DDOS your server?). The current implementation is not perfect; it is a demo after all. Certain stuff would need to be implemented differently . I didn't want to spend too much time on something that would not be useful in the end. All CRUD operations are via PW API and/or vanilla PHP. Deleted pages are Trashed and not permanently deleted. If there is interest for a module of this kind, I would request all the help I can get to develop it please. I would put it up on Github of course. In the demo, this is running off Diogo’s ACP module. Let me hear your thoughts please. Should a module like this see the light of day? Thanks Wasn't sure in which forum to post this...

My first PW project – the new responsive site for the Yavuz Sultan Selim Moschee in Mannheim. Two languages (still using LanguageLocalizedURL module to date), sticky menue, gallery with swipe gestures (photoswipe). Forms for a tour request and prayer times parsed via snippet.inc in a template. Thx for the essential help of the community – without them I couldn't have done it. It was more fun in PW than it was in modX which was my former beloved CMS... the flexibility which PW gives even to a non-coder is fantastic.

Just today I relaunched http://barefigur.es/ It’s now powered by ProcessWire. A bit of history: I launched Bare Figures in January 2012. Originally it’s a site for visualizing Apple’s quarterly results. Charts are being rendered by Highcharts JS. In the first few months after the original release I did all manually (actually also creating the JSON file by hand). After that I used a bare-bones SQL database for inputting the data and a PHP script generated the JSON file to feed Highcharts. Now Bare Figures is powered by ProcessWire (and it feels just absolutely right, I love it). I created a module that generates the JSON files and now the site is, of course, also scalable, which means I can add more companies to the site (the first one besides Apple is Google). I plan to add many more in the future. What do you think?

Unless something has changed since then, it would appear that this can't be changed that easily. See this thread for a possible solution and Ryan's explanation.

For a number of decades, there was over 50% vehicle ownership of Ford automobiles. Were they the best? Nope, heck no, not by a long shot. Things changed at some point, and Chevy, Chrysler, AMG, and many others sprouted greater/better ideas. Muscle cars were born. Economy cars took reign. I'm not impressed with which sales are the highest, which has a higher user base, or which is wanted more *cough*iApple*cough*WordPress*cough* I am impressed when the underdog brings to the light the customization, the ingenuity, the talent, the speed ... that's impressive.

Words of encouragement from the Pub's amateur psychiatrist (Read best in a soft spoken, German accent) Ah, you are here because you have been reading things in this forum about pages that have left you confused, disorientated, befuddled. You thought you knew what a page was - you have been thumbing through them, folding them, studying them, wrapping things up in them and scrolling up and down them for most of your life! A page is this solid item - this great lump of data stuffed with things. But now you have come to Processwire, and everything you thought was true, simply isn't any more. For in Processwire pages are completely different - they are not great gulps of information, but tiny little things, nothing more than a link to the more interesting world of fields and templates; just a little blip of data in your huge fascinating database. Pages in Processwire are used for all kinds of things. They can be used as a marker in your pages list. They can be used as a group parent for other pages. They can be used as categories, tags or lists or users. And they can even be used for simple drop-down selects - just to supply a label and value. It can seem crazy to use such an iconic thing like a page for such a mundane and trivial task! But don't worry and fret, don't lose sleep or pace the floor as you think the reputation of the noble page is being crushed! In Processwire, they are fulfilling their duty to the full - and the more slight the task, the more they bound up to the wall and jump up and down shouting "use me, use me!" And, as a bonus, they can even be used for content - for all that stuff you thought was a page, but in Processwire isn't! So, don't be put off by the Processwire page - use it for everything! it is much smaller than you think, takes up hardly any space at all, is well behaved and only will do its thing when it is called. In fact it is hardly a page at all .... and then again, it is also so much more!! Better now? Joss Freud

Feature Request ;-) It would really handy if the Batcher url under Setup was resource-oriented and stored the submitted Selector in the URL. That way you could bookmark the selectors that you reuse most often, or share very specific lists of content to team members etc simply by sharing a URL. -Brent

I was just about to ask you about that. AFAIK, in PW parent IS NOT same as grandparent. For grandparent you can use has_parent property (http://processwire.com/api/selectors/). Currently, you can only specify one value for each declaration of has_parent in your selector, so you can do has_parent=5, has_parent=15 BUT CANNOT do has_parent=1|87|90. I think there is another approach to querying grandparent ancestry relationships as well; I can't recall it atm. Exclude a whole tree or a whole branch? Yes, you can do both...using ancestry and/or template association...

Nowadays I care about not working with clients who don't trust my judgement with the tools I use. The last time I did any Wordpress development it was so painful to get something that should have worked working (yet another case of trying to make a plugin go that little bit further where PW wouldn't have needed a plugin/module) that it took almost 2 days to accomplish something that should have taken 2 hours. @pwired - yes, I would definitely say - if asked by a client - it is far simpler to pick up ProcessWire than any other CMS from a developer point of view. I've been asked it before. There are all the other pros and cons though - how many ProcessWire security updates have there been? I don't think I even need to have fingers to count them Other systems on the other hand... many patches and all too often for my liking. I think it's a case of weighing it all up. Of course, if you need the work and can't turn it down then don't, but if you think you can pass a job up and wait a bit longer for one you can do in ProcessWire we all know that a lot of the time you'll complete that PW site in a fraction of the time and be able to move onto the next job quicker. I used to work for a web dev company. Usually they have small teams and welcome the input, so back when I used MODx it didn't take a lot of convincing to have new websites build using MODx. If you're working for a decent web dev company, they will be interested in your experience and interested in looking at what tools you recommend - it's not just the single (as in team, not dating ) devs who are always looking for better tools. This will be the case for the majority of clients. Larger clients will be more likely to ask, but they will also more likely be interested in whatever is the best tool to get the job done most efficiently. I think for clients who are interested, you have to seel the CMS/CMF as the tool that is best for the job, the one that is going to get it done quickest, and the one that won't tie them down in terms of features if they suddenly decide they want to add some new, complicated part to the site at the drop of a hat in the future. PW is good in terms of the unknown future requests purely because, in my experience, it's not a case of if you can do it in PW, but rather how you're going to do it - the question of "if" doesn't exist for many scenarios I've come across @Macrura - yep, if you're happy with it then that's fine. Like I say, for some sites I've worked on it's time, money and the fact that it still works the way it is. @Zahari - I like the "live long and prosper" philosophy. I don't think anyone here has come straight to ProcessWire without having used any other CMS, and without the others there would be a stifling of creativity I think. You can't have just one CMS - it's the reason there have been massive improvements in the discussion forum scene in recent years: competition breeds creativity.

Maybe to tiny to post here, but may become handy for someone. It simply removes label, padding & border from all fieldsets. Nothing more. Just give some precious space back. FieldsetShrink on github

I believe these types of articles only serve as a distraction. They are popular and get a lot of press. Even if Wordpress had 99% of the webpages it doesn't make it a better product than ProcessWire. I have used Wordpress and Joomla for customer sites, in the past. They were a tool that got the job done, then, because I wasn't aware/knowledgeable of better tools. Since, I have discovered ProcessWire, I now know that those tools aren't appropriate for seriously developing websites or web applications. They have great strengths but also many technical weaknesses. Anyone who seriously compares Wordpress, Joomla or Drupal to ProcessWire and then states that technically those 3 are better, is not dealing with reality. I could spend the next year learning about all the remarkable things you can do with ProcessWire. I now believe the only limitation is your imagination.

The PageArray part is called "type hinting" in PHP. It is the developers way of telling PHP that it should throw an error if it's given something other than a PageArray. That way the developer doesn't have to write extra code in the function to make sure it's been dealing with the right type of info passed to it before attempting to use it. For the consumers of the function (you and me), it's also useful just purely for readability and knowing what it expects you to give it. It's also nice to know that you'll get a consistent error immediately if you give a function the wrong info. Like if you passed in a Page rather than PageArray, you'd know right away, rather than trying to figure out for some time why the function isn't working. If we had a function that we wanted to accept multiple types, like say arrays, strings and ints, then of course we would not want to type hint like that. We would probably just have myfunction($something) instead.

Hm, yeah, just making the tab is dead easy. I just made a new page under the hidden "Admin" page, published it, and I had a new tab. But it is asking for a process to associate with. So what I would recommend next is reading Soma's post, here: http://processwire.com/talk/topic/1272-new-page-nav-in-admin/#entry11276

Love it I was about to say that it wouldn't work for my idea in the other thread where I was talking about using something like this for repeater fields, but then I just saw the cell types on offer here and my jaw hit the flaw: http://handsontable.com/demo/renderers.html What impresses me with the cell types is that the config data for select fields, checkboxes, datepickers and autocompletes etc can be read straight from your field's config data in PW so there is almost certainly a way of making that happen if I ever find the time. So many possibilities here, and I love what you've done so far!

The only question i see in the OP is "Anybody using WP next or besides PW ?" To which the obvious answer is: Doh, a lot. As for the rest of the links and propaganda i cba, too many flaws and smells of propaganda. BTW, According to my own studies PW now owns 23,67 procent of the interwebs, so eat that Wordpress (no h8 toward TS)

Cool, I'm going to mark this as solved because it seems like it's just a matter of selectors/ingenuity at this point. Thank you for the investigative help! Edit: In fact, has_parent!=1057 works for all grandchildren! Both the superuser & the client gets the restriction. The only weirdness that remains is that the superuser also sees all the little admin cluttery pages, but that's not a big deal for me because the client's list is clean.

I also ran into this issue and, in case someone else does too, it might be worth pointing out once again that this is not the value to change. At the end of the php.ini-file (that you find under the wamp-icon in the task-bar and then by in the menu picking PHP - php.ini) you have the xdebug lines. Just add the line... xdebug.max_nesting_level = 200 ...directly under the [xdebug]-line. After that, things should run smoothly.

Think it will a great way to batch & import. Great work so far.

Hello kongondo. I don't like it, I just LOVE it.

That's why I would avoid working directly with the db tables. The db structure was built to maximize the power of the API, and this is PW's big strength. You can accomplish virtually everything with the API in a very cool and easy way If you forget the db and focus on the tree.

Hi kongondo, This is awesome! I would love to see a filter for the table that would accept a standard PW Selector rather than just a drop down for Templates. That would allow you to combine multiple templates in a result set, or get as granular as you need in terms of searching large data sets. Great work!

Looking great! Nice subtle "Arabic" looking background too. Care to share how you get the Gebetszeiten/Prayer Times? You use an API?

Problem with deleting all a user's posts & replies is that can break up the conversation flow. Better to leave posts & replies and to mark them as by 'Deleted User'? (Or maybe change username to user id - i.e. anonymise posts, but leave them in place.)

Just to give you an idea of the huge task that you are looking for, not even these forums were done with Processwire. But besides behing a CMS, PW is also an excellent framework suitable for building anything that you would build on another framework. Including a forum. As for your question: You could build a module that hooks on page delete, checks if the page is a user (if template is "user" would be enough), and looks for all the pages (posts would likely be pages in PW) that were created by that user to delete them. You could also simply delete the pages by the user by his request. Considering that it would be the user deleting himself, just look for his pages and delete them before deleting the user: foreach($pages->find("createdUser=$user") as $p) { $p->delete(); } If you are aware of the amount of small tasks you will have to code to create the forum, this gives you an idea of how easy is to solve them with PW.

I have to say the last time I tried to work with WP, I just couldn't believe how hard it was to find a custom fields plugin, figure it out, get it to work then sigh when it inevitably doesn't work as well as native PW. I have to say one area where I think PW needs to close the gap is in using a nice shiny, modern admin interface. I love Ryan's original version, it's very ergonomic but I think a few of the newer systems out there benefit from really modern clean design (eg: Squarespace). I'm currently making a few tweaks to Nikola's excellent Ergo theme.

I'd be very happy if you could do that -- would love to explore this concept a bit further and method I've posted here is nowhere close to "clean"..

You're welcome! If you just load the page for editing, then isPost is false. This means that the JqueryWireTabs get loaded. I belive the reason behind the check is that if we're dealing with a save-request, there's no need to load UI stuff like JquerWireTabs, because Pw does a redirect after the save. $this->isPost is used multiple times in the module, so it makes sense to save this long boolean expression in a variable which is easier to read.

Hi guys I've switched over from WordPress. Perhaps it's better to say that I have graduated from WordPress. I would like to add though that having spent a bit of time with Joomla, Drupal and WordPress, there was much to be learnt from the software and their respective communities in terms of their outlook and priorities. By spending time in the WordPress world for instance, I have come to learn a lot on the subjects of Typography and Search Engine Optimization. Drupal gave me an appreciation for the usefulness for Taxonomy and certain concepts of logic. I thought their token system was a great idea. Joomla, well, it was illuminating to see the long term effects of their project leadership circa 1.5 and what happens when there isn't a clear or prompt roadmap for some of us users Diversity in our world is a wonderful thing. May they all continue to "live long and prosper". I wouldn't be both in instant awe and totally content with my wife PW had I not lived with those 3 bitches J, D & WP ... The rascal that I was... sometimes I would have all 3 of em in the house at the same time...

@Pete - i've been using Diogo's custom admin pages to handle situations with a lot of data that I want to put into a custom table, using dataTables.js, so since this is the results of a selector, i would guess that you could show the repeater data in something like this...

Any decent web developer knowing php will be able to step into advanced PW building without problems. Not true to other system I know of.

Hi Debbylevinson, A quick one. The most important thing to do before you try to recover the site is to backup the /site/ folder and the database if you haven't done that already. Make sure you do that before taking any action. I'm pressed for time ATM but you have several alternatives...Before that... check in /wire/config.php There you will see the ID of the superuser and the role ID of the superuser. In PW 2.3 these are 41 and 38 respectively. You can also see this in phMyAdmin if you look under field_roles and pages. So, under the table "pages", find the name of the page with ID 41 (see "name" column). If you are still unsure about what to do, I'd be happy to chat via PM.

I really like this thread and what all you people are commenting. First, because I find more "newbies" like me, with similar difficulties but eager to learn. I love the support and dedication that experienced PWirers offer. And finally, i find that PW has kind of a "scalable learning curve", I mean actually I don´t fully understand it or some of the profiles of course... but i can do so many things and perform a lot of functionality with something as "simple" as: $page->get("name=123") echo "... or using the Related Pages Field. Uau! amazing, directly in the CMS, no need to add custom fields + plugin + then style it (where this class come from?!important) or something like that. I come from another CMS where I was for me so difficult to relate data, and i think that this is one of the main features a CMS should offer. So I settle here, and hope to reach far. Thanks

I built a site for a client with WP just about 5 months before discovering PW. The client insisted on WP at that time and I couldn't see any reason why not. Then about a year later they wanted to do a whole bunch of re-structuring; at this point I was already using PW and had built a few sites with it; When i looked at what they wanted to do, i had to cringe and say "this would be so easy in PW"... I ended up making extensive use of ACF (Advanced Custom Fields) which is a decent solution if you are stuck on WP. It can offer a tiny taste of what you can do in PW with custom fields and is allowing me to think like a Processwirer despite being trapped in WP; i did hit a brick wall once or twice (since there are some things WP+ACF simply can't do that PW can)... The other silly thing about this is that they requested WP because they thought it would be easy for their employees to manage the content. However this has not turned out to be the case, and consequently they ask me to make all the changes anyway.. Now i have to undergo the annoyance and aggravation of logging into the WP admin which is just awful (esp. in comparison to PW), and plodding through that interface to make their changes...

ProcessWire wants to have a local path to save files when you upload them. But using a solution like Teppo's, where you alternate the URL where they live, is certainly a possible way to redirect requests for any file to an alternate location. Another possibility is that I could make PagefilesManager::url() hookable, so that you could modify it with a hook. This would probably be the cleanest method, and I'll be happy to add the hook if anyone wants it. However, you would still need to be responsible for making sure that the files that live in /site/assets/files/* manage to find a way to their new URL location, whether it's literally having them copy to that location, or it's a directory mapped to another drive or server, etc.

I really like the way you advertise ProcessWire with the sticky logo. Very cool! On projects page, 3 of 4 posts contain screenshots. It kind of breaks the visual rhythm. I like the idea of the Table of Contents in each post. It makes reading long posts easy. Maybe bookmarkable URLs for tutorials or super long posts?

Greetings Teppo, I have spent time looking at this, mostly on mobile (iPad, Safari/Chrome). I really like the typography and the bright color theme. Each individual article has a nice eay-to-read presentation. It's great that you focus on content, which is what matters most of all for a site like this. And speaking of content -- you wrote lots of excellent arrticles! Keep that going! I agree with others regarding the logo, although it looks better on mobile. My only other comment is on the layout of blog articles. The uneven vertical space of articles makes the layout a bit confusing (although, even here, navigating to a title is not too bad). There seems to be an issue displaying the "project" pages (on mobile). They display initially, then the content disappaears: http://www.flamingruby.com/projects/process-login-history/ http://www.flamingruby.com/projects/page-render-ip-restriction/ http://www.flamingruby.com/projects/version-control-for-text-fields/ http://www.flamingruby.com/projects/process-changelog/ I have this book arked and will definitely watch your posts. Thanks, Matthew

More alive… Well. I don't know, whether it's because of the icons, or because the are no boxes/lines/backgrounds that would reinforce the masonry grid, but it feels that articles all over the place, without any sense of order. I think your homepage would benefit from more strict grid, or if you really want something unusual, come up with it manually. In any case, I'd force a bit of order on the items. On the other hand (to offset this at least a little), the spacing between items is just perfect on mobile. Other small things I noticed: on the Projects page, the images are little decoupled from their respective items. I understand this is a result of some internal "no item backgrounds" rule, but it's weird. Maybe adding a 'no-screenshot' thumbnail to all items would help a little. Also, on iPhone, the header as something like doubled right margin then left margin. But also, the fonts look even more fabulous on teh mobile. I commend you on that selection again, I really like the general typography.

Hi Teppo. Very good site with good and usefull articles! I like that it is clean and has good readability. Also it seems to have some nice parts that needs further study. I also like how you advertise PW! Keep up with it ----- Does the Logo display correctly in Firefox (22.0)? (see screenshot) In http://www.flamingruby.com/blog/ready-set-launch/ is a show/hide TOC, but the links have no anchors in the doc (at least in my FF)?

^ Completely agree. I just started learning AngularJS two or three days ago and I cannot believe what I've already been able to whip up. It's such a blast!! Also, nice site! Love how clean it is. The one thing for me there's a bit too much pink and red and it seems to clash with the dark purple, but that's probably because I don't see this color scheme often. Like others said, I think the responsive part is really awesome. Love how the posts transition as you adjust screen width, and especially how the logo responds as well.

I'm revisiting the site on my mobile and it feels great! I like particularly the summary on the posts pages I'm also loving the posts. Next on my list is the one about caching.

Just read your post about Fieldtypes/Inputfields. Thanks! Very useful informations! Keep it up

Zahari, Thanks for writing up about your experience, I have quickly read your post. One thing that sometimes confuses newbies is the so-called "the ProcessWire way of doing things". You will find out that in most things, there is no such way Yes, you will get advice about different approaches to solving a problem. One thing that is stressed though (by the way) is to sanitize your input (this has nothing to do with your post above) - that, perhaps, is one (of the few?) examples of the "ProcessWire" way . What am I saying? Feel free to experiment like you've done above, look at different approaches. The approach above by Ryan is one of the approaches available. When you have time, study also the default profile's template files, then look at the Blog profile and the Skyscrapers profile as well as code by other seasoned guys in these forums. You will see different approaches there. Choose what you believe makes best sense to you and ask questions. Finally, if you haven't already done so, have a read at the below link. This gem of a thread discusses various approaches to doing template files in PW: http://processwire.com/talk/topic/740-a-different-way-of-using-templates-delegate-approach/ Happy coding!

$items is a parameter of the function. When you use the function like this: renderNav($page->children), the array $page->children will be attributed to the variable $items inside the function. exactly the same as if you would do: $items = $page->children. that function could have been written also like this: function renderNav($items, $options) { instead of: function renderNav(PageArray $items, array $options = array()) { The difference is that, in the second example (the real one), the function is forcing us to use a PageArray for $items, and a regular array for $options. Plus, in the second parameter, the function also defines a default value to $options (in this case, an empty array), so you don't have to define a second parameter when using the function.

I created an empty language pack. Go to: Admin > Setup > Languages Create a new language Drag & Drop the attached zip-file in the Language Translation Files Field. Start to edit the files. empty-lang_pack_pw_3.0.41.zip EDIT: Obsolete in latest PW Versions. Create a language pack by your own. Go to: Admin > Setup > Languages > Add New Save Press button: 'Find Files to Translate' Select all files in the box 'Translatable files in /wire/' Select files in the box 'Translatable files in /site/' which you want to add to your custom language pack Press 'Submit' Start translating Download zip or csv file by pressing the related button at the bottom of the page where translatable files are listed. Done

Wise words.

things went wonky after they got that "big investor" on board and started talking about taking on the big three. but don't worry, according to most of their blog posts, everything's "amazing"

Can I just say that if ever there is a book written about how to use ProcessWire, this should be the foreword - it's perfect! I did fail to read it in the suggested accent and read it in an Austrian Arnold Schwarzenegger accent - it was amazing (like this - http://bit.ly/c7op9H ).

Hi lance, welcome. PW is very flexible and has no "Site" title as it's mostly something you set/code in your template. However you could use any field or page title field as the site name from any page you like. So maybe use the root node "home" on the top of the tree to define a site title for your website. To for example simply output the title from the root page use echo $pages->get("/")->title; Or if you want you could create a simple textfield ie. "site_title" and add that to the "home" template in PW. Then you simply change the above to echo $pages->get("/")->site_title; Another possible route is to use config file to add a title in /site/config.php $config->site_title = "MyHomepage"; then to you can access it from any php template like echo $config->site_title;

Sounds great, I look forward to seeing it. As promised, here's a full example of a simple contact form. This is bare bones, but safe. I've left out spam prevention measures, which I'll be happy to follow-up with if you'd like. Below is an entire template file. I figured it was simpler to show this way rather than splitting into multiple files. Though when forms get really large, I tend to split them in multiple files (and include them). But for smaller forms, I do it like the example below. /site/templates/contact.php <?php $sent = false; $error = ''; $emailTo = 'nikola@company.com'; // or pull from PW page field // sanitize form values or create empty $form = array( 'fullname' => $sanitizer->text($input->post->fullname), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class='error'>Please check that you have completed all fields.</p>"; } // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $message, "From: $form[email]"); // populate body with success message, or pull it from another PW field $page->body = "<h2>Thank you, your message has been sent.</h2>"; $sent = true; } } if(!$sent) { // sanitize values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // append form to body copy $page->body .= <<< _OUT $error <form action="./" method="post"> <p> <label for="fullname">Your Name</label><br /> <input type="text" id="fullname" name="fullname" value="$form[fullname]" /> </p> <p> <label for="email">Your Email</label><br /> <input type="email" name="email" id="email" value="$form[email]" /> </p> <p> <label for="comments">Comments</label><br /> <textarea id="comments" name="comments">$form[comments]</textarea> </p> <p><input type="submit" name="submit" value="Submit" /></p> </form> _OUT; } // include site's main template which outputs everything include("./main.php");

Attached is a module that gives you page level access control for view access in PW 2.1. It's fairly basic, but gets the job done and it's something to at least start from. I've tested it to make sure everything works, but not exhaustively, so let me know if you run into any issues with it. To install 1. Copy the attached file (CustomPageRoles.module) to /site/modules/ 2. Click 'Check for new modules' in Setup > Modules. 3. Click the install button for 'Custom Page Roles'. It will automatically add a field called 'page_roles' to your fields list. Add this field to any templates that you want to have page-level access control. Now when you edit a page using a template that has this field, you'll have checkboxes for roles that you can choose to define access from. When at least one role is checked, the page has access control authority for 'view' permission, rather than the template. When no roles are checked, then it will check the parent page to see if it has a page_roles field and delegate control to it. That parent's page_roles field is used in the same manner. As a result, you can inherit up (or down) the tree as long as the parents have page_roles fields. Authority will be given to whatever parent ultimately defines access (by having at least one role checked). If a page has a page_roles field with nothing selected, and it's parent doesn't have a page_roles field, then access inheritance stops and access control is deferred to the template. As an extra security measure, I've also set it up so that a page's template has to allow 'view' access in order for a page using it to inherit access from a parent page. Though I'm not sure if I should keep it this way... But here's the thinking: page level access control is a little bit dangerous in that one change can affect a lot of children (grandchildren, etc.), so that extra security is just so that the superuser exercise additional control where they deem necessary. This is similar to access control in PW 2.0 except that it's a little simpler (and perhaps less powerful) in that all the roles are inherited as a group rather than individually. Though this also means less ambiguity, which is a good thing. But ultimately this module is just a starting point and you all may want to suggest improvements or take it further. Caveats The main caveat here is that this does not affect results returned from $pages->find(), $page->children(), etc. Those are purely controlled at the template level. Here's two scenarios where that could affect you: 1. If access is allowed by your template, but not by your page, your page may still appear in search results and API functions like $page->find() and $page->children(). That doesn't mean the user can view the page, only that it may appear in searches. If you don't want that to happen, you'd have to take the same approach that you did in PW 2.0. When outputting a list of pages, skip over any where $page->viewable() returns false. 2. I think this will be an uncommon situation, but if you have guest access disabled in a template, but enabled on the page, the page is not going to show up in API functions that return PageArray. To make it show up, you'd have to add: "check_access=0" to your selector, like this: $page->children("check_access=0"). --- Edit: re-uploaded CustomPagesRoles.module file to remove two lines of unnecessary code and incorrect summary. No significant functional changes though, so you don't need to re-download if you don't want to. CustomPageRoles.module