Leaderboard

CMS critic is one website and not even a very popular one. It has done great stuff promoting PW (and many other systems out there), but it is very small amount of visibility. ProcessWire is steadily pushing forward, but it is true that some systems did get more popular in much faster - especially craft. See this https://trends.google.co.uk/trends/explore?date=all&q=processwire,craft cms (I believe they did get most users from dying Expression Engine community where they were popular plugin authors). I think ProcessWire is "old dog" now for most - it isn't "new and interesting" anymore, so all kind of marketing "gimmicks" should be used. New features should be promoted much more (videos, tutorials, blog posts etc). Ryan is doing most of the development, weekly posts and supporting his paid modules, so this is something where community - all of us - could help. Also I believe that this website, docs, tutorials etc are those parts of this project that can be most easily delegated to community. Another one is having official starter themes (site profiles) and admin theme. We have amazing amount of design and development talent here, I wish we could collaborate more easily. We all know Ryan is busy, so do not wait for green light and guidance - if you feel like you could do something for our community - just build it and share it! More people will pick interest and great things will happen!

Personally I have the impression it's growing at a slow but steady pace. And though slow and steady is much better than fast and sloppy, it's a bit frustrating to see other platforms seeming to get more attention while being notoriously inferior. I like following CMS Critic's Awards. PW has got a bunch of exposure there, but this year it's only nominated for "Best for SMEs" alongside Craft and ModX, both paid platforms. I'm guessing Craft will get that one because it looks polished and very DIY, and PW is too "pro" for that category. Then there's "Best free CMS". PW is not there. You see the usual Joomla and Wordpress there, along with CMS Made Simple. That one just trying out the demo makes me cringe. It's so 2001 that I can't take it seriously. Now I've never used Joomla, but I constantly compare PW with Wordpress and can't comprehend how Wordpress still holds on to such a large chunk of the market. "Best Open Source CMS". CMS Made Simple, ModX, Silverstripe. So I went to see what Silverstripe is all about. Now SS looks to use a somewhat similar approach to PW, and though it looks relatively polished, it doesn't feel as mature to me. So we've got PW in one category this year, and the wrong one. To me that feels like a loss, which will reflect another dip in that Google Trends chart over the next year. The next version will be an important step. Updating the default theme of the CMS is a must. I'm guessing most people now immediately install Reno's theme the second they enter the CMS after installing. So a new version with a new look will attract attention and that will hopefully pull it up a bit more. If we want it to grow faster (an argument can be made whether that would be good or not), it's mostly a matter of getting more people to try it out. After getting the first project running, it's hard not to be hooked. On an end note, I think it's time we start considering a refresh on the website. Just saying.

@psy - That's on my wishlist too ;-) Yes, I'll definitely implement this.

I wish, I wish... ProcessWire had loooooots of @ryans behind it. As it stands, we all depend on him. As long as he is with us, all is good though...

One of the easier ways to tell is to search Google Trends https://trends.google.co.uk/trends/explore?date=all&q=processwire Mod note: Hi all, The original poster was a spammer. He's been banned. The forum software has automatically promoted @Peter Knight as the new OP .

embarrassed to admit that after some thorough digging, I found if($page->template = 'pageGeo'){ instead of with == which was messing up everything.

That's an important point. Pixel & Tonic were already the developers of several of EEs most crucial extras and presumably had thousands of EE users on their database. When they started Craft they not only had a ready to go marketing list of people who were A) fed up with EEs development but also fans of Pixel and Tonic too. I wont go into details of how they announced Craft at an Expression Engine conference ? Anyway their climb to fame is well deserved but a little unnatural Vs how most CMS grow their profile.

I think a comprehensive doc would help greatly with new users or people on the fence. I know this has been discussed to death, but one place for the api/cheatsheet/tutorials with snippets/starting points would give first time users a confidence boost. I feel like I spend hours (if my project is large) googling and jumping between the references. It can be a bit disheartening at time. With all that being said, it doesn't seem to be "as bad" as when I was first starting out as I now have a better grasp on functions/the flow of PW. I have started moving away from granting access to the backend for in house projects, and instead, building "backends" on top of PW for them to use. I found it easier to give them only what they need to see than to have them getting scared of the page tree. I understand that PW is pretty much open ended and is only limited by your imagination, but maybe (dare I say) a template with the barebones for a dashboard/backend (perhaps with some ajax) built on top of PW could be helpful as well for new users. I know I still struggle with working ajax into projects and making something flashy, and examples always help (like live page listing refreshes etc). Understandably, this couldn't be a one size fits all, but it would be a great jumping off point for the newly initiated and make it more comfortable when granting access to the client or whomever the project is intended (Only intended if that workflow suites the project I know). The backend isn't such a scary place, but to whomever doesn't need all of the tree, could be nice. Well, I will end my ramblings, but thought I would throw my 2 cents out there.

I think a theme refresh for the admin would make a big difference. Problem I have is I don't know how I'm gonna convince clients that PW is a better choice than WP. As in, off the top of my head: 1) They know WP, everyone talks about it, their mum told them it's amazing! 2) Themes. 3) When you leave, who's gonna take over their PW site long term? 4) They want extra functionality, you can't do it for whatever reason, who can? 5) I like the simplicity of the hierarchical tree in PW. So far, my clients have been a little confused because of hidden/unpublished pages. They think everything in the tree is on the site to view. In fairness, I may have missed a setting that makes these actually hidden from clients. For example, one page that needed to be in the tree, but also hidden (to stop it being in the main menu) was a settings template. Client needed access to it, but it had to remain hidden. 6) Loads of plugins (whether good or bad, the client knows they're available). And they haven't looked into how they are coded, and why would they? They think they can simply install it and get going (although the truth differs somewhat). 7) Images/docs uploaded per page, not centrally. I've never liked this so much, however there is a paid module for media. If there is a file download on two different pages, this is awkward for the user. They can't just open 'all docs' or something and just sling it in. 8) They think WP is free, as in, downtime after being hacked, decent plugins are paid, you need plugins to do things a proper CMS just has as standard... not so free really. Now I've really liked PW from the get go, but in reality, I can't see how I can avoid learning WP too. Literally all the web design jobs round here list the same requirements, HTML, PHP, CSS, JS/jQuery, Wordpress. I've spent a fair bit of time with PW and this really irks me. --EDIT-- So I just looked up how to make some basic custom fields, post types and custom menus in WP as a refresher. It made me sad. And made me think twice about going down that road.

That's one +1 vote That would explain it - now to figure out how to fix it. Ideally it would be good if libraries included in PW modules were excluded from the Captain Hook search (since there obviously won't be any hookable methods in them), but not sure there is a foolproof way to do that. I think an easy fix (which should work in most cases) is to do an initial check for "___" in the file before scanning fully. This will only fail if a vendor library also uses the three underscore method prefix approach. I'll try this and see how we go. It's actually a nice speed improvement for the panel (when not cached), so a good thing to do regardless. Please try the latest version, remembering to clear the cache, and let me know how it goes for you.

would be nice to have in tracy we got closer! deleted the cache and the error appeared again. last file seems to be /site/modules/RockMpdf/mpdf6/vendor/mpdf/mpdf/mpdf.php - this file has 1,1MB

Soma's module already includes it - it finds all WireCache caches automatically - note "TracyCaptainHook" at the bottom. I am tempted to incorporate the features from his module into Tracy - it seems like an appropriate feature to have and I do like having less modules to install/update. I'll have a think on it for a bit! Anyone else have any strong feelings on this?

I just forked the module and added support for repeaters (only on the multi select inputfield for now); it basically involves 2 steps - changing the module code to use mostly the renderReady method instead of render(), and then some small update to the js file to init the field on the necessary events, which for the sake of brevity also involves moving the init code into its own function var... I submitted a pull request; in the meantime if you need this to work now, you can try the forked version https://github.com/outflux3/InputfieldChosenSelect

Wishlist/request... would love to see on a per page/template basis a sitemap priority field. When no priority is specified, Google goes 'top page - 100%', 'sub page - 80%', 'sub-sub-page - 60%'. In reality however, the 'sub-page' is often the parent page in the menu. The 'sub-sub-page' has the guts & glory that you want indexed with a high priority. Google doesn't guarantee but says it will give a sub-sub-page with a priority eg of 80% a higher priority than it's root parent with a priority of 60%. https://www.sitemaps.org/protocol.html

sorry no memory issue any more is there some caching that i can reset? i had to decrease it to 16MB to get the error... thanks, works!

Here's a primer on what hooks are and how to use them: https://processwire.com/api/hooks/. They're essentially a way to add custom functionality within processwire's workflows.

@PWaddict - Thanks! I totally missed out on the actual requirements there. Will work on fixes based on your code soon. Note sure why some of those pages are being ignored as I didn't experience that myself... Will look into it. @maxf5 - After fixes, the module will create a language ISO field and automatically add it to the language template.

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

I've just upgraded the forums due to an important security patch being released. There was a bit of a dilemma in that the forum upgrade was guaranteed to break the theme that blended the forum software into the rest of the site design as it was a fairly major release that contained the fix. I chose to upgrade the forums anyway as the security issue was big enough to warrant a little discomfort in the short-term. Please bear with me over the next 24 hours as I get things looking back to normal again.

One trick is to do this instead... if('pageGeo' == $page->template) If you mistyped that as: if('pageGeo' = $page->template)// syntax error // OR even if(1 = $page->id)// syntax error PHP will throw a Parse Error: syntax error, unexpected '=' , immediately alerting you of your mistake .

Great, thanks for letting me know. I just committed another update which fixes the issues you were having with the Captain Hook cache not automatically clearing when upgrading Tracy. It will now clear when you upgrade, install, or uninstall any modules, click the modules > refresh button, or change PW core versions. Also, uninstalled (but not deleted) modules will no longer have their hooks shown.

Would be great if @ryan could/would attend a conference and talk about PW. Or even someone else and work with ryan on the speech.

hi roland and welcome to the forum, i read your other posts and i also see two options: 1) if you WANT to learn and are not afraid of writing some code you'll always find someone here that is willing to help 2) if you want a quick solution and stay in your (i quote you here and mean it bad in no way) "wordpress click click and boom ready" - world I'm sure you find a developer in the job-board that can help you

We are using it on one ProcessWire install which is used heavily. We have around 20 Decimal fields with over 200k+ pages with all kinds of automated calculations (thanks @Martijn Geerts). Still working fine ... I haven't tried it on other installs, so I would really like to see @sforsman giving his blessing. You might want to test it out yourself. If it works for you I can cover the maintenance, no worries.

Welcome to the forums @kalimati Ha! It's the project I'm working on currently . So, hopefully soon. Meanwhile, there's also this module.

Then your in the wrong place. PW doesn't work that way, PW doesn't have a frontend by default like other cms*, you have to build the frontend yourself. * it does if you use a site profile but those are mostly to showcase some features To understand pages read this https://www.smashingmagazine.com/2016/07/the-aesthetic-of-non-opinionated-content-management-a-beginners-guide-to-processwire/#three-simple-core-concepts https://processwire.com/docs/tutorials/but-what-if-i-dont-know-how-to-code/part-1-pages-templates-fields-files/

Maybe @ryan can "share jobs" to the community much more that we can help. I think these points are outdated and had to be done first: a) default admin theme - it will pay more attention to people who are making the first steps into PW b) new branding/ci for PW. these identity now with the skyscrapers on facebook is looking so 90ties.. c) like @apeisa said, a new stylish/modern PW website. A powerful start-page showing the features. ( of course also updated docs, tuts,..) thinking of a clean design like pagekit ( https://pagekit.com )

seems to work, thanks not cached: cached:

Cool, good to know, thanks! I have not yet tried TracyCaptainHook – to tell the truth – so I guess that is why I did not notice it. Thanks. It might be useful to have it as a separate module but I do not think editors should use it, so probably it is a good fit for Tracy. Let's see what others say.

MODX isn't paid. I was surprised to see it listed though as it's last big update was 2014-ish and is suffering as a result. Corresponding 5 year Google Trends chart attached.

Do not forget that WordPress is click-and-play and can be easily pimped by googling around the web and pasting some hooks into functions.php. You can't beat that! WordPress is not even a CMS, by the way it is a blog engine with a nice GUI.

Just an idea: could you please implement it in @Soma'Clear Cache Admin and create a pull request for it? You might also want to pull up your sleeves and try to persuade him to register it in the Modules Directory Or you might just want to integrate his module into Tracy? (At least its features.) I hope I'm not asking for too much. Thanks for all your great community service as always!!!

The Captain Hook cache should be reset when you update any modules (including Tracy), or the PW core, so it should already be taken care of, but just in case, go to the database "caches" table and delete the "TracyCaptainHook" row. Great!

Google Trends monitors search queries entered into it's own search engine. It's like a stripped down version of their keyword tool for Adwords where they can tell you that.

It's hard to tell just by taking a closer look at the forum or github because a lot of developers hardly ever post anything there nor they register at the forum. A better indicator would be some statistics on PW's downloads. If it grows, the platform grows too, I guess. At least this could be a useful conclusion even if it is a basic one Hm, it is always hard to tell what search engines are actually "measuring", but it is better then nothing, I think

Yeah, I agree it's really weird - I just decided to show the link as a raw URL instead!

Here is a related very good post I keep recommending from time to time.

Wrapping up the fieldset trilogy comes part 3: Fieldset Group, which is now released. In the post we take a closer look at it and compare it to the other fieldset types. Then we wrap up with some hints about more coming up in the weeks ahead. https://processwire.com/blog/posts/fieldsetgroup-module-released/

You're running into PHP scope issues. You will need to use: $this->wire('user')->name; Same goes for $pages - use: $this->wire('pages')->findOne .......

Hey @bernhard - I took another look at the $wire variable not being available in ready.php (and init.php / finished.php) and this has been fixed in the latest version. Please confirm it all works at your end please.

Here are two ways: <?php namespace ProcessWire; /** @var $pages Pages */ $posts = $pages->find('template=post, sort=-published'); $latest = $posts->shift(); // removes first item off of $posts ?> <ul class="post-list"> <li class="item--latest item"> <?= $latest->title ?> </li> <?php if ($posts->count): ?> <?php foreach ($posts as $i => $p): ?> <?php $itemClass = ($i % 3 == 0) ? "item--hoverable" : ''; ?> <li class="<?= $itemClass ?> item"><?= $p->title ?></li> <?php endforeach; ?> <?php endif; ?> </ul> <!-- OR --> <?php if ($posts->count): ?> <ul class="post-list"> <?php foreach ($posts as $i => $post): ?> <?php if ($i === 0): // LATEST POST ?> <li class="item--latest item"> Latest: <?= $post->title ?> </li> <?php elseif ($i === 1): // BASIC ?> <li class="item--basic item"> Basic: <?= $post->title ?> </li> <?php elseif ($i % 3 === 0): // HOVERABLE ?> <li class="item--hoverable item"> Hover Me: <?= $post->title ?> </li> <?php endif; ?> <?php endforeach; ?> </ul> <?php else: ?> <p>No posts found</p> <?php endif; ?>

I think the two modules should be merged, as they both serve module specific tasks.

You can do this with EMO too: At module settings page set "Obfuscation mode" to "Obfuscate manually..." (OR adjust exclude/include templates/pages settings to have auto obfuscation enabled only where needed). Then on a page template obfuscate only the parts of markup you want by using $sanitizer->emo() method. // obfuscate single email address echo $sanitizer->emo('hello@world.com'); // obfuscate email addresses from a body field output echo $sanitizer->emo($page->body); Also make sure that you are using the 1.1.x version since this feature was added to the latest release (1.1.0).

Thank you very much! EDIT: Works like a charm!

I'm using this function in places, seems to work well: /** * Given an email address render the obfuscated version * * @param $strEmail - an email address * */ function createMailto($strEmail) { $strNewAddress = ''; for($intCounter = 0; $intCounter < strlen($strEmail); $intCounter++){ $strNewAddress .= "&#" . ord(substr($strEmail,$intCounter,1)) . ";"; } $arrEmail = explode("&#64;", $strNewAddress); $strTag = "<script type='text/javascript'>\n"; $strTag .= "<!--\n"; $strTag .= "document.write('<a href=\"mai');\n"; $strTag .= "document.write('lto');\n"; $strTag .= "document.write(':" . $arrEmail[0] . "');\n"; $strTag .= "document.write('@');\n"; $strTag .= "document.write('" . $arrEmail[1] . "\">');\n"; $strTag .= "document.write('" . $arrEmail[0] . "');\n"; $strTag .= "document.write('@');\n"; $strTag .= "document.write('" . $arrEmail[1] . "<\/a>');\n"; $strTag .= "// -->\n"; $strTag .= "</script><noscript>" . $arrEmail[0] . " at \n"; $strTag .= str_replace("&#46;"," dot ",$arrEmail[1]) . "</noscript>"; return $strTag; } also works well in a hanna code, and doesn't require any additional js files

For those people who cannot get this to work in PW3, the instructions say to put this in your head: <script type='text/javascript' src='https://maps.googleapis.com/maps/api/js?sensor=false'></script> This actually needs to be: <script src="https://maps.googleapis.com/maps/api/js?key=<?= $modules->get('FieldtypeMapMarker')->get('googleApiKey') ?>"></script> Or however you like to include your JS files. The sensor=false is no longer needed, but the API key is. Seemed to work for me, I havent had time to investigate the inner workings of the module to see if this should be done or not but is just a bug. Happy mapping.

The use statement does nothing in you snippet. If you want to use "use", then like this: <?php namespace ProcessWire; use DateTime; $date = new DateTime();

Try: new \DateTime($enddate);

Since I recognized a remarkable overflow of my trash bin I made a small module which auto delete pages sustainably from the trash after a period which can be set in module settings. PW modules: http://modules.processwire.com/modules/cronjob-empty-trash/ Github: https://github.com/kixe/CronjobEmptyTrash

Yet another new rich text editor I came across today - Trumbowyg.