Leaderboard

Hi all, Here's a preview of a Gallery photo album module I am working on (very slowly! ). Development is currently in closed beta testing. The module will consist of a backend (as seen on video below) and a frontend that is framework and lightbox agnostic, aka plugin whatever and it will still work. Features Unlimited number of albums and sub-albums (easy to query using PW API) Multiple methods to add albums and photos (including uploading images and zip files, scanning a folder for FTP'ed photos, etc) Automatic album and photo creation based on names of folders and files respectively Bulk editing (moving, deleting, tagging, etc) Manager themes in several colours A bit of eye candy Etc... This is in beta so it is still rough around the edges. Feature suggestions? Yes please Apologies the video is way too long and you might get bored toward the end...

Dear All, If one defines "Enterprise" as an environment of mission-critical websites that make money for a corporation, then I am already using ProcessWire in that fashion. My day job is as a Web Director for a New York magazine publisher that owns around fifty+ magazines. We have over 25 Linux and Windows servers, which I manage. I also write custom web database applications for the company, and recently wrote a "Web Help Ticket System" using ProcessWire. The ticket system receives its initial input via email, which gets piped to a PHP script, parsed, and then input into the ProcessWire help database. The script then emails the responses to various individuals that are in the database. I've created a front-end staff interface, with usernames and passwords, that displays the tickets and allows editing, searching etc. It's been running for a number of months, with tickets sent in from Editors, etc. So far, it's proven to be very robust. This is just one example of what I would call an Enterprise level web application, built using ProcessWire as the CMF. Of course, someone else may define it differently. I want to note that I had initially looked at Drupal for this purpose. I'm not yet a "Drupal developer" -- I just haven't spent enough time with it. But after spending *some* time with Drupal, and after seeing that many magazine sites that use Drupal seem over-heavy and bloated, I have to say that ProcessWire is lean and mean and fast and a complete joy to work with. It does have a learning curve, but I think it's less than Drupal's learning curve. (That would be a good survey.) I say that because once you wrap your head around PW's method of one data table per field and its "virtual data tables" (aka templates or field sets), then it becomes a piece of cake to use the API and PHP as the template language. The sky's the limit in terms of ProcessWire's power and flexibility. PW might seem arcane at first, but I don't really think it is, except for the table structure, and that ends up making sense after one digests it. I also built a complex, formula-based business app with PW, at http://thepivotstartup.com (in the members section). It allows entrepreneurs to plug in numbers about their business ideas and vet them, to see if they might work in the real world. Finally, I use ProcessWire as my own CMS, at http://significatojournal.com. My wife, who is a writer, but non-technical, does most of the article posting, using PW's admin back end. She finds it very simple to use. I don't need ProCache yet, but when I do, it seems to me to be a brilliant caching mechanism, since it dynamically writes each generated page to flat HTML files, and then uses clever .htaccess rules to serve them up. Because of all of the above, I would recommend ProcessWire for mega websites, and in fact, if it was "my do", I would build and/or convert many of the magazine sites that I manage in my day job to ProcessWire. I'm completely confident that PW would do as good a job as WordPress and Drupal, which the company currently uses. I believe that the reason that PW hasn't been adopted in the enterprise isn't support, but rather the lack of market share, mind-share, and enough usage for Big-Iron websites to prove to companies that they'll be safe using PW. I don't think Enterprise support is really the issue. We had one CMS, called "Nstein" and another called "Ekron" that both had expensive support packages. We left both behind with great sighs of relief. We use Drupal, WordPress and DotNetNuke, without any support contracts. All that matters is the confidence that: a) we can find developers who use it, and b) there are enough examples of high-powered, high-volume, Big-Iron sites that use it successfully. I think "B" is the real kicker. I read a Fast Company article about Drupal serving up hundreds of thousands of pages, and then recommended it to our VP. But, I wish PW had been around back then. That's the PW challenge, I think. Convince some VERY high-level, well know companies to make huge, heavily trafficked websites with PW, and then other folks will say, "Hey! Look at that! Let's use ProcessWire!" And then it shall be done. Peter

Hey, this is a piece of wood, but you have to be a carpenter to build a table from it ... So what? I think argos' comment puts a spotlight on how the CMS market divides into two sections: one for - more or less - out-of-the-box solutions and one for more elaborated pieces of work, which require some skills. There is nothing wrong with the demand for out-of-the-box solutions, but PW definitely addresses another market segment. Why should this be wrong or change?

@argos - there are many, many people who have learned it and understood it here that did not consider themselves programmers to begin with, so I think it all depends on every person's ability to grasp new concepts or languages and as human beings we'll all have different experiences there. However saying all of those things in your posts because you personally didn't get into it seems a little unfair. It's not for people who want to plug it in and go - it's for people who want to learn at least some of the basics of web development. As you say there are plenty of other systems out there for various needs, but just last night with a few choice fieldtypes and a bunch of templates I built the structure of a site that would have either been impossible in another CMS or taken me weeks of wrestling/coding. It took me 3 hours and not a single line of code was touched and the end result is a really nice page structure with intuitive templates for entering the data. The code will come in the frontend templates, but the backend is all the client should ever have to worry about. I would be very interested to know what could be done to improve the many documents and tutorials to better help people getting stuck, but I very much doubt the coding aspect can be made any simpler - it's already simpler than working with databases directly, so I can only imagine more tutorials might be the answer?

Impressive and an a fantastic example of what can be done with Process modules to make a completely customized backend. I predict your name will be lit up in flaming ruby red lights this Saturday

Looks like you've enable caching.

Love that line. Argos, not being a developer, you are not the only one who got stuck in the way you described when you started with PW. It happened to me and I have seen it happening with other starters posting about it in the forum. And you know why ? If I look back now on when I first started with processwire, it is only for not having seen in the beginning enough examples of how to rebuild, redesign, recode the template and css that comes with a standard processwire installation => into another completely different new website. You see, coming from wordpress, joomla, modx, etc. etc. etc, you are used to a certain way of doing things, workflow, thinking, etc. With processwire you have to put most of that out of your head and start looking at things differently with a new way of thinking. Not easy I admit. That is because processwire gives you so much freedom to do things it becomes a blind spot for a none developer where to start. It is your very old way of cms thinking that makes you think everything in processwire is complex and makes you frustrated. It clearly shows how designers and none developers repeatedly try to draw processwire into there old way of thinking with out of the box functionality, a template installer, plugins and more of that happy 1 click add-on's. (Luckily without success so far) Yes it is true that developers/coders have a great advantage here because they already have a mindset to abstract and translate concepts easily into a template with code, css, js, etc. Being experienced in php, css and js gives you a big head start when beginning with PW. You can see it sometimes happen in this forum that talented coders not always communicate well with none talented coders. Yes I am speaking for my self here But this forum stands out with great freedom of speech and with people who go to great length to help and assist beginners. But then again, you can't have it both ways: do it your way and do it the cms way. With processwire there is not doing it the cms way but do it your way or any way. What you wrote about pages is simply not true. Pages are easy for an administrator, a designer, a coder AND an end user/client. It only depends on who is going to fill pages with what data/setup/configs or content. The page concept is that flexible ! Once your beginners processwire blind spot goes away, you will never want to go back to joomla, wordpress and cms alikes. I can't give you right now the examples I was writing about. Try to find as much as you can in the forum like I did and you will see what I mean.

Hello everybody, we've just released PassiveCron & cron.pw as a beta version. Also check out the PassiveCron demo module, to learn how to integrate cron.pw inside a module. Follow @cronpw on Twitter to get notified about downtimes and updates. Thank you in advance for your feedback! Marvin

new german updates for actual PW dev 2.4.12 (13 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--process--processfield--processfield-module.json pw-lang-de-dev-update.zip

OK final say on this one, I have a workaround now - When going through the affected template in more detail, I found a nasty repeater-within-a-repeater part of the structure that wasn't actually being used when rendering the page, but was in there nonetheless. - I removed this from the template, which didn't fix the bug straight away - But - I then cloned one of the pages affected, so forcing a freshly created version to be made from scratch - The bug was then fixed in the fresh clone - i.e. repeaters seem to save ok again now, no matter what page field settings I had set - So my plan is to go through all the pages, clone them, delete the old ones, and the rename the new ones to take their place - I may do this programmatically using the API - One thing I'm wary of too: obviously when deleting pages, any references to the deleted page from elsewhere in the content will get broken, so I'll need a way of fixing these, hopefully via the API too Hope this helps anyone seeing similar weirdness s

Stop the presses! I must not have been thinking clearly yesterday. I pulled in the latest changes, updated the PW instance in question and went on to test it on the wrong domain, which still had the old code I guess this is a good lesson to not have too many quite similarly named test domains. So long story short: Latest dev has fixed the issue for me. As for the other one, this also seems to have to do with me exporting from an old install and importing that in a new (current dev) install. So everything is looking fine running the dev where the latest commit is '6ee2d96737fa64681fd3aefc65529ffca194f987'. I'm gonna go away now and hide in shame

You can't login that easy with email address. $session->login wants the name of the user. (Page name) Email is not unique in processwire. Something like this can work. (Could have a bug or 2 didn't test it) $email = $sanitizer->email($input->post->email); $password = $input->post->password; $amount = $pages->count("template=user, email=$email, include=all"); $error = false; if (!$email) { $error = "Not a valid emailadres"; } elseif ($amount === 1) { // if we have only one user with this email address, give the username back $username = $users->get("email=$email, include=all")->name; try { $u = $session->login($username, $password); if ($u && $u->id) { $session->redirect(1234); } else { $error = "Login failed."; } } catch(WireException $e) { // throttle login $error = $e->getMessage(); // get the error message } } elseif (!$amount) { $error = "No user found"; } elseif ($amount > 1) { $error = "multiple user accounts"; } if ($error) { echo "<p class='error'>$error</p>" }

I can't. I just pulled the latest dev branch. I export a field that's not required and it shows required:"". I change its setting to required and it shows required:1. I change it back and it show required:"". IOW, it works for me as designed.

Argos' little bit off-topic post really took some of the focus away in this thread, but anyway: If we take a look at two open-source PHP systems that are generally considered 'enterprise-ready' -TYPO3 and Drupal-, i see some things they have in common A very big portfolio of use in professional and large organizations, be it commercial or non-commercial, for all kinds of projects/sites A vast amount of companies that offer (Drupal/TYPO3) services and products. If you need help an agency is never far away. Globally known. 'Official' certification programs If you look at it along those lines, which a lot of people do, PW does not (yet maybe) fit the bill. But this whole 'enterprise' thing is tricky and dependent on the way you you define it. I would much rather emphasize on PW as a rock-solid and technically sound CMS/CMF, ideal for delivering professional, high-quality web projects. I agree that it might be a good idea to re-arrange or add to the site, so that it showcases this more clearly. Maybe a section of featured projects that showcase PW very well and/or do something very interesting with it. Maybe companies that use PW could be mentioned somehow, like avoine.fi. Anyways, these are just some thoughts. From a personal viewpoint (not using it professionally) i'm perfectly happy with where PW and the site stand at the moment.

The users as actual pages. users | +-- admin | +-- bwaked | +-- martijn There's no way you could put a double bwaked in the above structure. (remember $users->get('bwaked') syntax, getting bwaked user from users PageArray ) If you want to create a new user front-end, you should first check if the user already exists by asking the id. if ($users->get('bwaked')->id) { // user already exists, if it didn't existed the returned id was 0 so bools to false } else { // there's no bwaked, goahead and create } If you create a new user that already exists and you want to save this user, ProcessWire prevents saving. (error)

The former CMS from argos (and me) was a long time ago (around 20006-2012) full with out-of-the-box addons and snippets...many addondevelopers and so on. I used a lot of them - and hanging today on various older installations with the more or less "messed" code (actual example is the funny old continue(0); that kills some addons on PHP 5.4) I'm sick in using many many addons from many different sources. I'm sick of changing the given HTML Output of the addons to fit my Frontend. I'm sick of having 10xx template .htt's that serves me some Output (one from the Galleryaddon, one from the formaddon, one from the...) i'm a PHP "beginner" since a couple of years because if to less time to take a real step forward.....and in my opinion i'm a beginner until i am a beginner until i learn new things....so i always wanna be a beginner "Pages" is real the big issue to catch if you come from a other cms - and to setup the backend, too......but with the userroles and some other helpers it's a breeze! the "abstraction" with processwire is the best of the best....because it's much more easier than taking the head in a database abstraction!! every website setup could worked out exact for the needs of the user/client....and simple upgraded. to have some "skills" required for a system is not the badest thing - to keep out users that only demand everything (in the os world) for free and asap - the new tutorial pages are great and if my english would be better i'd love to write some... For the enterprise topic here - maybe it would be realy nice to show up some Apps that are build with PW like geowire.org! I'd love the showcase!! (there are some real big projects in it) and read all the casestudies https://processwire.com/talk/forum/16-case-studies/ something like this for some real "enterprise" projects - wouldn't this be the best advertice? and the "wording" enterprise has no good title in the OpenSource world because you can simple switch a letter and get enterprice

@argos I know the fact that "everything is a page" can be weird at the beginning (it takes me a few hours of experimenting to get confortable with this concept ), but I can confirm for my experience that this is really a great solution, both from a developer and and from a customer point of view, better than any other cms I tried (and I tried many, Wordpress, Joomla, Drupal, ...) I started to love the idea when I was starting to solve some problems in PW, and I always ended up (even after a lot of time thinking) saying "well I just have to use pages!". Just to give some examples: Problem: put some settings on a site level that can be manageable from the customer, ie a common footer text, a common image banner, and so on. Solution: You just have to create a new Settings template, put some fields in it, create a page with this template, fill in the fields and you're done! Problem: Create a categories system Solution: You create a category template, with the field you need (title, image, ...), you create some pages that uses these template, then, to link a category to a page, you only have to define a Page type field for the template that this page uses, fill in the value, and you're done! In both cases (in fact almost all other cases) from the template files (php) you can get the field values very easily using the api. The fact is: once you understand the "page" concept, you can solve almost any problem you can think of, and even very quickly.

jQuery DataTables 1.9.4 This module adds the great jQuery DataTables plugin for use in ProcessWire. You can load the module in the admin from any of your module using: $this->modules->JqueryDataTables; This will load the module and add CSS and Javascript from DataTables. This mostly would be used by a custom admin Process module. Note: Loading this module will just attach the necessary files to the admin. To use it you would need to add your own jQuery scripts and init the DataTables with something like. $("#mytable").dataTable(settings); For more informations on the DataTables options and API refer to http://datatables.net/ Download: http://modules.processwire.com/modules/jquery-data-tables/ https://github.com/somatonic/JqueryDataTables I included only the necessary files, and removed examples and docs from the package. NOTE: To avoid confusion, THIS module has nothing to do with my ProcessDataTable module for ProcessWire! ProcessDataTable was a proof of concept integrating it in a admin page. It included the jQuery DataTables plugin, but unfortunately it may wasn't a good way to. JqueryDataTables is a special js module like Fancybox. It is a "integration" of the jquery plugin for developers to use datatables in their modules. It won't be loaded unless you do so. An example would be the ModulesManager. They can coexist if you will.

I wonder if the Add Field dialog on the templates page could be enhanced to use the field's tags as optgroup dividers in the select field. I can see that might be useful if you have a lot of fields.

Why on earth you want to do that? Why not just call you field firstname?

Yes got it Adrian. What you said in your post before me put me on the right track. It´s working Add a new blog post and on the bottom there is a drop down list where you can chose the category and also what you said before add a new category !! Thanks a lot. Edit: yes, sorry forgot to click best answer.

But Rezepte is a Category which is linked to a page field for selecting categories to assign to blog posts. You don't want to add pages/posts under there at all - it would mess everything up

Yes, The verb is on the Http Request and different responses are given depending on the way you call an endpoint. If you got www.your-pw-site.com/products/ then you can have these methods GET -> list of products POST -> create a new product then if you got this particular product "computer-1" www.your-pw-site.com/products/computer-1 you can have these methods GET-> info of computer 1 PUT -> replace all the info of computer 1 PATCH -> replace specific info like name or sku of computer 1 DELETE -> removes computer 1 Now taking that as an example, you can have this way to program and endpoint in Processwire 1.- Create a template named "products" (with a file products.php in templates folder) 2.- Create a page that use that template, and creates the url www.your-pw-site.com/products/ (Enable UrlSegments) 3.- Now products.php will be coded like this Note that Product.php is just a helper class that just have some methods for easier output formatting <?php require_once './includes/Rest.php'; require_once './models/Product.php'; // Vars with the default output $code = 200; $output = null; $header = Rest\Header::mimeType('json'); // First check if you have Url segment1 // this segment you can have the product id if($input->urlSegment1) { $productId = $input->urlSegment1; $product = Product::find($productId); // Check if we found a product if(!($product instanceOf NullPage)) { // Convert the page object to our model $product = new Product($product); // Detects the Verb if(Rest\Request::is('get')) { // json encodeable array $output = $product->get(); } else (Rest\Request::is('put')) { $params = Rest\Request::params(); $output = $product->put($params); // Could be 202 if modification is made async // 200 if OK // $code = 202; } else (Rest\Request::is('patch')) { $params = Rest\Request::params(); $sku = $params['sku']; $output = $product->patch('sku', $sku); // Could be 202 if modification is made async // 200 if OK // $code = 202; } else (Rest\Request::is('delete')) { $output = $product->delete(); } // Product not found } else { $code = 404; $output = Product::notFound(); } } else { // Detects the Verb if(Rest\Request::is('get')) { $params = Rest\Request::params(); $page = $params['page']; $output = Product::fetch($page); } else (Rest\Request::is('post')) { $params = Rest\Request::params(); // You can get the params like // $params['name'], // $params['sku'] // and so on $newProduct = Product::create($params); // Returns and array that can be json encoded $output = $newProduct->get(); // 201 Created $code = 201; } } // End if // Show the response and body http_response_code($code); header($header); echo json_encode($output);

Martijn, you are really good. I see that was quite more then a normal login. It works! Since I am using this in a modal (foundation) and this modal closes when submit is clicked. is it possible (in case of errors) to redirect and echo these errors? ps. I have corrected some typos: missing ; and } at some places: <?php $email = $sanitizer->email($input->post->email); $password = $input->post->password; $amount = $pages->count("template=user, email=$email, include=all"); // if we have only one user with this email address, give the username back if ($amount === 1) { $username = $users->get("email=$email, include=all")->name; try { $u = $session->login($username, $password); if($u && $u->id){ $session->redirect("/login"); } else { $errors = "Login failed."; } } catch(WireException $e){ // throttle login $errors = $e->getMessage(); // get the error message $session->redirect("error-page"); ----------------- on that page echo $errors } } elseif (!$amount) { // no account with this email address } elseif (!$email) { $errors = "Not a valid emailaddress"; } else { // multiple user accounts $errors = "Login with username instead."; } ?>

@Kongondo: ^-^ ^-^

Looking awesome!

One of the best ways of doing that is to corner a niche market/region! Also, convincing the very high level companies ...how? some "very high level" companies tend to tune you out once you dont present a Microsoft based solution.

Great work Kongondo! Guess you've fun developing this one.

Great one - i'm shure ill translate it and test it!! maybe you've a lock at PIM http://modules.processwire.com/modules/page-image-manipulator/ for more options on the pics itself? Best regards mr-fan

@argos, Everyone is entitled to their opinion. Thanks for your comments.

[Maybe a somewhat off-topic reply] I would not call PW an Enterprise or Business CMS in this stage. I would not even call it an allround or general CMS at this stage. In my opinion it's purely a developers' CMS. I understand enough about the PW concept to understand why developers are psyched about it. It's a very promising concept indeed. I see it as a concept system, and not a real-world CMS yet. I know, I know, you can create real-world sites with it, but you have to be a developer. A real one, who can code, and can think very abstract. Someone who actually likes things to be abstract. Fired by my initial enthousiasm some time ago, when I discovered PW, I spent quite time trying to get my head around this system. I failed. I read all relevant forum posts, and support info. But still I failed. I was able to create a simple semi-static site after a while. But I would not need PW for that. I can use Wordpress or WebsiteBaker or Joomla or whatever. I got very frustrated trying to build a basic blog-site, even with the help of the semi-ready blog module I got frustrated about the complexity of it all. I also got frustrated about everything being called a page. I know the reasoning behind it, yet I think it's a user unfriendly concept that is already enough to stop PW in its tracks when it comes to widespread use. There are many usability shortcomings in PW that make it unsuitable for general use, let alone Enterprise use. It's an infant system, when it comes to allround features, plugins, and usability.It will not appeal to many people except coders and devs. That's not enough to make more than a dent in the current CMS landscape. I am not a developer. I am an experienced website builder, and I think PW is way too abstract and too cumbersome for people like me. My clients would even fail to understand 90% of the low level PW stuff I know now. I simply could not offer this system to clients, even if I would understand it completely myself. I keep an eye on PW, and I hope many of it's usability issues will be fixed in the coming years. Right now I use Joomla/K2 if I need a CMS with easy custom fields option. For a semi-static site I use WebsiteBaker, and for a typical straightforward blog either Joomla or (heaven forbid) Wordpress. PW an Enterprise CMS? Only if all people who work with it are coders. And those chances are very low. Sorry for the negativism, I'm still excited about PW, but it's not a suitable general or business CMS in the real world right now. I hope it will be someday.

new german updates for actual PW dev 2.4.11 (11 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--inputfield--inputfieldpagetable--inputfieldpagetable-module.json wire--modules--process--processmodule--processmodule-module.json added files: wire--core--modules-php.json wire--core--wiretempdir-php.json wire--modules--process--processmodule--processmoduleinstall-php.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.11 (09 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--core--functions-php.json wire--core--wirehttp-php.json wire--modules--fieldtype--fieldtypefile-module.json wire--modules--process--processmodule--processmodule-module.json added files: wire--modules--inputfield--inputfieldpagetable--inputfieldpagetableajax-php.json wire--modules--inputfield--inputfieldpagetable--inputfieldpagetable-module.json wire--core--wirecache-php.json wire--core--pageimage-php.json wire--core--fields-php.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.10 (06 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--process--processfield--processfield-module.json wire--modules--inputfield--inputfieldckeditor--inputfieldckeditor-module.json added files: wire--modules--process--processfield--processfieldexportimport-php.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.10 (04 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--process--processpageadd--processpageadd-module.json added files: wire--modules--languagesupport--languagetabs-module.json pw-lang-de-dev-update.zip

The word "Enterprise" gets used, abused and misused widely, and it is no help to anyone. To many developers/coders out there, Enterprise means it can scale up happily. But to the business community, Enterprise means it has a support structure in place that is able to relate to the large organisation, that it has a stable, long term support version and so on. I think if you release a business/enterprise version of anything, you must be in a position to speak to non-technical, business decision makers and be able to answer their needs I know from a cousin who is a decision maker in a large public company, that when they go for the Enterprise version of anything, it is not that they expect more bells and whistles than the community version, but they expect to be treated very differently. PW is not currently in the position to do that, unless someone can work out how to clone Ryan for free.

new german updates for actual PW dev 2.4.10 (02 August 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--fieldtype--fieldtypepage-module.json wire--modules--process--processrole--processrole-module.json added files: wire--modules--fieldtype--fieldtypeselector-module.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.9 (28 July 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--process--processtemplate--processtemplate-module.json added files: wire--modules--inputfield--inputfieldckeditor--inputfieldckeditor-module.json pw-lang-de-dev-update.zip when PW 2.5 is ready, we have to remove TinyMCE language file from the default lang pack and offer it separately for the module.

new german updates for actual PW dev 2.4.7 (11 July 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--fieldtype--fieldtypepagetable-module.json wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json wire--modules--process--processmodule--processmodule-module.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.5 (01 July 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--fieldtype--fieldtypefile-module.json wire--modules--inputfield--inputfieldimage--inputfieldimage-module.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.5 (28 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--core--pages-php.json wire--core--wireupload-php.json wire--modules--fieldtype--fieldtypefile-module.json wire--modules--inputfield--inputfieldfile--inputfieldfile-module.json wire--modules--process--processlist-module.json wire--modules--process--processpagetype--processpagetype-module.json wire--modules--process--processrole--processrole-module.json pw-lang-de-dev-update.zip

new german updates for actual PW dev 2.4.5 (18 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--templates-admin--debug-inc.json pw-lang-de-dev-update.zip

thanks for the hint. new german updates for actual PW dev 2.4.4 (17 June 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). added files: wire--modules--inputfield--inputfieldselector--inputfieldselector-module.json pw-lang-de-dev-update.zip best would be to have a GitHub repo for the dev lang-pack as discussed above, so others can check and correct files if necessary?

new german updates for actual PW dev 2.4.2 (28 May 2014). Zip contains only updated/added files (in comparison to the default 2.4 lang pack). updated files: wire--modules--inputfield--inputfieldinteger-module.json wire--modules--process--processpageadd--processpageadd-module.json added file: wire--modules--fieldtype--fieldtypepagetable-module.json pw-lang-de-dev-update.zip

I have placed the first 4 module translations for german on GitHub --> https://github.com/Manfred62 ProcessDiagnostics Thumbnails ModulesManager CKEditor not sure, is it helpful to always translate the module title? Suggestions and corrections welcome.

Hi Ryan, I don't how complicated this would be, but I have a feature request. If a field using the Table Fieldtype is set to required, then have the first row of the field automatically visible. I just watched some of our interns test calendar entry using a "dates" table field. They got tripped up on the field being required, but no rows immediately visible. Most of them missed entering the field the first pass.

short update: the missing string has to be placed in /wire/templates-admin/default.php. Maybe could be done with installation process of the language support module? /* * Dynamic phrases that we want to be automatically translated * * These are in a comment so that they register with the parser, in place of the dynamic __() function calls with page titles. * * __("Pages"); * __("Setup"); * __("Modules"); * __("Access"); * __("Admin"); * __("Languages"); // the missing phrase * */ after that it's translatable. Also have done some more translations for the german language pack (for 2.3.4). Will send a pull request soon.

small update to the german laguage pack. In the zip are following new files: wire--core--pages-php.json wire--core--wirehttp-php.json wire--core--wireupload-php.json wire--modules--fieldtype--fieldtypecomments--commentfilterakismet-module.json wire--modules--fieldtype--fieldtypecomments--fieldtypecomments-module.json wire--modules--fieldtype--fieldtypecomments--inputfieldcommentsadmin-module.json wire--modules--languagesupport--languagesupportfields-module.json wire--modules--languagesupport--languagesupportpagenames-module.json I took them from Radek's cz files and translated them. Maybe someone (yellowled?) can check/correct them before loading up to GitHub? Some phrases are ... difficult to translate. de-DE.zip

The creation process really isn't a problem with the tools Ryan mentioned. Especially for stuff like country lists i think it's really powerful to use pages. Easy to maintain; if a country name changes (yes, this does happen every once in a while) you just update that page and everything using it will always be in sync, be it your select options or other places you used the country pages. Maybe you would want to add some additional info, like a country flag or multilingual country names. This stuff all becomes easy and transparent if you use pages. What if later on you would also want to support regions and/or continents? Easy to implement when everything is pages.

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