Leaderboard

You can detect whether the current page was loaded from ajax by checking the value of $config->ajax from your template file: <?php if($config->ajax) { // page was requested from ajax } Following that, you will likely want to render the page differently to accommodate whatever you are doing from the javascript side. For instance, you might want do one of these: 1. Deliver alternate or reduced markup when loaded from ajax 2. Deliver a JSON or XML string for parsing from javascript Below are examples of each of these scenarios. 1. Deliver alternate or reduced markup when loaded from ajax You might find checking for ajax helpful when you want portions of pages to load in your site without re-rendering the entire page for each request. As a simple example, we'll use the default ProcessWire site and make it repopulate it's #bodycopy area when you click a page in the top navigation. (To use this example, you'll need the default ProcessWire site templates, though you can easily adapt the example to another situation.) To accomplish this, we'll update our main page template to only include the header and footer markup if the page is NOT being loaded from ajax: /site/templates/page.php <?php if(!$config->ajax) include("./head.inc"); echo $page->body; if(!$config->ajax) include("./foot.inc"); Next we'll update the top navigation to do ajax loads of the pages when the client has javascript (and leave as-is when they don't). Paste this javascript snippet before the closing </head> tag in the header markup file: /site/templates/head.inc: <script type="text/javascript"> $(document).ready(function() { $("#topnav a").click(function() { $("#topnav a.on").removeClass('on'); // unhighlight selected nav item... $(this).addClass('on'); // ...and highlight new nav item $("#bodycopy").html("<p>Loading...</p>"); $.get($(this).attr('href'), function(data) { $("#bodycopy").html(data); }); return false; }); }); </script> Now when you click on any page in the top navigation, it pops into the bodycopy area without a page load visible from your browser. And all pages remain accessible from their URL as well. Note that this is just a test scenario, and I probably wouldn't use this approach for the entire bodycopy area on a production site (it would make bookmarking difficult). But this approach can be very useful in the right places. 2. Deliver a JSON or XML string for parsing from javascript Lets say that you want pages in your site to return a JSON string with the page's id, title, and number of children when it is requested from ajax. When not requested from ajax, they will return their content as normal. To handle the ajax requests, you'd want to add something like this at the top of your template file before any other output. <?php if($config->ajax) { // this is an ajax request, return basic page information in a JSON string $json = array( 'id' => $page->id, 'title' => $page->title, 'numChildren' => $page->numChildren ); echo json_encode($json); return; } // not ajax, continue with regular page output And here is some markup and inline javascript you might use to test the ajax call on some other page (or the same one if you prefer). You would paste this snippet right in your site's markup where you want that info to appear. <ul id='info'></ul> <script type='text/javascript'> var url = '/'; // this is homepage, so replace '/' with page URL you want to load JSON from $(document).ready(function() { $.getJSON(url, function(data) { $.each(data, function(key, value) { $("#info").append("<li>" + key + ": " + value + "</li>"); }); }); }); </script> The above snippet would output something like this: • id: 1 • title: Home • numChildren: 5 To take this example further, you could build an ajax-driven sitemap or any number of web services. Conclusion Hope this helps you to see how simple it is to use ProcessWire to deliver output for ajax. These are just contrived examples, but hopefully examples that might lead to more ideas. In addition, much of what you see in these examples is also applicable to building web services in ProcessWire.

I'd like to share and discuss some things I've come across maintaining the German translation. Ryan has outlined a way to get the translatable files in PW: http://processwire.c...__20#entry11232 — while this does work, it's not very comfortable. It would make translations much easier if there was a way to get those in the backend, as well as maybe detect which translatable files are new or abandoned. For instance, I think InputfieldRadiobuttons just got moved to a separate directory, making the previous translation file uneditable. I think it would also be good to have different "states" for empty fields in translations. As of now, "empty" could mean "not translated yet" as well as "doesn't require translation, can fall back to English value". Updating a translation would be easier if one could just skip the values which don't need to be translated, but obviously, this would be nice to have. It's definitely not a must-have. Which brings up the question as to when to actually update a translation. Obviously, doing that constantly as changes are committed to GitHub is insane. So it would make sense to update translations based on a release. As far as I have followed PW development, there is no alpha/beta stage, right? It would be nice to have some phase before a release where nothing new is added so translations could be updated to be ready along with a new release. Another thought: Let's say I install a translation for PW 2.3 in a PW 2.2 installation (or vice versa). Are there going to be any "side effects"? Should we maintain versions of the translations for specific PW releases? Most pressing issue in my humble opinion: currently (as far as I can see, please correct me if I'm wrong), there's no "protection" for additional translations added. Let's say I install a translation, then I add some translations of my own, maybe related to the templates of the site or some help texts in the descriptions of fields. Then I update PW and the updated installation. In that case, all my additional translations will be overwritten by the updated translation, right? If so, there should at least be a way to backup the additional translations, although I figure this could be hard to implement given the JSON format of the translations. Oh boy. Sorry for rambling here, I hope this makes some sense.

Ok, I got a little time and did it myself Please go there and change it as you wish. http://toolbe.lt/Processwire

I'm not angry just lazy

Ryan pointed to a good solution here. Edit: Soma, as always you're first

You can also do this in newer versions of PW: $newpage->template = 'upload'; $newpage->parent = '/uploader-test/'; I suggest sanitizing the title, and excluding the name (since PW will autogen it from the title). So the above code would be replaced with this: $newpage->title = $sanitizer->text($input->post->title); Here is the current PW implementation for uploaded files. Perhaps there is a way we can populate this to $input->files, but currently I think it's best to be more specific when it comes to file uploads since there are added dangers and overhead. The WireUpload class does make things simpler and more secure. It also provides options for handling known quantities, filename sanitization, overwriting vs. making unique filenames, processing ZIP files, handling ajax uploads, etc. The full class is in /wire/core/WireUpload.php