Leaderboard

ProcessWire uses quite basic RBAC system and it probably just didn't feel necessary to dive further into this. Some of the basics: Each user has one or more roles; "guest" is always assumed and required, even for non-logged-in users (i.e. visitors) Each role is a named collection of one or more permissions; page-view (as you noted before) is always assumed and required and only displayed because, well, it's there (that's actually supposed to be helpful; you don't have to guess which permissions this role might have, what you see is what you get) Permissions are just permissions, there's nothing really magical about them; for the most part they're just Pages with special purpose Each Page uses a Template and each Template has access settings, where you can define which roles have access to the basic actions on Pages using said template: view, edit, create and add children One important thing to note here is that an user having a role with page-edit (or page-view) permission won't instantly allow that user to edit / view all pages but it is a prerequisite for giving this kind of access at Template level (via access settings). Template level access settings are just one use case for the access control system in ProcessWire; it actually goes a lot further and is much more versatile than that. (Admittedly this part does sometimes cause confusion and thus it might be worthwhile to document it more clearly.) Programmatically managing and/or checking for roles/permissions is explained in the docs. If you want to check if user has specific permission, whether that's built-in permission or one you've added yourself, it goes like this: $john = $users->get("johndoe"); if ($john->hasPermission("read-the-docs")) { echo "Sure thing, go ahead: http://processwire.com/api/"; } Cheatsheet also provides basic info on most (if not all) actions you can perform on/with users, roles and permissions. If you use $pages->find(), it should already only return pages that current user has view access to (unless you add "include=all"), so I'm not entirely sure what you're referring to in your last comment. Pages don't have roles, they have a Template, and that Template has access settings. If current user doesn't (via one of her roles) have access to view that Page, it won't be returned by $pages->find() either. Note: $pages->get() is different from $pages->find(), as it assumes you really want that one, specific Page. It always returns the Page (if it exists) without considering permissions.

Hi guys. Just wanted to properly say "hi" and thank everyone for all the help lately. I'd been posting as "sparrow" for many months while I got started and many of the regulars here have been a great help. I'm an independent web designer from Dublin, Ireland, and my primary CMS is MODX. A while ago I decided that 3 CMS would be a good number to settle on and I began to evaluate Craft and PW. What attracted me to PW specifically has been all the good stuff I'm sure you already appreciate but in particular, I really like: PW fields and especially how powerful the Profields set are Lister (not released yet) Image management (native and CropImage etc. Image control is brilliant in PW) Fields control (allowing me to specify exactly which field(s) to display per template) How friendly the community is How communicative Ryan is re. the product and the fact that there is a roadmap and that roadmap is largely followed and updated The array of great Modules available etc etc. But basically, PW has been impossible to ignore with the recent adittions of Profields and Lister. I'm very much at the beginnings of my PW journey so to be balanced, these are the areas that I've found challenging: Speed. I find *just* having a tree slows my editing down a lot. Would love to see a tree on the left and the page edit on the right. Obviously, I'm coming to this from a MODX perspective Right-click Again, probably baggage from MODX but it's very useful to be able to right-click a page and duplicate, delete, move, hide from menu, quick-edit etc etc. I can't do this on PW. But mayeb there's not such a need. User control The user control and permissions look very basic. I'm used to much more fine grained control over which elements of the admin a client can see Manager appearance When I first installed PW I found the box-iness and colors a bit hard to settle into. Some of that may have just been TinyMCE which I replaced and I believe made a huge difference. I know there are lots of themes available so that's not an issue now but was definitely a "first impressions" thing. PHP That's not PWs fault. I've gotten used to working with tags so being pushed into a bit more PHP has been a challenge. I'm enjoying it though and feel my skills are slowly but surely coming on. So that's my 2cent. Thanks again for all the help so far and it's great to be part of yet another very friendly CMS community. On a side note, I have started a mini blog based on PW, Craft and MODX as I think they really are 3 of the best CMS available. Will update soon when I have a little more content.

The Background Early in December 2013, the National Geographic Traveller India team at Amar Chitra Katha, called Pigtail Pundits over to help them build their website. Till then, the NGTI site was a poorly cobbled together, pale shadow of the publication in html and css, comprising, mainly content from the offline magazine articles. It was formatted too plainly, and didn’t carry the richness of imagery, gloss and character that you’d associate with anything from the National Geographic stable. The Brief NGTI had an ambitious remit for the revamped website. It will contain the offline magazine, in full, with each issue richly illustrated with some 35 odd travel stories and encrusted with glorious pictures The past issues of the magazine, some 15 of them so far, would have to be imported into the new system gradually It will carry have articles written exclusively for the web, by a separate editorial team It must have the ability for accepting photos from amateur travel enthusiasts, every day It must showcase the images from National Geographic Traveller in all its glory through on-page galleries and sliders It must have a workflow for the editorial to schedule articles into the future It must be fitted with rich tags to describe/ cross-tag the articles, the ability for browsers to comment and search ability built into it What’s more, it must come close in feel and richness to the National Geographic mother site in the US. That site incidentally, was in Beta at that time, and used some really fancy, jaw dropping scripts and effects. We were wondering as to what technology it was built on. But, there were a lot of challenges to tackle before we even reached to the front-end effects. To Drupal, or to Processwire? The Million $$ choice. We took on the challenge of the revamp. Thinking through and rationalising the different and varying content types in the magazine was our first task. We noted 13 different types. The trick was to winnow this down to just one content type that could fit all types of articles. Then, in fitting this content type into the system, we had to take a few calls. We argued that the system must have the flexibility to allow editors to embellish their articles - with drop caps, pull quotes, captions, guides and other style ornamentation that was singular to the National Geographic Traveller. In order to do this effectively, we would have pre-styled codes in the system that could be invoked using short codes as the editors saw fit. This was a whole sight better and more flexible than putting text into pre-styled boxes that would constrain the editorial. Drupal CMS was our first choice in putting this system together. We had worked with Drupal for several years now and we knew a thing or two about customising it too. The only challenge was to get a young team at Pigtail Pundits behind Drupal. The learning curve for Drupal was always daunting and that was a concern. We started work on Drupal in early January 2014. We cobbled together an internal team that would work on the project. After about a month into Drupal, we had almost everything ready for a demo to the client, save for styling. In early February, we had a rethink. We were working on some projects and testing out Processwire, internally in parallel with the NatGeo project. We found PW to be a fast, flexible, efficient system, without either the bloat and the learning curve required of Drupal. We had to take a call. Drupal, for all its goodness, still made heavy weather of its modules. Drupal optimisation alone required a lot of modules at the application level. Plus a few on the server - memcache, ably supplemented with server processing speed and memory in fair, generous helpings. But optimisation itself was just one of the many things that troubled us about Drupal. There were a heap of other modules, each adding weight and extra lumber to the ponderous system. Besides there was image heavy content. We had serious doubts as to the conditions under which the site would run well with Drupal, both immediately, and in the long run. We had to take a call. Time for a few seditious thoughts Could we now change the NGTI project to Processwire from Drupal? What would be the implications? For us, for NGTI? We had to grapple with a whole bunch of fallouts of this. How do we come clean with the client on this? Would that decision to shift hurt us? What if the client were to say no to the shift? What about getting our internal team that was already on Drupal, come to grips with Processwire? How long would that take? The reasons to shift to Processwire were clear. Speed, flexibility and scalability given the volume of content that was going to be part of the magazine and web editorial, the features we required, and the potential traffic on the NGTI site. The decision had to be made now. We decided to make an early switch to PW. And in retrospect, it was probably the best decision we took. We had to instil confidence in the client that this switch to Processwire was the right thing to do. If we relayed the news too early, it could have worked against us. We had to prove that PW was a better decision. So we went ahead and simulated all that we’d done in Drupal into Processwire without asking the client, or giving them a whiff of what we were up to. We worked in parallel on both the systems. It took us about 15 days to get everything in Drupal into PW. Mercifully for us the client was hunting for a design team that would do justice to the Nat Geo design pedigree and that took some time. Along with the fact that the new web editorial team was still being formed. We used this lull effectively to make the switch. Remarkably, our Drupal team picked up PW twithout any issues. It took them a week to grasp it and get going. That was a record of sorts as we’d folks who struggled with Drupal even after 3 months on a project, still coming to grips with techniques and modules. But PW was a cinch. The Processwire Miracle We put together the first cut of the site in Processwire. Rationalized content types for magazine articles were in One magazine issue was fed in so that we could slap on some styling Hannah code was used generously to style the content within the editor, without getting in the way of content, or trapping this into pre-styled text-area boxes. Magazine captions, guides, block-quotes, drop caps were driven by Hannah to facilitate the editorial hoopla Gallery and slider scripts were quarried for the demo The demo date was decided in early April. We showed off the system, its speed, and ease of use, live to the client. It was only after the demo that we told them that the system was not Drupal, but Processwire. They were already sold by then. The real intensity on the NGTI project however started in June 2014 when the designer Matt Daniels was brought in by NGTI. We were privy to the early designs of the Home Page, Landing Pages and Detail Pages. But were anxious as to how things would play when the entire design was complete. After all the design was not in our control. Luckily, everything went off well. There were a few challenges, and these were taken up and resolved. Javascript for the galleries, sliders had to be rewritten from scratch to conform to the design requirements Editorial came up with a list of how they wanted articles to be featured on the Home Page in blocks and we had to program this accordingly. We managed to queue the articles and then lop the old off, when the new were published Destination page required maps by default and then of city/ country being searched. This was programmed using Google APIs. Marketing came up with the need for ads - leaderboard and sidebar and we had to fit these in An Events Calendar was programmed from ground up, as per the design for Events The import of prior issues was debated, captured into excel sheets, reviewed, and reviewed some more. Scripts were written for import. Scripts were written to test the integrity of the data input before import. And everything came together in August, 2014. 6 magazine issues were imported before the launch was announced on August 14. The NGTI team went in and styled these quickly using the tools we had built for them. The final build had 20 different templates. In retrospect, we could have rationalised these too to fewer. But these came in bit by bit for the build and there was little we could do there as we couldn’t see the whole, before it arrived. The NGTI team was trained on the backend operations as part of the build itself, so by the time we had completed the site, they were up and ready to input. The project is still in beta for a few days. Optimization using just compression of CSS & JS works fine for speed. The site works like a charm now. Thanks everyone Thanks are due to Processwire and the amazing system and set of modules that are in place. Thank you Ryan Cramer. We don’t have to tell you how much we enjoy working with this system, after coming from Drupal and WordPress. Thanks to all the lovely folks on the PW forum who had answers to niggling issues we had. Key Tools, Systems used: Processwire 2.4 CMS with Foundation 4.0 framework Hannah Code for short codes in the editor for style application Event Calendar was coded ground up Form Builder was used for front end forms CK Editor, for text area editing with Image extra for description and tags ProCache - for server level caching Video Embeds and Images used field uploads Image Captions & Tags using image extra fields Scheduler, for advanced date publishing AIOM - for compressing JS and CSS for speed improvements MailChimp Integration for Newsletter Disqus Integration for Comments Integration of Facebook, Instagram, Google Maps via API Integration and customisation of Google Search Integration of DoubleClick and Adsense for advertising

@Newbie, click on the field name to edit its settings (see attached screenshot). It took me a while to figure out too

Hey guys, Please, please read netcarver's warning before making changes to the 'admin' template settings. Changing access for non-logged in users from login prompt to http 404 may effectively block you from logging in! If you have locked yourself out (like I just did), do the following: - Log in to phpMyAdmin. - Find the 'pages' table, then Browse it and find the Id of the page named 'login'. Mine was 23 and I did not change the default settings. - Then go to the table 'templates', find the line with name=admin and edit it. Add , "redirectLogin":23 to the array (assuming that 23 is the id of the login page). Save (press "Go"). Now you will be able to access your admin login prompt. I attach a screenshot, so that should be pretty clear.

Hey bipster, Entering a title isn't required. Have a look at this thread. https://processwire.com/talk/topic/7477-strategy-for-flexible-content-types-in-a-template/#entry72309

Hello Peter Knight! I started in the community recently I can only say ... The cms and the community are great Lists are cool Edit by me Because 2 lists Are better than one. Just kidding

I think we need an option "don't ever display children here" as a template setting. At least for editors. Even I am a bit confused when I accidentally open a folder in the tree where all this data crap is in

PageTableExtended Download here: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Extends the Processwire PageTable field for rendering table row layouts. This is great for editors, because they actually see at a glance what the table rows consist of. What it does Turns the Processwire Fieldtype "Page Table" from this: into something like this (sorting capabilities of course still functional): See it in action: Requirements FieldtypePageTable installed (part of the core since Processwire 2.4.10.) Templates used for PageTable need a file associated (otherwise nothing gets rendered) This render method is meant for sites where the PageTable templates only render part of the layout, not complete websites. But you also can define what will be rendered (see below). Options Render Layout instead of table rows Check this for seeing the rows rendered. You can easily turn off the complete functionality by unchecking this. Path to Stylesheet Since the parts are unstyled by default, it is a good idea to define styles for them. All rendered templates are encapsulated in a div with the class "renderedLayout" so you can style them with: div.renderedLayout h2{ color: green; } The path is to be set relative to your templates' folder. Reset Admin CSS Since the parts are rendered inside the Admin, common styles of the Admin Interface apply also to your layout parts. This is not a bad thing, because especially text styles are well integrated in your admin's theme. But if you like to override the admin styles in your table rows completely (more or less), just check this box. Don't forget to define a custom CSS then! Advanced Since this module is meant for parts of your layout you already have defined for your frontend templates, it is a good idea to use a preprocessor like Stylus, Sass or Less for building the custom CSS file. Just outsource your layout part definitions in an extra file, compile that in a separete CSS file and use this as custom CSS for this module. Since your CSS is should be built in a modular way, this works pretty well ;-) Will write a tutorial with a use case once finished testing. Notes: Github: https://github.com/MadeMyDay/PageTableExtended If you want to get rid of the unnecessary step for entering a title before editing the page, just set the "autoformat" value as suggested in the PageTable settings. If you don't want to use a title field at all, see this post from Soma Will put it in the module repository once finished testing. Please test it and give feedback. I haven't used GitHub for a long time, please check if everything is in place and if this will work with the modules manager and the new core module installer once added to the repository. Have fun Module is in the repository now: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Please use GitHub for instructions, I made some additions there.

Would be nice to have a thorough explenation how to setup access. It might be me, but I never succeeded in setting this up the right way (at least, what I would like). Going to Access does not explain a lot. Docs neither. Example : permissions - I can add a new one. But what to do with it? it just has a title and name field... users - I can add users, and asign roles... roles - I can check what permissions they have, but how do you handle this in frontend, especially with new permissions. I find under permissions the "page-view (required)" rather confusing. If it IS required, why put it there? I would like to see a PW native function or something that said: find all pages - from this directory - but show only - if they have certain roles (page-view) That way, page-view would make sence to me. But as I said, it could just be me...

What happens if you use: https://github.com/NicoKnoll/ProcessPageDelete/archive/master.zip in the new "Add Module from URL" option?

Works great for me on 2.4.18 Sounds like kixe and mr-fam are actually having issues with it working on 2.4 stable. Maybe you guys could try an older version from Github. I thought it might be related to the autoload condition that was added a while back, but then the delete button wouldn't show either, so not sure. Not sure that it is worth Nico messing around too much though since 2.5 is only a week or so away

No need to remove it from the template, just make it hidden and not required in the context of that template. I don't think there is really any need to populate it all in this case, but it would be possible via a hook if you really want to. You could also remove the global flag for title so it is not in the template at all, but I think the former approach is better.

Thanks renobird!

"Using $form->processInput($input->post) will prevent CSRF attacks and the form will append a hidden field automatically." https://processwire.com/talk/topic/2089-create-simple-forms-using-api/

No problem. It's done in just two steps. Assuming you are logged in with administrative rights: 1. Go to Setup -> Templates. Click "Filters", then set "Show system templates" to Yes. Click the "admin" template in the list. 2. On the "Edit template" page click the tab "Access" and scroll down to "What to do when user attempts to view a page and has no access?". Select "Show a 404 Page" instead of "Show the login page". Save your admin template settings and you are done! This setting works for any template, not just admin templates. I attach a couple of screenshots to illustrate the above two steps. Hope it helps you. P.S.: If you want to go a little bit paranoid, I suggest playing with request handling such that GET requests with ?it= in them would be handled differently.

Hey Martijn, I managed this by using the automatic naming option and by setting the title field to hidden and not required in the template context settings (so it doesn't affect other templates) and that seems to be working ok. The one thing I am really missing (and maybe this is just me) is for the PageTable sub pages to be stored in some sort of hierarchy when using an alternate parent page. I can see a complete mess of hundreds of pages ending up in there, with various -n name appendices. Maybe it would be unnecessary extra cruft, but what if sub parent pages (named to match the actual page that uses the PageTable field) were made to store the PageTable pages. e.g.: Home ----About (has a PT field called Sections) ----Portfolio (has PT field called Jobs) PageTableItems (hidden) ----About -------Sections -----------Section 1 -----------Section 2 -----------Section 3 ----Portfolio -------Jobs -----------Job 1 -----------Job 2 instead of the current situation of: PageTableItems (hidden) Section 1 Section 2 Section 3 Job 1 Job 2 I know the latter looks simpler, but I can see it becoming a mess and confusing when page names were automatically changed to avoid conflicts. Anyone agree, or am I on my own

See it in action:

Hi Tobaco, my setup is always the same. Doesn't matter if I use PageTable or not. Here it goes (simplified): /templates - basic-page.php - home.php - /tpl - main.php - mainnav.php - subnav.php - footer.php The tpl/main.php is the overall template like: <?php include('tpl/mainnav.php'); include('tpl/subnav.php'); include('tpl/slider.php'); ?> <!DOCTYPE html> <html class="no-js"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title><?= $page->title ?></title> <!--- styles and scripts --> </head> <body class='<?= $bodyclass ?>'> <header> <div class='wrap'> <a href="/"><img src='/site/templates/img/logo.png' class='logo' alt="Logo"></a> <nav class='main'> <?= $mainnav ?> </nav> </div> </header> <?= $slider ?> <?= $subnav ?> <section class="content"> <div class="wrap group"> <h1 class='v2 hide'><span><?= $page->title ?></span></h1> <?= $content ?> </div> </section> <footer> <div class="group"> <?php include ('tpl/footer.php'); ?> </div> </footer> <script src="/site/templates/dist/all.min.js"></script> </body> </html> basic-page template looks like this (every template renders the content and then includes the main template): <?php /** * basic page template * */ $bodyclass='inner'; $content = $page->body; include('tpl/main.php'); With PageTable the structure looks like this: /templates - basic-page.php - home.php - part_text.php - part_columns.php - part_gallery.php - /tpl - main.php - mainnav.php - subnav.php - footer.php The part_* templates are templates only for PageTable. part_columns.php could look like this: <?php $headline1 = ""; $headline2 = ""; if(!$page->checkbox1) $headline1 = "<h2>{$page->title}</h2>"; if(!$page->checkbox2) $headline2 = "<h2>{$page->text1}</h2>"; // Output echo " <div class='pageTableSection {$page->template->name}'> <div class='inner'> <div class='col one-half'> {$headline1} {$page->body} </div> <div class='col one-half'> {$headline2} {$page->textarea1} </div> </div> </div> "; And the basic page template gets enhanced by ("layout" being the PageTableExtend field): <?php /** * basic page template * including PageTable layout parts */ $bodyclass='inner'; $content = "{$page->body}"; if(count($page->layout)>0){ foreach($page->layout as $l){ $content .= $l->render(); } } include('tpl/main.php'); That way, the layout parts are easily renderable in the Admin with PageTableExtended. While writing this, I want to point to another feature of the module. If rendered by PageTableExtended, the template gets an option 'pageTableExtended' which you can use in your part template: // Output echo " <div class='pageTableSection {$page->template->name}'> <div class='inner'> <div class='col one-half'> {$headline1} {$page->body} </div> <div class='col one-half'> {$headline2} {$page->textarea1} </div> </div> </div> "; if(!$options['pageTableExtended']){ // we are not in the Admin, so we include our social media buttons which we only need in our frontend include('social/socialmediabuttons.php); } Hope that helps.

ProcessWire DataTable 1.0.0 (https://github.com/somatonic/DataTable) This module enables you to find and edit (fancybox modal iframe) pages at a small and very large scale. So far it has: ajax suuport masked pagination state saving (datatable using cookie, template filter using session) template filter (only showing templates user has edit access) search text filter (using title|body field) multilanguage support (PW's language translator) Superuser will see all pages and system templates. Users only those with view|edit access and pages in trash. This Module is still very simple and only in "lazy" developement and testing and this is the first official release mainly to get it out for others to see and use. It also could provide as an example/kickstart for someone. Everyone is encouraged to help and contribute to further improve or add features. The module is hosted on my github account: https://github.com/somatonic/DataTable The plugin used in this module is the excellent jQuery Plugin DataTable 1.8.2 - http://datatables.net/ I've chosen it, because I used in in some other web projects and was really happy about it's power and ease to setup. It supports jQuery UI styling, which makes the deal perfect for a ProcessWire module. Thanks and have fun trying it out. ------ (original post, kept for nostalgic moments) Ok, I started trying to implement the great jQuery dataTables plugin into ProcessWire. So far it works very well and is very powerful and fun. Best of it it support jquery themeroller. Not sure how far this all can go with configuration and how to define which pages should be displayed, what collumns etc... Many many things to consider. But if it could provide as an example on how to implement it, it would be great tool for site builders. Here you can see a short video of how it looks and works.

Hi einsteinsboi, You can move the blog stuff under its own parent, let's say 'blog' and build a the normal website structure around. Like in this example: In your homepage template, you can include /site/templates/blog.inc. In this file, you find the functions to render the posts, latest comments etc. For example, render the latest 4 comments: $comments = findRecentComments(4); echo renderComments($comments);

I've used this script, built from stuff I learned here to back up sites in the past. It will only work on Linux hosting though. To use it, create a folder above your public_html folder called "backups". In this create two folders called "site" and "db". It must be above the public_html folder else you will end up backing up your backups and you will soon run out of disk space that way Now you need to open the attached file and change the path near the top to the path to your backups folder. Next, scroll down to line 41 and enter your site's root username and password (or a database users that you have created that can read all relevant databases for your site). That's it really - upload it into public_html and call it via a web browser to test it, but it should backup the entire contents of public_html and all databases, plus as a special bonus your mail folder, which on this type of hosting means that even if the whole server bursts into flames you can just re-create the mailboxes, put that folder back and the mail is back too Since it uses system commands to run the backups it won't work on restricted hosting, but the easiest way is to follow the above instructions and if it creates files in your /home/yoursite/backups/site and /db folders that have a filesize greater than 0kb then it will work on your hosting. Because it uses system commands rather than PHP to back up, it won't mater much what size your site is and is suitable for sites in the gigabyte range (all depends on your hardware of course). The other thing to note is that it keeps 7 days of backups and cleans out anything older. You can change that by altering the $livecutoff variable to something other than 7. This could use some improvement of course, but I use SyncBack Pro to download the backups each day to a local drive, and also periodically back these up to an external drive kept elsewhere (can you tell I've had trouble with hosting and hard drive failures before? ). cronbackup.php