Leaderboard

I am really glad this topic is brought up in the community discussion. I think we all can benefit from PW being more known and used all around the world. It does not pay off to be good at something nobody else around want to use. It is not like karate secret move you can win the fight with. Your customer has to agree and preferably desire that you use PW. More like Kamasutra than martial arts. But those are common words you all understand those thing better than me. I said about "known" and "used" in the same sentence, but those are quite different things although connected. I do not think that we can or should expect PW to be as commonly used as Wordpress or Joomla, as it is obviously targeting a narrower target audience. But we definetely wish and can expect almost everyone in the web-dev world to at least be familiar with the name. And we want it to have a positive connotation. This is a task, and if we want to achieve it, we need to know, when it is achieved. I think that we need to set goals for 2016 and track the porogress. Site visits might not be the best parameter to evaluate for this particular purpose. I am well aware of Symfony 2 framework and I entertain my thought that once I will learn it and use, but I do not visit their site anywhere near often. What other measurable metrics can we track? Backlinks? Google trends? Maybe even conduct some kind of sociological survey now and in the end of 2016? I also suggest we organize ourselves in our effort. What about conducting a number of marketing campaigns with defined goals, timeframe, and summing up in the end? I can propose a few right now: Get PW more stars on Github. So we can be rated closer to the top in the searches like "PHP CMS" and so. If we do it in condensed period of time, we can even make it to trending, which can bring us quite a number of newcommers. Get PW more reviews with stars on bitnami, which will position PW closer to the top of the apps list. Get PW atop of syn.in on alternativeto.net. I think we deserve at least No. 4 . It could be beneficial to make a dedicated forum thread for the campaign to encourage forum members to participate. We also probably want to investigate the target resource's anti-spam policies if any and organize against them. What do you think?

What might really expose ProcessWire is a book on packtpub.com. These books really helped me to jump start website development about five years ago: http://www.amazon.com/SilverStripe-The-Complete-Guide-Development/dp/0470681837 https://www.packtpub.com/web-development/silverstripe-24-module-extension-themes-and-widgets-beginners-guide I especially liked the first one (The Complete Guide to CMS Development). Nowadays ProcessWire is a lot more beginner friendly then SilverStripe (for example) except that there isn't a well organized book/tutorial for beginners. Such a tutorial should not just scratch the basics, but give an example of how to develop a somewhat complex, database driven website. The above mentioned books did achieve that. (They are outdated and have never been updated, but still good examples.) And I agree that upgrading the cheatsheets with lots of examples is a good idea. I spent 7 years developing Flash/ActionScript games and websites, and I loved the docs Adobe created for ActionScript. It was packet with lots-and-lots of code snippets, most methods had one ore two (or even more) examples, one just had to copy+paste them and tweak them to their liking. Php.net's idea of utilizing the developers to add notes and code snippets is one way to do it, so besides adding "official" snippets, commenters should be able to add their own too. The new WordPress docs site does the same.

This week we're going to look at our path for growth in 2016, which is already off to a nice start! This includes where we've been, where we're going, and how we will get there–with your help. We actually do have several core updates prepared too, but mostly smaller things that will fit better in next week's post. This post originally started as a section of our 2016 roadmap, but I decided it really deserved its own post, so saved it for this week so that we could cover it more in-depth. However, you might consider this part of, or a continuation of, our 2016 roadmap. But rather than looking internally, much of this post looks externally, outside of our software and community, and into the bigger picture of ProcessWire in the web development/design world. https://processwire.com/blog/posts/growing-processwire-in-2016/

Well, spending 12 years on PHP-Nuke the main goal of site upgrade was to keep things as simple as possible. You know all those first generation CMSs, they were a real pain. That is why we rejected Drupal, WordPress, MODX, Joomla during selection process. I was fed up with systems where you only allowed to toss some blocks and an actual page code is generated under the hood. ProcessWire kind of reverse the whole development process. Here you start with a blank page. You write a neat code and turn to CMS only when needed. There are only few templates serving the whole site. For example all lists are the same, differing only by a line of CSS code: http://gsbelarus.com/pw/en/articles/news/ http://gsbelarus.com/pw/en/articles/post/ http://gsbelarus.com/pw/en/articles/deployments/ The same is true for a story page: http://gsbelarus.com/pw/en/articles/deployments/avenu-centr/ http://gsbelarus.com/pw/en/articles/post/analiz-ispol-zovaniia-polei-v-baze-dannykh/ When needed pages are linked through tags. For example, here all right side bars are built by tags: http://gsbelarus.com/pw/en/front-page/solutions/units/fixed-assets/ There is only one code base. Smartphones, tablets and desktop versions are maintained through responsive CSS. You can check how the site will look on a phone or on a tablet just by shrinking browser window. We didn't use any UI scripting. All visual effects are done with animated CSS. Flexes and columns are used widely through the whole site. In fact, one and half year ago only Chrome and Firefox Developer Edition supported all CSS features we needed. Nowadays the site is rendered correctly in all current browsers except for some quirks in built-in browser of Android 5 and earlier. We wanted to save all old links to hundreds of articles from our old website. So, we imported all article id and made a special template which could deal with old URL, parse it, extract old id and find a matching page in the ProcessWire database. A single line in .htaccess file does the redirect: RedirectMatch permanent ^/gs/modules\.php(.*)$ http://gsbelarus.com/pw/redirect/$1 Also, a desire to save all old topics and links determined that we chose a PHPBB3 for a web site forums. Actually, 70% of development time were spent on seamless integration of PHPBB with ProcessWire. We integrated some Google services. Such as map: http://gsbelarus.com/pw/en/contact-us/ Search: http://gsbelarus.com/pw/search/ Forms: http://gsbelarus.com/pw/front-page/about/vacancies/ Calendar: http://gsbelarus.com/pw/front-page/about/calendar/ As of ProcessWire features table repeaters are used on Contact page: http://gsbelarus.com/pw/en/contact-us/ They define form fields you could see switching radio buttons.

Real-Life Example Website: crms.sdtool.info Purpose: Collaborative Resource Management System (CRMS) Ok, this website uses Adrian's Protected Mode module to control access to the website. ProcessWire (PW) Roles are then used throughout to control access to selected pages. Fields within templates are also controlled via this method. These PW Roles are added at each PW template using the Access Tab. I use a concept I call a "Security Container" that sits at the top of the PW Page Tree (backend) on the website. This is how the "Security Container"is explained on the website: Each "Security Container" has a PW template that controls who has access to that particular page. Once again, access is gained via one or more PW Roles. You have to have access to the gateway "Security Container" page to get to any pages under it. My Client: (I will be using the name Axxxx, as I still need to respect confidentiality and privacy) is an Internet Marketing and Investment Company in the Washington DC Metropolitan Area. They provide selected SEO services to their clients. My role with this client is to provide back-end Internet-based infrastructure support for Axxxx and their clients. This comprises of: Manage/maintain existing web hosting user accounts (SSH/SFTP) and creating new ones (when required) Database creation and upkeep Domain and SSL/TLS registrations Wordpress website installations, day-to-day back-end management and upkeep Email domain/account creation, back-end management and upkeep (website, plug-ins and themes) Centralized database backups and restorals Analytics management using Google Tag Manager/Analytics, Piwik and Woopra Work with Wordpress developers, on behalf of the client, to integrate third-party plug-ins or capabilities Accessing Axxxx Client Data or Resources The Axxxx Client has three possible PW Roles that can be assigned: axxxx-client-access (Contractors or any outside Axxxx related entity) axxxx-manager-access (Axxxx Business Owner or Manager) axxxx-staff-access (Axxxx Staff who aren't at the manager level) The top-level Axxxx "Security Container" Page ensures that only the above three PW Roles have access to Axxxx data or resources. Whenever an Axxxx employee logs into the website, they only see Axxxx related information. Form-Based Page Submissions All newly created pages (by clients) make extensive use of Ryan's Form Builder module. Support request pages and emails are created using this handy tool. Each client has dedicated Form Builder forms that are applicable to their particular mission. Email-Based Page Submissions All my clients have the capability to submit updates or new submissions to me through email. I use the fantastic Email To Page module by Pete and Adrian to achieve this feat. I now make extensive use of Twilio based communications capabilities due this module being installed on this website. Axxxx Company Clients The Axxxx Client company has clients of their own and their data is stored within the website's "Client Portal" Security Container. They can all see the "Client Portal" page (but not any CStevensJr or Axxxx data) and each has an individual named page (which is a "Security Container" for their permissions) under it. PW Roles are used here also to segregate access to each client's own data. Whenever a Axxxx client logs into the CRMS, they only see the "Client Portal" PW Page and beneath that their own data/resources. Final Thoughts PW has an extensive Roles and Permissions system which has significantly improved over the last year. I previously made use of Ryan's Page Edit Field Permission module but now use the greatly expanded native permissions instead. My SDTool Project has progressed very nicely and is being expanded to make use of all the great new capabilities that PW provides. I hope this rather long explanation is helpful. This is just one way I work with PW. I will, in the next few months, provide some more promised updates on the SDTool Project (in the linked post) .

Maybe so, that's a good idea. I'll include that in the 2017 version. Though I figure everyone already can see that, whereas a site's Google Analytics isn't public to everyone. I knew the Beer Garden required one to be a member, but had missed that there was a minimum post limit. I suppose that makes sense. Maybe rather than linking to it, I should post a screenshot in there? @Mike Rockett is that okay with you if I put a sample of the design in the post? If so, which one do you want me to use? (or maybe I link to one on your site?)

Hi BartekG, As I understand it, the choice was to not allow search engines to index all the conceptuals being posted in the threads, mostly because we'd only want the finished product to be seen by them. (This was a suggestion made by kongondo - not sure about the specifics there.) That said, the idea was not for it to be 'closed'. The Beer Garden's original purpose is to hide discussions that may involve client work, which is why one needs to be a member to see it. For additional 'protection', it does require that users have 10 posts to their name. Therefore, the posts about the brand and site unintentionally (I'd think) fall within that ambit. (Not sure if the post count can be reduced on a per-post basis.)

I think a central manager (ProcessWatch ?) is a great idea and something I've needed in the past. My collection of PW sites is growing rapidly and a birds eye view if all of them would be a real bonus as we manage more and more. Are there recent developments with PW3 which allows it to share data with other PW sites? Maybe the time has never been better to have a central PW install with the: 1. Ability to see which version is running and what latest Dev and Stable version is 2. Ability to upgrade , backup database etc 3. See a modules installed and their version. See if a new version is available 4. See the health of a site (some kind of ping or status - live or non responsive) 5. See who is logged in per site 6. See latest changes per site I think all of the above are already available within a PW install via native functions and Module so I wonder how they could be harnessed on a central console.

I have been pushing it on quora and there are usually a few others that will as well. Thats a great place. ie. https://www.quora.com/We-need-a-CMS-that-manages-images-and-themes-but-does-not-enforce-some-framework-Any-suggestions or https://www.quora.com/I-need-a-website-Should-I-use-WordPress-or-HTML-CSS-more-info-in-description or https://www.quora.com/How-do-I-make-content-editing-easy-for-my-web-design-clients/answer/Joe-Regan

No problem, Give me a little while and I will write something up.

Hey guys, I finally got my first module ready to publish It's called HappyCssClasses. I know there is BodyClass module, which I used a lot, thanks to Kay Seliger! But lately I needed more flexibility. First thought about a class in prepended template file like $bodyClass = "lang{$user->language->name}"; and then could extend it in template files using $bodyClass .= " blog"; of course. But there is no fun. I want and need to learn more about classes and php so figured this could be a good use case. So what is this module doing? After installation (see readme) it will instantiate $bodyClasses variable which will be available in your template files (should work almost everywhere) Then you will be able to add/remove classes as needed Like $bodyClasses->add("className"); $bodyClasses->add("className", 'key'); // the key is only necessary to remove a class later $bodyClasses->add("className secondClass third-class"); $bodyClasses->add(array('first-class', 'secondClass')); $bodyClasses->add(array('key1' => 'first-class', 'key2' => 'secondClass')); $bodyClasses->remove('keyDos'); $bodyClasses->remove('key1 keyDos'); $bodyClasses->remove(array('key1', 'keyDos')); There are some dynamic classes build in which you can enable by just adding the key $bodyClasses->add("language") to add "lang-{langname}" $bodyClasses->add("template") = "template-{templatename}" $bodyClasses->add("published") = "published" / "unpublished" $bodyClasses->add("pageNum") = "page-1" for pages greater than 1 it also adds "not-first" or $bodyClasses->add("defaults") = adds all of the 4 above (language, template, published, pageNum) or you could define multiple like $bodyClasses->add("language template") Could be in prepended template file, e.g. _init.php, or your appended template file, or of course in specific template files lice article.php I would love to get feedback For example, I just added the possibility to get all defaults by adding "defaults" Is there a better way? Because I conditionally check if the added class is one of the 4 (or defaults) and need to cancel after one of thos got added. But because the "defaults" would add all I need to make sure only to return if not defaults.. if (in_array($class, array('language', 'defaults'))) { $this->classes['language'] = 'lang-'.$this->wire('user')->language->subtitle; if ($class !== 'defaults') return; } As I said, every hint, feedback, suggestion, request, idea or anything constructive is highly appreciated Check out on Github https://github.com/CanRau/HappyCssClasses I'm planning (like mentioned in the readme) that one can enter custom names to instantiate a second (or more) time so you could have e.g. $bodyClasses, $articleClasses, $blogClasses..thinking about implementation. And need to do some other stuff today too ;-) One question to github, I'm using the Github app for os x at the moment. I made a seperate Repositories folder for it. And then I symlinked the module into my modules folder, otherwise I would have to copy/paste everytime I change something. How'r you handling this? Are there better ways? Saludos Can CHANGELOG 0.0.6 - Changed module name from HappyClasses to HappyCssClasses - Added second parameter to $bodyClasses->add("language", "fieldname")

Ryan - you're the twinkly fairy atop our ProcessWire Christmas tree. But seriously, I wonder if you should include a screen grab from GoogleTrends too? It does a great job of showing the increase in Searches for ProcessWire on Google. BTW, your clarity and openness here just highlights the WTF-fest surrounding another platform I use. Nobody knows the number of the next version, they can't agree on the product name, there's no public (if any) roadmap and it's probably over a year since there was any type of public info. I wish them well but reading great posts like yours on how solid PW is and how bright it's future (and present) is, clarifies for me that banking on PW has been the right decision for my business and clients too. And that's not because the other CMS is headlining at Confusion-Palooza but because PW on its own merits has a bright, long road ahead. You've written too a post which I'll happily send clients to when they ask "well, what is ProcessWire"?

PW is different because updates are mostly installed by devs who finished their projects much before deadline and would like to have some extra fun time in the admin

That's true. Still, there are some reasons why you might want to update sites anyway: If you're hosting and supporting multiple sites, it's more overhead when they have different versions of the system running Updates often bring in new features – such as hugely improved image management tools – that your customers might want to use Not having known vulnerabilities in the core or third-party modules in the modules directory so far doesn't mean that these can never ever appear; especially when you're working with third party code, it's good to keep track what you're using and where, and for this reason alone a centralized management platform can be quite useful We're hosting quite a few sites and for this purpose I've built an in-house solution that does pretty much what you've described here. The focus is on making management of a large group of sites effortless and providing automation for common tasks, but this platform is also used to keep track of site-specific features, versions, usage, and so on. There's little chance of opening our in-house solution to larger community, but the thought of building something similar and open-sourcing it has crossed my mind a few times. Potential user base for this would be somewhat limited for the time being, but this is definitely something to keep in mind in the future

In this tutorial I will cover how to use clsource's REST Helper classes to create a RESTful API endpoint within a PW-powered site and how to connect to it from the outside world with a REST client. This is a quite lengthy tutorial. If you follow all along and make it through to the end, you should get both, a working REST API with ProcessWire and hopefully some more basic understanding how these APIs work. As always with PW, there are many ways you could do this. My way of implementing it and the code examples are loosely based on a real world project that I am working on. Also, this is the first tutorial I am writing, so please bear with me if my instructions and examples are not that clear to understand. And please let me know if something is missing or could be made more clear. The steps covered: create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed at) copy and save the REST Helper classes to your site create a template file and write some logic to receive and process data through our endpoint and send data back to the REST client test the whole setup with a Browser REST Client Addon I will not go into fundamentals and technical details on how RESTful APis are supposed to work. I assume that you have already read up on that and have a basic understanding of the principles behind that technology. Some helpful resources to brush up your knowledge: https://en.wikipedia.org/wiki/Representational_state_transfer http://www.restapitutorial.com/lessons/whatisrest.html The complete pages.php template is attached to this post for copy/paste. Lets get started. 1. create templates and pages in the PW backend to get an API endpoint (an URL where the API can be accessed) First we need to create some templates and pages in the PW backend to make our REST API accessible from the outside world through an URL (API endpoint). In my example this URL will be: https://mysite.dev/api/pages/ Note the "https" part. While this is not mandatory, I strongly recommend having your API endpoint use the https protocol, for security reasons. Further down in step 3 we will use this URL to create new pages / update and get data of existing pages. Go to your PW test site admin and: create 2 new templates: one is called "api", the other one "pages". For a start, they both have only a title field assigned. Just create the templates. We will create the corresponding files later, when we need them. enable "allow URL segments" for the "pages" template. We will need this later to access data sent by the requests from the client. in the Files tab of the "pages" template check "Disable automatic append of file: _main.php" create a new page under the home page with title, name and template "api" and set it to hidden create a child page for the "api" page with title, name and template "pages" The pagetree should look somewhat like this: Ok, now we're all set up for creating our API endpoint. If you browse to https://mysite.dev/api/pages/ you will most likely get a 404 error or will be redirected to your home page as we do not have a template file yet for the "pages" template. We will add that later in step 3. 2. copy and save the REST Helper classes to your site I have the REST Helper class sitting in site/templates/inc/Rest.php and include it from there. You could save it in any other location within your site/templates folder. I forked clsource's original code to add basic HTTP authentication support. Click here to open my raw gist, copy the contents and save them to /site/templates/inc/Rest.php In the next step we will include this file to make the classes "Rest" and "Request" available to our template file. 3. create a template file and write some logic to receive and process data through our endpoint and send data back to the client This will be the longest and most complex part of the tutorial. But I will try to present it in small, easy to follow chunks. Since we access our API at https://mysite.dev/api/pages/, we need to create a template file called "pages.php" for our "pages" template and save it to /site/templates/pages.php. Go ahead and create this file (if you're lazy, copy the attached file). Now right at the top of pages.php, we start with <?php require_once "./inc/Rest.php"; to include the REST Helper classes. Next, we initialize some variables that we will keep using later on // set vars with the default output $statuscode = 200; $response = []; $header = Rest\Header::mimeType('json'); 3.1 retrieve data with a GET request Now that we have the basics set up, we will next create the code for handling the easiest request type, a GET request. With the GET request we will ask the API to return data for an existing page. To let the API know which page it should return data for, we need to send the page id along with our request. I am attaching the page id as an url segment to the API endpoint. So the URL that the client will use to retrieve data for a page will look like: https://mysite.dev/api/pages/1234 where 1234 is the unique page id. Add following code to pages.php // if we have an urlsegment and it is a numeric string we get data from or update an existing page: handle GET and PUT requests if($input->urlSegment1 && is_numeric($input->urlSegment1)) { $pageId = $input->urlSegment1; // GET request: get data from existing page if(Rest\Request::is('get')) { // get the page for given Id $p = $pages->get($pageId); if($p->id) { $pdata = ["id" => $pageId]; // array for storing page data with added page id $p->of(false); // set output formatting to false before retrieving page data // loop through the page fields and add their names and values to $pdata array foreach($p->template->fieldgroup as $field) { if($field->type instanceof FieldtypeFieldsetOpen) continue; $value = $p->get($field->name); $pdata[$field->name] = $field->type->sleepValue($p, $field, $value); } $response = $pdata; } else { //page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } else { // no url segment: handle POST requests } // render the response and body http_response_code($statuscode); header($header); echo json_encode($response); Lets brake this down: First we check for a numeric url segment which is our $pageId. Then the Rest Request class comes into play and checks what type of request is coming in from the client. For the GET request, we want to return all data that is stored for a page plus the page id. This is all good old PW API code. I am using the $pdata array to store all page data. Then I am handing this array over to the $response variable. This will be used further down to render the JSON response body. If the page does not exist, I am setting an error message for the $response and a status code 404 so the client will know what went wrong. The else statement will later hold our POST request handling. The last 3 lines of code are setting the header and status code for the response and print out the response body that is sent back to the client. You can now browse to https://mysite.dev/api/pages/1 where you should see a JSON string with field names and values of your home page. If you enter a page id which does not exist you should see a JSON string with the error message. Lets move on to updating pages through a PUT request 3.2 update pages with a PUT request Since our API needs to know the id of the page we want to update, we again need to append an id to our endpoint url. In this example we will update the title and name of our homepage. So the request url will be: https://mysite.dev/api/pages/1. For the GET request above, anyone can connect to our API to retrieve page data. For the PUT request this is not a good idea. Thus we will add basic authentication so that only authorized clients can make updates. I use basic HTTP authentication with username and password. In combination with the https protocol this should be fairly safe. To set this up, we need an API key for the password and a username of our choosing. We add the API key in the PW backend: add a new text field "key" and assign it to the "api" template. edit the "api" page, enter your key and save. (I am using 123456 as key for this tutorial) Now add following code right after the if(Rest\Request::is('get')) {...} statement: // PUT request: update data of existing page if(Rest\Request::is('put')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // get the page for given Id $p = $pages->get($pageId); if($p->id) { $p->of(false); $p->title = $sanitizer->text($params["title"]); $p->name = $sanitizer->pageName($params["name"]); $p->save(); $response["success"] = "Page updated successfully"; } else { // page does not exist $response["error"] = "The page does not exist"; $statuscode = 404; // Not Found (see /site/templates/inc/Rest.php) } } } Breakdown: We check if the request from the client is a put request. All data that was sent by the client is available through the $params array. The $params array also includes $params["uname"] and $params["upass"] which hold our API user and key. We set API key and user and check if they match with the values that were sent by the client. If they don't match we store an error message to the response body and set the appropriate status code. If authentication went through ok, we get the page via PW API and update the values that were sent in the request body by the client. Then we put out a success message in the response body. If the page does not exist, we send the appropriate response message and status code, just like in the GET request example above. Now you might wonder how the client sends API user/key and new data for updating title and name. This is covered further down in step 4. If you want to test the PUT request right now, head down there and follow the instructions. If not, continue reading on how to setup a POST request for creating new pages. 3.2 create new pages with a POST request Final part of the coding part is creating new pages through our API. For this to work we need to implement a POST request that sends all the data that we need for page creation. We will do this at our endpoint: https://mysite.dev/api/pages/ Paste following code within the else statement that has the comment "// no url segment: handle POST requests": // POST request: create new page if(Rest\Request::is('post')) { // get data that was sent from the client in the request body + username and pass for authentication $params = Rest\Request::params(); // verify that this is an authorized request (kept very basic) $apiKey = $pages->get("template=api")->key; $apiUser = "myapiuser"; if($params["uname"] != $apiUser || $params["upass"] != $apiKey) { // unauthorized request $response["error"] = "Authorization failed"; $statuscode = 401; // Unauthorized (see /site/templates/inc/Rest.php) } else { // authorized request // create the new page $p = new Page(); $p->template = $sanitizer->text($params["template"]); $p->parent = $pages->get($sanitizer->text($params["parent"])); $p->name = $sanitizer->pageName($params["name"]); $p->title = $sanitizer->text($params["title"]); $p->save(); if($p->id) { $response["success"] = "Page created successfully"; $response["url"] = "https://mysite.dev/api/pages/{$p->id}"; } else { // page does not exist $response["error"] = "Something went wrong"; $statuscode = 404; // just as a dummy. Real error code depends on the type of error. } } } You already know what most of this code is doing (checking authorisation etc.). Here's what is new: We create a page through the PW API and assign it a template, a parent and basic content that was sent by the client. We check if the page has been saved and update our response body array with a success message and the URL that this page will be accessible at through the API for future requests. The client can store this URL for making GET or PUT requests to this page. If you're still reading, you have made it through the hard part of this tutorial. Congratulations. Having our code for reading, updating and creating pages, we now need a way to test the whole scenario. Read on to find out how this can be done. 4. test the whole setup with a Browser REST Client Addon The link in the heading will take you to a place from which you can install the very useful RESTClient addon to your favorite browser. I am using it with Firefox which is still the dev browser of my choice. Open a RESTClient session by clicking the little red square icon in the browsers addon bar. The UI is pretty straightforward and intuitive to use. 4.1 test the GET request Choose Method GET and fill in the URL to our endpoint. If you do not have a SSL setup for testing, just use http://yourrealtestdomain.dev/api/pages/1. If you happen to have a SSL test site with a self signed certificate, you need to point your browser to the URL https://yourrealtestdomain.dev/api/pages/ first in your test browser and add the security exception permanently. Otherwise RESTClient addon won't be able to retrieve data. If you have a test site with a 'real' SSL certificate, everything should be fine with using the https://... URL Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string with data of your page. now change the 1 i the URL to some id that does not exist in your site and hit send again. You should get a 404 Status Code in the Response Headers tab and an error message "{"error":"The page does not exist"}" in the Response Body (Raw) tab. If you get these results, congrats! The GET request is working. For further testing you can save this request through the top menu Favorite Requests->Save Current Request. 4.1 test the PUT request Choose Method PUT and fill in the URL to our endpoint ending with 1 (http://yourrealtestdomain.dev/api/pages/1). In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remember me" and hit Okay. You now should see Content-Type and Authorization headers in the "Headers" panel. Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. As I will update the home page for this example, my JSON reads { "title" : "Newhome", "name" : "newhome" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon. Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page updated successfully"}". Now go to the PW backend and check if title and name of your page have been updated. If yes, congrats again. 4.2 test the POST request Choose Method POST and fill in the URL to our endpoint without any page id (http://yourrealtestdomain.dev/api/pages/). In the top left click Headers->Content-Type: application/json to add the right content type to our request. If you miss this step, the request will not work. You will now see a "Headers" panel with all your headers for this request Click on Authentication->Basic Authentication. In the modal window that pops up, fill in user (myapiuser) and password (your API key). Check "Remenber me" and hit Okay. You now should see Content-Type and Authorization headers in the "Headers" panel. Next, we need to send some data in the request body for updating our page title and name. Since we're using JSON, we need to create a JSON string that contains the data that we want to send. I will create a new page with template basic-page and parent /about/ for this example, my JSON reads { "template" : "basic-page", "parent" : "/about/", "title" : "New Page created through api", "name" : "newapipage" } Be careful that you have a well formed string here. Otherwise you will get errors. Paste this into the "Body" panel of the REST Client addon. Hit send. In the Response Headers tab you should see a Status Code 200 and in the Response Body tabs a JSON string "{"success":"Page created successfully","url":"https:\/\/mysite.dev\/api\/pages\/1019"}". Now go to the PW backend and check if title and name of your page have been updated. If yes, you're awesome! Summary By now you have learned how to build a simple REST API with ProcessWire for exchanging data with mobile devices or other websites. Notes I tested this on a fresh PW 2.7.2 stable install with the minimal site profile and can confirm the code is working. If you experience any difficulties in getting this to work for you, let me know and I will try to help. There purposely is quite a lot of repetion in the example code to make it easier to digest. In real life code you might not want to use procedural coding style but rather separate repeating logic out into classes/methods. Also, in life applications you should do more sanity checks for the authentication of clients with the API / for the data that is delivered by the client requests and more solid error handling. I skipped these to make the code shorter. RESTful services are by definition stateless (sessionless). My implementation within PW still opens a new session for each request and I haven't found a way around that yet. If anyone can help out this would be much appreciated. And finally big thanks to clsource for putting the Rest.php classes together. pages.php.zip

We have a few PW sites and plan to increase this number. I'm looking for a multiple site monitoring tool similar to https://managewp.com/ where you can see a snapshot of all of your sites, the versions of the core, modules etc and also a way to update them centrally? ManageWP also handles malware scanning, database optimisation. Is there anything available for PW? Thanks Pete

Modalception for ProcessWire GitHub: https://github.com/thetuningspoon/AdminModalception Direct Download: https://github.com/thetuningspoon/AdminModalception/archive/master.zip Modalception improves the usability of ProcessWire's modal dialog/popup windows when opened from within another modal window. The parent window is expanded to take up the full screen behind it so that additional modals can be opened without the inner windows becoming progressively smaller and less usable. The outer windows' toolbars are hidden from the user to help reduce confusion. * Screencap also features the Page Field Edit Links module

Hi, Here is our web site done in ProcessWire: http://gsbelarus.com/pw/en/ Background image will change with every page reload, so use Refresh to view all gallery.

Is the name of the module HappyClasses or DynamicCSSClasses? Congrats on your first module.

It is now working. After trying everything I could think of I started over. Re-installed pw. Previously I had exported a profile from my server and imported that, this time I used the blank site profile and manually added all the fields. Not sure what was wrong, but it is working now.

Yes, all these points would mean creating a monster. In terms of database backups or malware scans, those are highly platform specific and not something easily implemented in a module. A centralized overview actually makes sense to me. Showing.PW and module versions and outputting some statistical information is also quite doable. Displaying a momentary status can be done, but continuous monitoring is not something that you can build on top of PW - for this, you'd need to add some layers under or next to it. I've started tweaking together a set of modules that could serve as a base. I'll try to add the necessary hooks to allow extending it tomorrow and put an alpha release on github. If nothing else, it's an interesting conceptual challenge

I would suggest to split this. In my opinion, all the points except 4 can be in the backend. For 4.) there are dedicated monitoring tools which measure exactly this: availability, load, status of services, memory consumption, … you name it. This again can be made available by API. Besides, you should _always_ be able to update. ALWAYS. Whether you feel you need it or not. One day there might be a breach no one saw coming and you do want to be able to install the newest version in the least time possible. So in your own interest, always update, always make your modules update-friendly, and always keep your hands of fiddling around in the core.

You should take a look at Soma's great gist about building frontend forms from fields of a template (or page). This code also pulls in all the dependencies you need for asm page fields, image fields etc. It also takes care of server side form validation. Only thing you need to add is sanitation of the form values. I have used this code as a base for several frontend forms (even complex ones) and it is working great.

You should set dutch as the default language in the backend to avoid those kind of problems. Or you can use a hook before page save to automatically populate the default language (english) fields with the value from the dutch fields.

Hi adrianmak, here's a good read: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Markup/MarkupAdminDataTable/MarkupAdminDataTable.module It's not that don't want to fish and cook for you, but fishing your self will give you more experience.

Three underscores make them hookable.

Hi James - welcome to PW, and to the forums. Have you perhaps had a look at this support article: https://www.hoststar.ch/en/node/2613 ?

Yes. It works with Processwire 2.7 and with the dev version 3.

The automatic page creation must be setup in the module config, otherwise the module cannot know which page it should create where. 'page' => array( 'name' => 'guest-book', 'parent' => '', 'title' => 'Guest Book' )

While I agree with earlier posters about not needing to update PW installations, honestly I agree more with teppo - I want older customers to reap the benefits of improved admin functionality. And course we are not just talking about the PW core here - there are also often 3rd party module updates - sure these updates might just add new functionality and there is always the chance that they might break something, but if you do your due diligence in checking the revised versions, it is nice to be able to update across all your sites at once. I actually had/have some plans to build something like this - but am waiting to see if the demand is going to be there. Module Toolkit is something I use in the meantime for updating all 3rd party modules on a site at once - it can be a significant time saver. But be aware that this module is currently alpha/early beta - I would like to get back to it and release it properly, but juggling priorities as usual

Make the pages not viewable for anyone (except superuser) and use the module permission system to limit view access of your dashboard module separately.

If you save your pages under the Admin section in the Page list, isn't that OK to you?

I'm pretty new to PW but have 15 years Joomla and Wordpress experience and have watched those platforms expand to a point where you need a good tool to centralise maintenance. Having no known security issues and therefore no reason to apply updates seems a little cavalier. Unless you're looking to keep backwards compatibility I would always think you're best to apply an update when it comes out? Not knowing PW that well, I could have this wrong though - please don't flame me

Hi, I read the blog articles and many planned improvements and new features. At the moment I do some tests with devns branch and maybe switch over to it. ProcessWire's front-end framework (for the admin) I like the PW backend. It shouldn't be more complex or slower. Simplify it and maybe reduce dependencies (jQueryUI?) to make it faster. If modules like inputfields (frontend file uploads), login (swap out backend admin messages), .... will be modified it would be great to keep frontend usage in mind. I know that isn't the PW intention, but it would be great to reuse login module, form api... Other systems deliver "basic modules" like login, register while developers have to write custom code or use 3rd party modules. I like to write my own modules and learn more about PW, but more stable frontend useable modules (= existing core modules used in the backend) would make PW more attractive for new users and could increase the community.

Multi instance support is planed for 3.0 but it's not ready to be tried out yet.

Hey, this is the exact use case why I made the http://modules.processwire.com/modules/process-field-generator/ module. It will generate crypto safe strings to use as page names (you don't have to expose the page id, especially with the combined use of urlSegments as a view handler).

Since I've been working on a few projects where I used Bootstrap 3 and will be using it for future projects, I put together a blank site profile with Bootstrap 3 Sass, Fontawesome and a few markup render functions for Bootstrap dropdown menu, image carousel and accordion. You can find it at https://github.com/gebeer/site-pwbs Features bootstrap-sass-official font-awesome SASS version jquery modernizr render functions for:BS3 dropdown menu BS3 accordion from PageArray BS3 carousel from PW images array Prerequisites compass bower How to install from zip: download the zip extract the folder "site-pwbs" into a clean ProcessWire install's root folder during install of ProcessWire choose the profile "bootstrap-sass-official fontawesome blank profile" After installation The last step after installing the profile is to install all assets with bower: open a terminal in site/templates and execute "bower install" How it works The profile is based on the blank site profile that comes with PW 2.5 and uses the delegate template approach. It comes with a top navbar, a main container and a footer section. Rest is up to you. CSS gets compiled through compass. You can easily override BS variables and exclude BS components that you don't need. I intentionally did not add structure to the sass folder so you can structure your partials yourself as you please. There is only one folder "generic" with _mixins.scss whith a very lean and flexible breakpoint mixin that I discovered here. JS Since I only use the BS javascript plugins I really need, I usually copy them over to my plugins.js file. I use bower to install bootstrap-sass-original and fontawesome because it gives more flexibility than requiring them through ruby gems. This way you can tweak the BS and FA partials to your liking (of course only if you don't intend to do "bower update" further down the road) Enjoy!

Thanks from me as well. These lines in my template file plus adding alt to the img tags in the theme made my good friend the W3C validator happy. $options = array('title' => str_replace(' ', '%20', html_entity_decode($page->headline))); $soc = str_replace('&', '&', $modules->MarkupSocialShareButtons->render($options));

Feasibly it's possible, but it's not desirable. Making wire('var') aware of context involves pre-compiling the template files to replace wire('var') with wire($this, 'var'). So it's something we do to provide backwards compatibility in template files. We won't be providing that backwards compatibility outside of template files, so people will have to use $this->var, $this->wire('var') or wire($this, 'var'); elsewhere. Also, a Static::syntax implies dealing with a framework that only has one context, which gives the appearance of a weakness that isn't there, something I think we'd want to avoid. While I'd really like to limit statics in ProcessWire as much as possible (just because they are more than often a bad programming practice), that syntax is perfectly fine for static functions where context doesn't matter or where you are passing the context into it. For example, $sanitizer functions would not need to have different behavior in different contexts. I've even seen some frameworks that do use statics for sanitization functions as well. In the end though, IMO they would still be better served by providing the same functions non-statically. The plan is that when you do this... $main = new ProcessWire('/site/'); $intranet = new ProcessWire('/site-intranet/'); ...everything in each of those two instances will be unique to those instances and whatever site files are stored in /site/ or /site-intranet/. That means that when a module is initialized, it is only initialized for the instance (whether main or intranet). When a module refers to $this->var, it's referring to API variables that are part of its instance only. This enables you to have multiple sites talking to each other. Currently this isn't possible precisely because PW uses statics for API variables behind the scenes. But the fact that we've kept that behind the scenes is a good thing because that means it doesn't matter how our API variables are stored. We can switch them to a stronger storage mechanism that would be tied to an instance. This is one reason why I deprecated the Wire::getFuel() syntax (that appeared in early versions of PW2) early-on... though you might still see it appear in a few core spots, which will need to be changed. But we've really tried to keep the public API clear of static calls so that the API would not have to change as PW continues to grow as a framework.

OMG, Ryan! Then I need for sure a seat belt at the office chair, avoiding liftoff.