Leaderboard

I've pushed several updates consistent with the feedback above. This includes going a little more minimal on some things, converting absolutes to floats, making the lines more visible, and numerous other updates. I also added another color theme "futura", which is based on Nikola's Futura Remixed. With regard to typography, I'm going against my own preferences and making the type bigger, bolder (in Classic and Modern), and increasing the line height. These changes make it less usable to me personally, but my conclusion from previous feedback was that others may prefer bigger/bolder, more height, more room, etc... so just trying to find a balance. After all, the point here is to have a theme that appears to a broader group, rather than one that maximizes usability at scale. Or at least to find a balance. Regarding there being some redundancy or things that need cleaning in the CSS–I'm leaving a lot of extra stuff in there since I change my mind a lot. I'm not going to fully clean and remove redundancies until it's final. So please don't look for perfection here, this is a work in progress. I'm not going to vacuum this place until the work is done. Regarding use of Arial as the typeface: I tried switching to OpenSans, but there was just too much personality to it that I thought it was influencing the tone too much, and ultimately too distracting. If you guys can think of any other free, fairly neutral webfont typefaces worth trying, please let me know. I would love to find a better alternative to Arial. Edit: Almost forgot, here's the screenshots of the updates. ./?colors=classic ./?colors=modern ./?colors=futura ./?colors=warm

This module is obsolete - please use the Console Panel in Tracy: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=console Ok, this is really not very fancy, but I think it will come in quite handy - for me at least It provides an admin page where you can test code without the need to edit template files. It runs from a new item under Setup called "Code Tester" Simply enter your code, including an opening <?php and click "Run Code". Page will refresh with the code block still in editor, and with an iframe containing the results of your code below. In some cases the output may not be relevant if your code is manipulating pages etc via the API, rather than outputting content to a page. Then you can easily make code changes and run again. Github: https://github.com/adrianbj/ProcessCodeTester Installation Install as normal, then move the included file "code_tester.php" to your site's templates folder. Depending on your sites template structure, you may want to edit this file. I have set it up using the head.inc and foot.inc approach that is used in PW's default profile. There are detailed instructions in the file to make it easy to modify as needed if you prefer using a single main.inc or other approach. Install the ACE Text Editor module if you want syntax highlighting. That's It! How it works Nothing very high tech - when the module installs it creates a new template: code_tester and a new unpublished page: Code Tester. When you click "Run Code" it creates/updates this file: /site/assets/files/ID_of_Code_Tester_page/code_tester_code.php and writes your code to the file. This file is included from the code_tester.php file and the code is run and the output processed. Note that I am using ob_start(); include; $out = ob_get_clean(); so that this will work take the approach of populating variables that are output within a main/shared markup file like main.inc If you want to use a variable other than $out in your test code, you will need to edit the code_tester.php file accordingly. Things you can do It may not be immediately obvious as to some of the things that work with this, so here are some examples: echo 'test'; $out .= 'test'; //list page titles matching the selector foreach($pages->find(selector) as $p) $out .= "<li>$p->title</li>"; //populate the results frame with the page returned by the selector. You must use $getpage as the variable! $getpage = $pages->get(selector); // bulk delete pages matching the selector foreach($pages->find(selector) as $p) $p->delete(); So really it is more than a code tester - it can also be used as a way to test selectors and return the resulting page and also as a way of running admin maintenance scripts. Hopefully you guys might find it useful. Please let me know if you have any thoughts for improvements.

Nope, not luck. I've never handed out a single business card. I work harder, longer, smarter. Where others give up, I keep going. There's a fine line between doing good work and great, and I put forth the effort that others don't to produce great work. I'm also very careful not to think about what I don't want, but rather what I do want. For example, while you are thinking about prices in the supermarket, elec, gas, rent, etc. your perception shifts to fear and scarcity. Afraid you can't pay rent, afraid you don't have enough work, afraid you'll be in debt. You attract what you think about. I'm an entrepreneur, and yes, I have the same concerns, but instead of worrying I'm thinking about solving problems for others, growing my business and how I can provide value to others. Which thought pattens do you think will serve you? If you want to build websites, how does thinking about supermarket prices help you do that? Money and success is a natural bi-product of correct thinking and providing value to others. So that's one aspect, and it takes practice to correct thought patterns that aren't serving you (limiting beliefs, e.g. the market sucks, there's no jobs. Some of my most successful times were during my nations worst economic recessions). Looking at this from another perspective... If you aren't getting work, asses your skills and talents. If you are skillful and have the talent, then you may need to just get out there more. Do more networking, ask family and friends if they know anyone needing a website, talk to local businesses, reach out to design agencies, reply to tons of classified ads frequently. Make unsolicited call, send emails, stand in front of a supermarket and embarrass your self with a cardboard sign that advertises your services (if that's what it takes). It's a numbers game. In e-commerce there's something called a conversion rate. Converts are the website visitors that actually buy something from the website, not just a site visitor who stops by to look. A good conversion ratio is between .5% and 1%. That means that for every 200 site visitors only 2 of them will buy something. The same idea applies to getting paying gigs. Have you offered your services to 200 people this week? If so, maybe you'll pick up a gig or two. If not, hustle. Reply to 20 classified ads a day, five days a week. That's 100 people who know you now. Go out into your community and find another 100. Maybe that means sending unsolicited emails and making phone calls, maybe it means stoping by the shops that you like. Go to book stores and libraries and slip your biz card into the how to build website books. If you want some help, send me a list of your skills and some examples of your work. I'll keep you in mind when I or a client needs someone with your skills. If you have any questions, I'm happy answer them over skype, email, this forum, etc. Some good resources to consider: Marketing Without Advertising: Easy Ways to Build a Business Your Customers Will Love and Recommend 177 Mental Toughness Secrets of the World Class Business Lessons for Entrepreneurs Change Anything: The New Science of Personal Success Mind Performance Hacks: Tips & Tools for Overclocking Your Brain http://fundersandfounders.com

There was a post here some days ago where Arimo was mentioned. The metric is the same as Arial. It's the default font at HTML Kickstart from our Joshua

Field dependencies are coming in ProcessWire 2.4, and I just wanted to give you guys a little preview of it. The development of this new feature is being sponsored by Avoine, the company where Antti works (he also specified how it should work). Field dependencies are basically just a way of saying that one field depends on another. It dictates which fields should be shown in a given context. In our case, it also gets into whether a field is required or not. This short video demonstrates how it works: (switch to the 720p and full screen version, as YouTube's default settings for this video make it impossible to see): // Edit @Adamkiss: Here's link for those on mobile: youtu.be/hqLs9YNYKMM The implementation here is done both client-side and server side. Javascript handles the showing/hiding of fields and the required vs. not required state changes. On the server side, it doesn't process any fields that aren't shown, and honors the required rules. A separate processing occurs both client side and server side, ensuring that the user can't make their own rules by manipulating the markup or post data. These field dependencies can be used with any Inputfield forms. That means you'll be able to use it not just in ProcessWire, but in FormBuilder, and via the API too. It's very simple to use from the API. All you have to do is specify a ProcessWire selector to either "showIf" or "requiredIf" to the Inputfield, and ProcessWire takes care of the rest: // show this field only if field 'subscribe' is checked $inputfield->showIf = "subscribe=1"; // show this field only if 'price > 0' and at least one category selected $inputfield->showIf = "price>0, categories.count>0"; // make this field required only if 'email' is populated $inputfield->required = true; $inputfield->requiredIf = "email!=''"; This feature will be in the 2.4 core (rather than as a separate module), so it will also be ready and available for things like module and field configuration screens.

Two days ago, an idea about a new admin theme came to my mind. Some hours later, I've crafted a first concept in Adobe Fireworks.... The look and feel of the admin is important Two months ago, I've introduced some teachers into ProcessWire. They were none-technically people. At the end, they knew how to use the admin panel to create content or update a gallery on their new page. However at some points, they got confused with parts of the admin theme -beside the problems with our concept on how to use fields and templates for creating content. I think one factor why Wordpress became so large, was the great Adminpanel. It works well and easy (as long as you have a blog and not a twenty-plugins-for-text-pages-site). Editing content on a daily basis is the main task of my customer. I've to take this aspect serious. Problems I wanted to solve Have the page tree always visible. If I do not click the right link, it will be closed after I've finished editing my site More visuals like icons. Simplify some workflows. Creating 3 or 4 pages can result in multiple unnecessary clicks. More focus on important links like the tabs. Guide my customer through some action. Help them to repeat simple tasks. The concept First: Nothing is perfect and its not possible to find one single solution for everything. This was just done in a couple of hours and it's only the first iteration. Quick action button Next to the ProcessWire logo is the quick "Quick Actions" button. It should be possible, to configure it like: "Create a new Page with Template X with page Y as a parent". Use it for skyscrapers, news or galleries. (Yes i know, the arrow is pointing upwards. This is wrong) Two column layout The page tree is always visible (as long as we are in the pages view). It can be navigated as the normal page-tree. If you click "edit" it will become highlighted. Every action that would take you to a new page, would be displayed in the other half of the monitor. Speaking of a "half monitor" - I think that most people use a screen resolution of atleast 1300px. The sidebar should take up to 1/3 of this. On smaller screens, it will become hidden by default or we just simply step back to single pages for each view. If the content is to long, the sidebar becomes scrollable. Page tree I like the Template Decorator made by mindplay.dk. It fits the concept well with black outline icons for every type of template. The same icons could be used in the Quick action menu. I'm note sure what to do with the "move" action. To Do list Think more about the behavior of the elements. Design the modules view. Rework the search and the top menu. Options to "brand" the panel for agencies while keeping the ProcessWire logos. What happens if we are on mobile (small screen) devices? Listen to your feedback.

Lately there have been lots of people that are not enjoying the default admin theme, so we've been working on making something new. Not trying to solve all issues or add every new feature we'd like, but just trying to come up with something to have as an interim replacement for the default admin theme until we can afford the time to do something broader in scope (like Phillip Reiner's great admin theme design for example). So this theme doesn't necessarily break a lot of new ground, but hopefully has some of the improvements that people are looking for. Visually, the goal here was to find a lighter, more modern look and reduce the boxes-in-boxes feel of the current admin theme. I've opted to commit it to the dev branch because it requires the latest version of ProcessWire on the dev branch, and likely will continue to with updates. Meaning, I can't distribute this one as a 3rd party theme very easily. This is because I'm making core updates related to the admin theme at the same time. So if you want to help test this new theme, you'll need to grab the dev branch of ProcessWire. The new admin theme is in /site-default/templates-admin/. That means you'll see it as the default theme if you are installing a new copy of PW. But if upgrading an existing copy, you'll continue to get the old theme. If you want the new theme, then just copy the /site-default/templates-admin/ directory to your /site/templates-admin/ directory on your existing PW install. This would be in addition to replacing your /wire/ directory with the latest one from dev, as usual for PW upgrades. The existing default admin theme also remains in place in /wire/templates-admin/. So if you want to stick with the existing/stable admin theme, then just make sure you don't have a /site/templates-admin/ dir in place (unless you are using a 3rd party admin theme). This admin theme is probably not production ready, as it's not been tested in many browsers yet. I personally haven't yet tested it in anything but Chrome and Firefox in OS X. Please let me know if you experience issues in other browsers. I fully expect things won't be pretty in IE... but they never are. To start, this comes with 3 color schemes (though we'll be adding more too): Warm: Modern (similar to processwire.com site colors): Classic (similar to existing admin theme colors): To switch to one color theme or the other, specify a GET variable of 'colors' in any URL you are accessing in the admin: /processwire/?colors=warm /processwire/?colors=modern /processwire/?colors=classic To specify a default, edit your /site/config.php and set to one of the following: $config->adminThemeColors = 'warm'; $config->adminThemeColors = 'modern'; $config->adminThemeColors = 'classic'; We'll probably make this switchable in the user profile at some point, but that comes later. This theme also comes with some new features (most of which have been copied/inspired from the work of others here, whether in other admin themes, modules or designs): It now uses Font-Awesome icons rather than jQuery UI icons. We now only use jQuery UI icons for actual jQuery UI widgets. Note that asmSelect and our file/image inputfields are built as jQuery UI widgets, but I don't think anything else is. Basically, the majority of icons in the system are now Font-Awesome icons. You can associate Font Awesome icons with templates. When associated with a template, the icons will appear in the page list, in front of the page title. To use this, edit any template and go to the Advanced tab. In the "List of fields to show in admin page list", you can type in any Font Awesome icon name (in addition to the field names you could before). For example, in the Page List screenshots above, I have my "search" template configured with the value: "icon-search title". You can associate Font Awesome icons with fields. When associated with a field, the icon will appear at the beginning of the input. For example, I associated a coffee icon with my "title" field in the screenshot below. To do this, edit the field, click on the Advanced tab, and enter the icon name in the new field provided for it. The top navigation now supports simple dropdowns. A new "user" dropdown has also been added that contains profile and logout links. The main Pages screen contains an "add new..." button, that is itself a dropdown to a list of templates that are configured adequately for us to know where they would be added. To use this, you have to configure your template "family" settings. The search box is now ajax powered, though this was introduced a couple weeks ago in the existing admin theme too. The theme is responsive too, of course. This is all kind of preliminary and open to changes. I'm trying to keep the scope of the project fairly small since I don't have much time to work on it. But just wanted something to quiet the haters a bit for a little while, so that we can take our time on the bigger admin theme project for longer term. We'd appreciate your feedback if anyone has time to help test.

I just pushed ProcessWire v2.3.1 to the dev branch. This is a fairly major change in that it switches the DB driver from mysqli to PDO. It meant changes to a large percentage of core files. ProcessWire still supports mysqli, but doesn't attempt to use it unless a module or a template asks for it via the $db API variable. The new API variable (for the PDO driver) is $database. More about PDO at php.net If you are using the dev branch, be careful and test thoroughly with this latest commit to it. Before upgrading, you may want to double check that your PHP supports PDO by looking at your phpinfo (CMD-F or CTRL-F for "PDO"), especially if you are running PHP 5.2.x (where PDO wasn't compiled in by default). Though if you are running PHP 5.2 (vs 5.3.8+) then you may want to just stick with ProcessWire 2.3.0 and upgrade your PHP version when possible. If you are using any modules that use the procedural version of mysqli functions (vs. the $this->db object oriented versions), or type-hint mysqli in methods, then those modules will no longer work. If you come across any modules that don't work with 2.3.1, please let me know here so that I can assist the author in updating them. Note that FormBuilder is one of the modules that does not work with 2.3.1, but I have posted an update in the FormBuilder board that corrects it–so be sure to download that version if you are tracking the dev branch of ProcessWire and using FormBuilder. What this new version adds: 1. New API variable $database that refers to the PDO database. The old $db API variable is still there and refers to mysqli for any modules that continue to use it. 2. New API variable $log that lets you easily log messages or errors to the system logs. Usage: $log->message("This saves this line to messages.txt"); $log->error("This saves this line to to errors.txt"); $log->save("my-log", "This saves this line to my-log.txt"); // Get an array of the last few entries saved to the messages log $entries = $log->get('messages'); // Get an array of the last 50 entries saved to my-log $entries = $log->get('my-log', 50); Note that as always, log files are located in /site/assets/logs/. 3. Conditional autoload modules. In PHP 5.3+, modules may now specify an anonymous function OR a selector string, rather than a boolean for the 'autoload' property returned by getModuleInfo(). PW runs the anonymous function after determining the current $page, so your module can make autoload decisions based on the $page (or any other factor you'd like), if desired. Lets say that we have a module that we only want to autoload when the template is 'admin': public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => function() { if(wire('page')->template == 'admin') return true; else return false; }); } And the same example but using a selector for autoload: public static function getModuleInfo() { return array( 'title' => 'Module Title', 'summary' => 'Summary text...', 'version' => 1, 'autoload' => 'template=admin' ); } 4. Addition of $pages->add() method. Actually $pages->add($template, $parent, [string $name], [array $values]); This function adds a new page to the database and returns it. This is for syntax convenience, but using the old method is still perfectly fine too. Here's a few examples of usage: // add a new page using template basic-page under /about/ $newpage = $pages->add('basic-page', '/about/'); // same as above, but named 'contact' $newpage = $pages->add('basic-page', '/about/', 'contact'); // same, but populate the title field too $newpage = $pages->add('basic-page', '/about/', 'contact', array('title' => 'Contact Us')); // you can also do this, specifying the values array as 3rd argument: $newpage = $pages->add('basic-page', '/about/', array('title' => 'Contact Us')); $template and $parent are required, but may be objects, IDs, or string identifiers (like name for template, or path for page). When you add a new page and don't specify a 'name', then PW will make one up, guaranteed to be unique. 5. Module files that end in '.module.php' are now supported. So rather than ClassName.module, you may use ClassName.module.php if you prefer it. The purpose here is to support text editors that determine their syntax highlighting based on the file extension. More updates being made almost daily. Please report any issues you experience. Thanks, Ryan

nghi - don't bother - just grab the lastest dev version of PW - Ryan has implement toggling of grid and list views for images - very nice

for shure: // mysqli will be depricated, so use PDO if you start with it $sql = "awesome query"; // $database variable is available in your templates. $database is the PDO way. $query = $database->prepare($sql); $query->execute(); Oké, stupid me: Welcome to ProcessWire greentea

Hello. I don't know if this could this be added on the Page Name module's settings to PW installation: ã õ I added those two because I use portuguese to generate FURLS and I noticed that on PW 2.3 . Don't know if this is relevant or not. Thank you. ä=a ã=a õ=o ö=o ...

I had to leave Drupal behind, because it didn't serve my community. Basically it was too expensive and it's really starting to cater more to enterprise clients. I'll probably never use Drupal again, unless it's for an enterprise client with a big budget. Building a simple blog site is fast and easy enough by cloning an existing Drupal site, but the problem is the ongoing costs of maintenance. I can knock out a fairly robust Drupal site in a week and charge less than $2-5k, but at that price point, I'm not attracting clients who will pay the $2,500 - $5,000 a year to maintain (both the server and the software) and host Drupal (In my experience Drupal needs a dedicated or vps server for sites w/o any significant amount of traffic). My clients are small businesses and uneducated regarding their options. They think Drupal is the next WordPress w/o realizing it's not even close to being as simple, it's more expensive, and it's not all that easy to maintain. On top of that, Drupal devs charge between $90 and $175 per hour. From a business perspective, Drupal is fantastic (a cash cow). There's always an upsell, always a problem to fix, always a new update to apply (then fix). It's too bad I'm not it in for the money. I prefer to get paid less and enjoy the work I do (PW is fun, Drupal is a pain in the ass). I want to provide quality, charge a fair price, and work with great people, not dupe someone into buying a boat as it were, which is what I see a lot of Drupal web agencies doing. They don't choose the best platform for the client, instead they put them on Drupal... the recurring income stream because it's good for their business. Inexperienced devs/freelancers will do the same thing, but for the right reasons most of the time. They just don't have the experience with Drupal to know what problems lie ahead. The only advantages I see of using Drupal, -Drupal has a huge community testing and reporting bugs which makes it more stable, secure and more accessible to more server/hosting environments. -Drupal has a ton of quality free modules. -Drupal is great for enterprise clients. The costs at this scope are quite reasonable and Drupal seems to meet the needs of these clients very well (talking about huge companies). For example putting the .gov site in Drupal was smart, the whitehouse has the budget and resources to do the job right and they have a much better solution for the price than building something that large from scratch. My rule of thumb, if a client is getting 100K unique visitors a month, then consider Drupal, but also consider whether or not the client can afford it. If you sell someone a Drupal site that they can't afford, you will have nothing but conflict and unhappy clients. Sometimes too you need to consider the level of sophistication of the client. Even if a client has the budget, it's sometimes better to put them on a platform which grows as their understanding of websites grows. A way to illustrate this... Say I work at a snowboard shop and i have a customer who has only been snowboarding once. I wouldn't sell them them to top of the line board unless they insisted. Instead I'd try to get them to purchase a board that is more appropriate for beginners. Not only will the board be cheaper, it's not built for precision like the high end boards. The customer will have an easier time learning on the entry level board and have more fun as a result. If sold them the high end board, they may have difficult controlling it and fall a lot or run into a tree. To address some of your points on the difficulty of selling PW... My point is, change your sales strategy for each client. You may think PW is the best thing since sliced bread (it is), but if you are interested in being successful in business, sell people what they want, not what they need. They will be ecstatic with you and your services and you'll have a fat wallet and more work than you know what to do with. As your relationship with these people grows, you'll be able to move them to a better platform like PW when it's time for a new website or when they decide they need something that their current platform doesn't provide. My boat reference: A boat is a hole in the water into which you pour money.

Hope the icons go to 14px. Font Awesome is designed for 14 px.

Hi Joe. A simple search via google (processwire.com hide settings tab) found my thread a while ago: http://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/ Here's another example doing it differently: // in a autoload module like HelloWorld.module public function init(){ $this->addHookAfter("ProcessPageEdit::buildForm", $this, "buildFormHook"); } public function buildFormHook(HookEvent $event){ // get page edited by ProcessPageEdit $page = $event->object->getPage(); // conditions if(wire("user")->hasRole("superuser")) return; if($page->id == 1039) { // the form InputfieldWrapper returned by ProcessPageEdit::buildForm() $form = $event->return; // find the desired InputfieldWrapper's and remove them from the form $fieldset = $form->find("id=ProcessPageEditSettings")->first(); $form->remove($fieldset); $fieldset = $form->find("id=ProcessPageEditDelete")->first(); $form->remove($fieldset); } } This works fine in PW.

That's correct. Incorrect. You'd want to add some additional GET or POST variable to your AJAX requests in order to differentiate them and bypass the cache. The drawback is that only your regular requests will be cached, and your AJAX requests won't. You can always get around this by using MarkupCache for caching either type of request and delivering the appropriate one according to the request method (regular vs. ajax), but it'd have to be a pretty slow/heavy request before I'd bother with that. Perhaps a better way to achieve it would be to use pagination, as paginated URLs are fully cached (using PW's template cache). That's assuming you don't need pagination on the template for another reason. But by enabling page numbers, you could delegate your regular full-page request to /path/to/page/, and your ajax requests to /path/to/page/page2/, and page3, page4, etc., as needed. Your template code could detect it like this: if($input->pageNum == 2) { // deliver ajax request } else if($input->pageNum == 1) { // deliver regular full-page request } else { throw new Wire404Exception(); // prevent caching } Partially correct. If you use ProCache, you can cache URL segments, but not the results of #anchors, or requests containing GET/POST variables. You'd want to convert those to URL segments and then you could cache everything as needed. For example, rather than /path/to/page/?fragment=version you'd use /path/to/page/fragment/version/, and "fragment" would be represented by $input->urlSegment1 and "version" would be represented by $input->urlSegment2.

Uhh, I have a lot do to right now. But if I have any free time in the next days this is the first thing I'll continue

I would guess that wireEncodeJSON() is converting your string value to an integer. It will do this if the value matches ctype_digit("$value"); That means a value like "0888" would get converted to an integer of 888. But a value of "0888 1234" would not, as it contains a space. In your case, I'd stick with the regular json_encode(). wireEncodeJSON() was made for saving module and field configuration settings, where we wanted to remove settings that had blank values in the name of space savings. If you also want that capability, but wireEncodeJSON() doesn't do it exactly how you want, you may want to copy the function out of /wire/core/Functions.php and into your own (named differently) in /site/templates/includes/functions.php (or something like that). You probably want to make adjustments to the line that converts it to an integer.

Greetings, What makes ProcessWire so excellent is the ability to do all kinds of work at the API level, so that you can essentially create a custom admin for your projects. Editing a page is of course a crucial part of any custom admin. NOTES: Of course, you must cutomize this to your project. Also, in my code I am editing the page directly inside the page itself. In other words, you display a page as usual, but inside it you have your edit code, as well as code to save the page after editing. The other option would be to link to another page just for editing. Editing does get rather involved. Below is a technique I've used. I'll break editing down to several steps, then later I'll put it all together as one. Here goes... Step 1: Isolate Who Has Editing Rights You don't want anyone who can view the page editing it! I use code like this to limit editing to people with either an "editor" or "superuser" role. We open it here, and close it later in Step 6: <?php if ($user->isSuperuser() OR $user->hasRole("editor")) { Step 2: Set the $page Variables (Except Title) to Hold Edited Values Take inputs received from a submitted form and use those values to replace current $page values. For this example, I am only using two fields to keep it simple. And they are text fields. We hold off on setting the title, since that needs special handling: <?php if ($input->post->title) { $page->set("first_name", $sanitizer->text($input->post->first_name)); $page->set("last_name", $sanitizer->text($input->post->last_name)); } Step 3: Edit Title Field, but Only if the Title is Unique, Then Save the Page You need something like this so you don't get an error if the title you apply to the edited page collides with the title of an existing page. The code below confirms that the title is unique and allows you to set the title, and only then save the page: $thistitle = $page->title; $matchedtitle = $input->post->title; $checktitles = $pages->find("parent=/[path]/[to]/[parent]/, title=$matchedtitle|$thistitle"); $titlecount = count($checktitles); if($titlecount < 2) { $page->of(false); $page->set("title", $sanitizer->text($input->post->title)); $page->set("name", $sanitizer->text($input->post->title)); $page->save(); Step 4: Refresh URL Think about it... If while editing this page we changed the title, the URL you are on is no longer valid. Here's a simple bit of Javascript to handle this. The code below also closes out the conditional set in Step 3: $refresh=$page->url; ?> <script type="text/javascript"> window.location = '<?php echo $refresh ?>'; </script> <?php } Step 5: Handle the Scenario When the Page Title Collides In Step 3, we edited the page title because it passed the "unique" test. But what if it fails that test? We would move to this section of code, where a message lets the user know there is a problem. A bit of Javascript helps make the warning fade in so it is more noticeable: else { ?> <div class="admin_error_box"> <p>Sorry, there is already a page using this title: <?php echo $input->post->title?>!</p> <p>Please enter a different title in the form.</p> </div> <script> $(function() { $('.admin_error_box').hide().fadeIn(3000); }); </script> <?php } Step 6: The Edit Form We need a form to capture the submission of edits. It would look the same as your page-creation form, but would have to be pre-populated with the current values of the page, which will also change upon submission of the form. The last bit of code closes out the check on user roles set in Step 1: <div class="page_create_form_box"> <p class="form_heading">EDIT THIS PAGE USING THE FORM BELOW</p> <form action="<?php echo $page->url ?>" method="post"> <ul> <li><label class="label_class" for="title">Page Title:</label> <input type="text" class="input_class" name="title" value="<?php echo $page->title ?>"></li> <li><label class="label_class" for="first_name">First Name:</label> <input type="text" class="input_class" name="first_name" value="<?php echo $page->first_name ?>"></li> <li><label class="label_class" for="last_name">Last Name:</label> <input type="text" class="input_class" name="last_name" value="<?php echo $page->last_name ?>"></li> </ul> <button class="admin_submit" type="submit" name="submit">SAVE EDITED PAGE</button> </form> <?php } ?> Step 7: Putting it all Together Now let's put all of this code into one continuous routine. <?php if ($user->isSuperuser() OR $user->hasRole("editor")) { ?> <?php if ($input->post->title) { $page->set("first_name", $sanitizer->text($input->post->first_name)); $page->set("last_name", $sanitizer->text($input->post->last_name)); } $thistitle = $page->title; $matchedtitle = $input->post->title; $checktitles = $pages->find("parent=/[path]/[to]/[parent]/, title=$matchedtitle|$thistitle"); $titlecount = count($checktitles); if($titlecount < 2) { $page->of(false); $page->set("title", $sanitizer->text($input->post->title)); $page->set("name", $sanitizer->text($input->post->title)); $page->save(); $refresh=$page->url; ?> <script type="text/javascript"> window.location = '<?php echo $refresh ?>'; </script> <?php } else { ?> <div class="admin_error_box"> <p>Sorry, there is already a page using this title: <?php echo $input->post->title?>!</p> <p>Please enter a different title in the form.</p> </div> <script> $(function() { $('.admin_error_box').hide().fadeIn(3000); }); </script> <?php } ?> <div class="page_create_form_box"> <p class="form_heading">EDIT THIS PAGE USING THE FORM BELOW</p> <form action="<?php echo $page->url ?>" method="post"> <ul> <li><label class="label_class" for="title">Page Title:</label> <input type="text" class="input_class" name="title" value="<?php echo $page->title ?>"></li> <li><label class="label_class" for="first_name">First Name:</label> <input type="text" class="input_class" name="first_name" value="<?php echo $page->first_name ?>"></li> <li><label class="label_class" for="last_name">Last Name:</label> <input type="text" class="input_class" name="last_name" value="<?php echo $page->last_name ?>"></li> </ul> <button class="admin_submit" type="submit" name="submit">SAVE EDITED PAGE</button> </form> <?php } ?> My apologies for any problems with the formatting of the code above (please use your editor to assure proper tabs). Notes: - If you include checkboxes or other field types in your page, the editing is a bit more involved. - If you have image fields, you would have separate actions connected with those. For more information on handling image fields in custom forms, take a look at this: http://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ That should get you started! Follow up if you have more questions! Thanks, Matthew

Thanks for trying it out. I didn't realize that locale settings went as far as typecasting. Seems like typecasting should be about maintaining a type for the language, not for display. While we could set the LC_NUMERIC, and maybe that's the right way to go (I'm not yet sure), I'd be worried about the situations when someone wants to override the numeric stuff. Perhaps FieldtypeFloat needs to do this in the sleepValue method: save the locale, set it to something compatible with PHP and MySQL, then set it back to whatever it was. That seems like maybe the way to add this with least impact.

download ISO image Raspberry pi, for people that doesn't know about this little computer that cost less than 50$ The image comes form a 2GB SD card ProcessWire Admin user: admin pass: process2013 Mysql Database dbName = 'process'; dbUser = 'process'; dbPass = 'processdb'; Raspberry admin and ftp user user: pi pass: raspberry you get processwire files under /home/pi/www