Leaderboard

Select Multiple Transfer Multi-selection Inputfield module for ProcessWire using the jquery.uix.multiselect plugin by Yanick Rochon. This Inputfield provides similar capabilities to asmSelect but in a very different way. The usage of two separate lists may be more convenient when needing to select a large quantity of items. Like asmSelect, it also includes support for sorting of items. Unlike asmSelect, it has a built-in search field for filtering. It can be used anywhere that the other ProcessWire multi-selection inputfields can be used. Download ZIP file Modules directory page GitHub Class (for auto-install): InputfieldSelectMultipleTransfer Important Installation Notes This module is installed like any other, however you will need to take an extra step in order to make it available for page selection. After installing this module, click to your Modules menu and click the core InputfieldPage module to configure it (Modules > Core > Inputfields > Page). Select InputfieldSelectMultipleTransfer as an allowed Inputfield for Page selection, and save. Now you should be able to select it as the Inputfield when editing a Page reference field. For obvious reasons, this Inputfield would only be useful for a Page reference field used to store multiple references. (Note that this video is showing this module in combination with field dependencies and dependent selects (something else brewing for 2.4 but not yet committed to dev).

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.

GitHub: https://github.com/adrianbj/ProcessMigrator This module has gone through lots of iterations with lots of new functionality each time. It is now a fully fledged content migration tool. *** Please be sure to read the GitHub ReadMe to find out what it can do now as most of the posts in this thread are no longer correct regarding its functionality Once it is release worthy, I'll create a fresh thread with all the details. This modules allows export, sharing, and import of page lists via JSON files. It takes care of replicating all the pages, as well as creating any templates and fields that are needed. I have defined "Page Lists" as page trees (parent and children) that store selector values for a Page fieldtype. An example would be a list of countries that would be used to populate a countries drop-down select field. The fields might include: Country Name, 2-digit code, 3-digit code, number code. I would like to suggest a place where we can post json files to be shared and updated - maybe a dedicated github repository? Start of a repo of lists ready to import is now available: https://github.com/adrianbj/ProcessWirePageLists It might handle migrating other simple pages trees as well, but it should not be considered a tool for migrating general pages as it does not handle associated files, nor does it handle fields which store arrays. Probably lots of other things it doesn't handle either It now handles migrating all (I think) field types, including repeater fields, page fields, all Profields fields, multi-language versions of fields etc. The only omission is the actual uploaded files and images in file/image fields. WARNING: This should be considered an Alpha module - please don't use this on a live site at the moment and be sure to back everything up before testing. Would appreciate any feedback on the concept, the code, and the idea of a shared and community edited resource of these files. Also, would love to hear what page lists would be good to share. Here are a few quick ideas: States (separate files for each country) Measurement units Languages Religions Race Academic subjects (chemistry, biology etc) Publication types (book, journal article, newspaper article, newsletter, thesis etc) Car makes and models Anyone have a better idea for a name, or how to better describe "Page Lists"?

Hi folks This isn't a new concept, but since I use this on several sites and was getting frustrated by having to add the fields and put the CSS in the admin template's CSS file to have it overwritten on updates I thought I'd make it into a module where it should work regardless of which admin template you use and shouldn't be affected by updates since the CSS to hide the fieldset's container styles is now in a separate CSS file completely. Unfortunately I can't find the original topic where this concept was introduced (if anyone can find it, please link to it as I can't take credit for the idea), but essentially what the module does is create a left and right columns that are actually fieldsets, and you simply add the fieldsets to your template and place fields in each of the columns to suit yourself. Enough chit-chat, the screenshot below will explain it better: I think when this was originally discussed it was back before ryan had introduced field widths, but I think this still has a place for where you have differing heights of field (as per the ASMSelect field on the right of the shot) where using field widths would result in a space before the next row of fields. In fact, this works especially well on pages where you have small bits of information to enter and want to leave a larger left column for text editor, image and file fields. The beauty of now having variable width columns per-template now as well is that you can change the fieldsets from their set widths of 70% and 30% respectively to whatever suits your needs on a particular template. Download from the modules directory. Usage Download and install the module above Add admin_column_left and admin_column_right fieldsets to your template and put the fields in the relevant column fieldsets (Optional) change the field width for either column, taking care to leave 1% for a gap between the two columns (default is left column at 70%, right column at 29%) That's it!

owzim: one thing you might want to mention. We (www.avoine.fi) are company with around 2.5 - 3 million euros revenue for this year. Good part of that (all client websites and -services) comes from ProcessWire. We have also build lots of new software using ProcessWire. Fully dedicated to this platform in many ways: 5 developers working with ProcessWire, sponsoring the core development and also contributing to the core and releasing open source modules. And I see "strong leader" model as a strength for ProcessWire development. Software development is not road building: you don't do it faster nor better by throwing more people to the mix. It of course requires that we have great leader, and that we certainly do have!

Making a multilingual site with an extranet, very snappy with Processwire. http://www.goer.fi/ design by Nordenswan & Siirilä http://www.nordenswansiirila.fi/ -- Mikael

A million times this! Of course, you can't tell someone they're perhaps being lazy in real life if you want to work with them, but as I read the first post and before seeing ryan's my first thought was "I bet the design agency would prefer to play it safe" which is understandable to a degree and probably true of many. I've only worked for a web development company once, and I had the good fortune that they listened to me when I said I could save them time with a CMS (this is back when I was using MODx). If I could take ProcessWire back in time with me I'd have saved them even more time and money! Seriously though, it might not hurt to say to them some of the things that have been mentioned above in terms of security and stability. What I'd add to that is that ProcessWire is built for today's web technology - there are many other CMS' out there still supporting legacy versions of PHP and crippling themselves (by comparison) by not being able to leverage the advancements in PHP's core in recent versions. I would submit that ProcessWire is the forward-thinking person's CMS of choiceTM in this regard. It's not hampered by legacy code and the thing that I still love is that it's been so wonderfully abstracted that even if PHP6 was a total rewrite that turned every function on its head and renamed most of them it wouldn't change your API calls, because we access the data through the PW API then the API would still be the same (ryan would have quite the headache in that fantasy scenario, but the API is actually a safety net to a degree - nothing in the core would be deprecated in the future from what I can see as there's simply no need - it's that abstracted and has been built extremely sensibly in the way that it reads). What I would suggest owzim, time-permitting, is that you put together all these points for this or other agencies and maybe even offer to build something for them to show how fast sites can be developed. Speed and ease of use are two of the biggest selling points for the people who are going to part with the cash, and for agencies ease of use also means other workers can easily learn the system. Then you're giving the agency the tantalisingly juicy apple of saving time and therefore making more profit. Onto democracy, totally agree. Without leadership things can stagnate in a pool of good-natured suggestions and resultant inaction or, worse, people working in silos and doing their own things. I think on a project like this the thing is that as long as you don't get too despondent when an idea isn't included in the core then you'll get on juuust fine, but feel free to keep suggestions coming

This design direction is really looking good. It's as good of a replacement for the default admin theme that I've seen, and I think it could be a good direction for us. I agree with Antti, that I liked the reduction of the borders from the latest version. I did kind of prefer the icons in the page list actions, though am thinking it might be good to just have 3 configurable options there: text only, icons+text, or icons only. I think that the screenshots do demonstrate that a sidebar page-list is workable with condensed indents–it actually looks pretty great. But I'm not convinced it's workable on the technical side–I think we'd have to go with frames in order to avoid having to re-render that page-list on every edit. And even then, we run into issues, like when and how to refresh it automatically (like when a title is change for instance). Though I'm sure it's all solvable one way or another, and I think we should give it a chance and see where it takes us. Other elements that I think would be useful would be things that Soma has already done with his Teflon theme. One example I can think of is the drop downs that let you go straight to a template or field. I know the concepts shown here don't get down to that level of granularity yet, so just mentioning things I've liked. I know some people like the current minimal admin theme, and I am one of them (I can't seem to use anything else for more than a few minutes). But the default admin theme has to be one that markets us well, and apparently the current one does not have the broad appeal it needs to have. If there's one thing that comes up more than any other when people are checking out ProcessWire for the first time, it's a general aversion to the admin theme. This has been the case since the beginning. I don't understand it, but I think the current admin theme is the only thing preventing wider adoption of ProcessWire. There's a large segment of users out there that judge a product on how it appears to their subjective design sense, and they don't bother looking further if the admin look doesn't excite them. So what we need is something that draws people in rather than halts them from looking further. That's not to say that the current admin theme is bad (I quite like it myself), but that the current admin theme must be an acquired taste–something probably better as a 3rd party theme option rather than the default one. Diogo and I may keep using the current admin theme, but the time has come where we need a different default theme to increase our user base. There are several other admin themes that already exist that could accomplish this already. But like has been mentioned above (and by others before) there is also a need to optimize and improve some of the framework elements behind it all. So building a new default admin theme is best done with a little bit larger scope of changes than would usually accompany an admin theme. I'm not interested in switching away from jQuery UI, but would support inclusion of another minimal framework to provide more foundation both to grid and typography–the things that jQuery UI doesn't do, and isn't designed to do. I'm not sure what framework would be right, or if homebrewing would be better. Regardless, if we were to start developing a new default admin theme from scratch, I think Philip's design here is a good direction to build from. I don't have the bandwidth to get involved with this anytime particularly soon, but it should maybe be a top priority after release of ProcessWire 2.4.

I personally think that the way that the current ProcessWire admin functions is exactly how it should continue to function, I'm not a fan of the always available page tree (or any kinda of extra clutter really), I've rarely had a client I was confident could understand/effectively utilize such a feature anyway. I get fewer calls about "CMS confusion" with processwire than I ever have before with ANY platform (yes, even WordPress). Though developing a new admin theme that may make itself more conducive to the addition of such major features would be great, if doable?(I'm not master programmer so I have no idea) I really think this simplicity is key in a default shipping product. Also making the default theme clean/minimal would also potentially make small visual changes easier for developers. My concerns about the theme don't come from a function stand point as I think some of the ideas floating around in these forums serve more to solve developer issues than client issues, and in the end our primary concern, particularly for the default theme, needs to be client experience. My concern is that honestly I was one of these superficial types that overlooked PW because the admin wasn't "cool" or "slick" enough for my tastes. There was probably a 3-4 month period between when I first discovered PW and watched the intro video to when I ended up back here out of my continued search for a "custom post type/custom content" CMS. This second time I took a peek around in the forums to realize that PW supported admin themes, I was in. Between Futura Remix and at the time a preview post for Ergo I knew I could be happy with the look of PW. But obviously not perfectly happy as I was still motivated to go on to make a few of my own (one particular motivator was the use of Jquery ui and its awful awful icons). And frankly in general jqueryui is a bit ugly and very dated looking (though I can understand the concern of moving away from it, seeing as how much code would need to be rewritten). The point before being that there is a very real risk of loosing out on new users because of this (just look at the CMS "Craft" which recently got tons of attention in a bunch of webdev blogs and yet has no single feature that processwire doesn't except it has a gorgeous admin interface, AND you have to PAY for almost all the other good features!). I think one thing that happens is people can't so quickly understand how amazing, flexible, straightforward, powerful and generally beneficial the PW API is, but what they can understand immediately, is whether or not the CMS admin panel is cool, clean, slick, simple, sexy.... whatever. And I think PW falls short here, its not terrible, but its nothing exciting. There are certainly plenty of CMS' to draw inspiration from though: Symphony CMS, Kirby admin panel plugin, Craft, Statamic, Anchor CMS... I'm sure there are more. I think the most effective place to put effort for now it a simplified cleaner rewrite that better supports 3rd party admin themes, no more specificity battles (there should be no need for the use of "!important" in the default theme, or at least very little). This combined with the ability to have "Admin Theme settings" and a per user admin theme selection could really fix most of the concerns floating around (at least I think so...). I really think something that takes the colors from the new processwire.com and a bit of inspiration maybe from others could really nail it. Oh and, I really think switching to an icon font would be smart..... and ditching jqueryui.... I'll stop here... phew.

A responsive and minimalist photographer portfolio. http://mikael.siirila.net/ (and if you like the photos, follow me at http://www.facebook.com/mikaelsiirila/) -- Mikael

Yeah also wanted to mention but thought not overkill the thread. You can use also use the new pw log functions. $log->save("mylog","test") // will save test to mylog.txt

I agree I think this could be cool. The profile exporter is great if you want to copy an entire setup, but it would be great for example to be able to "install" the pages/templates/fields for an image gallery from an existing site onto a new site with a couple of clicks at any point in the development of the site (unlike the site exporter where it is the entire site and you need to do it at the start). Perhaps I could also add an option to just export/import the page/template/ field structure without the data! I'll have to experiment with this in the next few days. Thanks for the feedback

My mind works in mysterious ways Not every site I build is the same, there are always subtle differences. For things like blogs and galleries being able to export a basic page heirarchy (& fieldset) and recreate it on a new site build would be a huge, huge time saver.

What, all these posts and no one actually welcomes u to PW? Welcome to PW and the forums Gregory!

Before reading your replies, I wanted to send the user's local time back to php, then run a bunch of astronomical calculations on the server, then refresh the visitor's page. But that's 2 reloads after the 1st one, and it looks suspicious when a page blinks twice. Ajax might work without refreshing, but it's beyond me. So I've thought of a work-around by doing the .php calculations using UT time, then make adjustments in .js based on visitor's UToffset. ProcessWire is awesome. Thanks guys, Gregory www.1au.com

I totally understand what you mean but just to clarify for those who may not ....Diogo is not saying things are not democratic here at PW..just that final decisions are made by the lead dev... . I don't need to remind us all that Ryan is very quick to listen and thoughtfully respond to requests, criticisms, etc. Sometimes I feel he bends over backwards to accommodate our many requests.... That has been my experience. Anyway, I digress, again, sorry

Thanks, it looks like I've got a few more updates to make! Actually just checked, and it looks like I've already made them but just not committed them. Though a couple of those are actually just commented out versions of live() that have already been replaced. I keep the old commented version just because I find live() easier to read and comprehend what's going on. I'll go ahead and commit the rest here shortly. I'm running jQuery 2.x locally, with the migration plugin. I plan to include the latest 2.x jQuery with PW 2.4. I haven't yet found any others, though that might be because I'm still using the migration plugin to identify stuff that needs updating. But I'm not married to the fancybox plugin–we'll replace it with something else.

404 pages serve an important purpose from an SEO standpoint. So if this is a public facing site, I'd recommend maintaining a proper 404 page rather than just redirecting to or displaying the homepage. You could always have your 404 page link to your homepage or even meta redirect to it after a few seconds.

Hi Nico, Would it be possible to make it so that when pages are in trash, clicking delete permanently deletes the page rather than "re-trashing" it? Either that or perhaps not show the link when a page is in the trash? Thanks!

I'm not sure what's the issue you're talking about, nor if you want to or use admin to delete pages, as it will trash them and not delete them. So my example is just working for all hooks either trash or delete, just a question if you want the user page to be deleted if the page gets trashed or deleted. Looks ok, you could also use Pages::saved or Pages::saveReady (look at core/Pages.php to read the docs what they're doing), the problem seems more that you're doing a save() in your hook so it will trigger you save hook also. SO it will create user, save user, call save hook, update user. I'm wondering why you don't get a endless recursion (?) That's is simply to prevent recursion or in case the hook get's called multiple times. We could also avoid this differently, but it gets the job done. You could also write: if($page->thispageisalreadyudpated) return; // do nothing $page->thispageisalreadyupdated = true; edit: updated code

Have been vacationing in the Algarve region twice and i must agree, Super Bock blows Dutch lager out of the water. Then again, maybe the beers just taste better on a vacation, no matter what brand you have

This works for me $this->pages->addHookAfter('deleted', $this, 'deleteUser'); public function deleteUser($event){ $page = $event->arguments(0); if($page->skip) return; // to prevent multiple calls when using Pages::trash(ed) $page->skip = true; if($page->template == 'student'){ $this->message("Page name in trash $page->name"); $name = str_replace("{$page->id}_", "", $page->name); // strip out the id_ in name $u = $this->users->get($name); if($u->id) { if($this->pages->delete($u, true)) { // maybe recursive in case user has children $this->message("deleted user $name"); } } else { $this->error("user $name not found"); } } } This same code also works with this code $this->pages->addHookAfter('delete', $this, 'deleteUser'); $this->pages->addHookAfter('trashed', $this, 'deleteUser'); $this->pages->addHookAfter('trash', $this, 'deleteUser'); Just depends what you need.

Maybe we can make the base color adjustable. A single line of CSS or a line in $config. Here are the only PW blue, green or black versions: I wouldn't make the topic more complicated than it is. We can right now customize the admin theme and write modules. This discussion is good, because we ould create some interessting ideas for future modules - build for the backend of PW. The idea of a blank admin theme is great. This could be layed out as a kit to develop your own admin theme. (In addition, PW could ship with a theme created on top of this blank master).

In the above code I have forgotten the channels, so the correct code could be: function getMaxMem() { // read PHP maxMemory from php.ini $sMem = trim(ini_get('memory_limit')); preg_match('/^[0-9].*([k|K|m|M|g|G])$/', $sMem, $match); $char = isset($match[1]) ? $match[1] : ''; switch(strtoupper($char)) { case 'G': $maxMem = intval(str_replace(array('G','g'),'',$sMem)) * 1073741824; break; case 'M': $maxMem = intval(str_replace(array('M','m'),'',$sMem)) * 1048576; break; case 'K': $maxMem = intval(str_replace(array('K','k'),'',$sMem)) * 1024; break; default: $maxMem = intval($sMem); } return $maxMem; } function checkMemoryForImage($imageFilename, $maxMem) { // images pixel $size = getimagesize($imageFilename); $channels = isset($size['channels']) && $size['channels']>0 && $size['channels']<=4 ? $size['channels'] : 3; $imgMem = $size[0] * $size[1] * $channels; // read current allocated memory $curMem = memory_get_usage(true); // memory_get_usage() is always available with PHP since 5.2.1 // check if we have enough RAM to resize the image return ($maxMem - $curMem > 2.5 * $imgMem) ? true : false; } $maxMem = getMaxMem(); foreach($imageFiles as $imageFile) { if(!checkMemoryForImage($imageFile, $maxMem)) { throw new WireException("Cannot load the imagefile {$imageFile->name} into Memory! Imagedimensions are to large."); // or e.g. with modules use $this->error("Cannot load the imagefile {$imageFile->name} into Memory! Imagedimensions are to large.") continue; } // do the resize ... }

The next version of PiM will be able to enhance the Thumbnails module (after I have successful send a pull request to apeisa and he have had time to check and implement the code, - hopefully) While writing on the (optional) support for PiM with Thumbnails, owzim has written the js-code that rebuilds the crop rectangle, - and also he has tested and forthrightly commented my various tests with that. Thumbnails will recognize if PiM is installed and use a different routine then. And without PiM the Thumbnails Module will use the PW core ImageSizer. Since dev-version 2.3.3 the ImageSizer uses automatic sharpening after resize. So - once after updating to the new module and a newer PW version (dev 2.3.3 or stable 2.4) everyone has sharpening support. We both (owzim & me) want to have the coords & data stored and pre-selected when coming back to a previous created thumbnail. We use a wrapper class with a read and a write method on a session basis to achieve that. (After closing the browser or otherwise destroy the session, all data is lost) But together with PiM the coords and options can be stored permanent! It can be stored as metadata in a IPTC custom field (2#215) with the original imagefile. If you want enable permanent storage you have to create a config array named imageManipulatorOptions in your site/config.php and create the key thumbnailCoordsPermanent and set it to true: $config->imageManipulatorOptions = array( // ... 'thumbnailCoordsPermanent' => true ); So, - if you don't want permanent storage, you are still able to use Thumbnails Module and PiM together, but without permanent storage. https://youtu.be/IHwjL7YSfRo EDIT: PullRequest is send https://github.com/apeisa/Thumbnails/pull/13 (the unorthodox way)

Since you guys asked for it, I'll take a stab at a case study on the development process. Most of the development was done in about a week and a half. I started with the basic profile, but it ended up being something somewhat similar to the Blog profile in terms of how it's structured. Below I'll cover some details on the biggest parts of the project, which included data conversion, the template structure, the front-end development and anything else I can think of. Data Conversion from WordPress to ProcessWire One of the larger parts of the project was converting all of the data over from WordPress to ProcessWire. I wrote a conversion script so that we could re-import as many times as needed since new stories get added to cmscritic.com almost daily. In order to get the data out of WordPress, I queried the WordPress database directly (my local copy of it anyway) to extract what we needed from the tables wp_posts for the blog posts and pages, and then wp_terms, wp_term_relationships, and wp_term_taxonomy for the topics and tags. WordPress stores its TinyMCE text in a state that is something in between text and HTML, with the most obvious thing being that there are no <p> tags present in the wp_posts database. Rather than trying to figure out the full methodology behind that, I just included WP's wp-formatting.php file and ran the wpautop() function on the body text before inserting into ProcessWire. I know a lot of people have bad things to say about WordPress's architecture, but I must admit that the fact that I can just include a single file from WordPress's core without worrying about any other dependencies was a nice situation, at least in this case. In order to keep track of the WordPress pages imported into ProcessWire through repeat imports, I kept a "wpid" field in ProcessWire. That just held the WordPress post ID from the wp_posts table. That way, when importing, I could very easily tell if we needed to create a new page or modify an existing one. Another factor that had to be considered during import was that the site used a lot of "Hana code", which looked like [hana-code-insert name="something" /]. I solved this by making our own version of the Hanna code module, which was posted earlier this week. Here's an abbreviated look at how to import posts from WordPress to ProcessWire: $wpdb = new PDO("mysql:dbname=wp_cmscritic;host=localhost", "root", "root", array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES 'UTF8'")); $posts = wire('pages')->get('/posts/'); $sql = " SELECT * FROM wp_posts WHERE post_type='post' AND post_status='publish' ORDER BY post_date "; $query = $wpdb->prepare($sql); $query->execute(); while($row = $query->fetch(PDO::FETCH_ASSOC)) { $post = $posts->child("wpid=$row[ID]"); // do we already have this post? if(!$post->id) { // create a new post $post = new Page(); $post->template = 'post'; $post->parent = $posts; echo "Creating new post...\n"; } $post->of(false); $post->name = wire('sanitizer')->pageName($row['post_name']); $post->title = $row['post_title']; $post->date = $row['post_date']; $post->summary = $row['post_excerpt']; $post->wpid = $row['ID']; // assign the bodycopy after adding <p> tags // the wpautop() function is from WordPress /wp-includes/wp-formatting.php $post->body = wpautop($row['post_content']); $post->save(); echo "Saved post: $post->path\n"; } What I've left out here is the importing of images, topics, tags, and setting the correct authors for each post. If anyone is interested, I'll be happy to go more in depth on that, but didn't want to overwhelm this message with code. Template File Structure This site makes use of the $config->prependTemplateFile to automatically include the file _init.php before rendering a template file, and $config->appendTemplateFile to automatically include the file _main.php after. So the /site/config.php has this: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; You may recognize this as being the same setup from the Skyscrapers profile. The _init.php includes files containing functions we want to be available to all of our templates, and set default values for the regions we populate: /site/templates/_init.php /** * Include function and hook definition files * */ require_once("./includes/render.php"); require_once("./includes/hooks.php"); /** * Initialize variables populated by templates that get output in _main.php * */ $browserTitle = $page->get('browser_title|title'); $body = "<h1>" . $page->get('headline|title') . "</h1>" . $page->body; $side = ''; $renderMain = true; // whether to include the _main.php file The includes/render.php file that is included above includes several functions for generating markup of navigation and post summaries, or any other shared markup generation functions. Examples are renderPost(), renderNav(), renderTags(). This is similar to the blog.inc file from the Blog profile except that I'm letting these functions generate and return their own markup rather than splitting them into separate view files. I personally find this easier to maintain even if it's not as MVC. The includes/hooks.php sets up any hooks I want to be present for all of my templates. I could have also done this with an autoload module, but found this to just be a little simpler since my hooks were only needed on the front-end. The main hook of interest is one that makes all posts look like they live off the root "/" level rather than "/posts/" (where they actually live). This was in order to keep consistency with the URLs as they were in WordPress, so that the new site would have all the same URL as the old site, without the need for 301 redirects. /site/templates/includes/hooks.php /** * This hook modifies the default behavior of the Page::path function (and thereby Page::url) * * The primary purpose is to redefine blog posts to be accessed at a URL off the root level * rather than under /posts/ (where they actually live). * */ wire()->addHookBefore('Page::path', function($event) { $page = $event->object; if($page->template == 'post') { // ensure that pages with template 'post' live off the root rather than '/posts/' $event->replace = true; $event->return = "/$page->name/"; } }); Our /site/templates/_main.php contains the entire markup for the overall template used site wide, from <html> to </html>. It outputs those variables we defined in _init.php in the right places. For example, $body gets output in the <div id='bodycopy'>, $side gets output in the right <aside>, and $browserTitle gets output in the <title> tag. /site/templates/_main.php <?php if($renderMain): ?> <html> <head> <title><?=$browserTitle?></title> </head> <body> <div id='masthead'> // ... </div> <div id='content'> <div id='bodycopy'><?=$body?></div> <aside id='sidebar'><?=$side?></aside> </div> <footer> // ... </footer> </body> </html> <?php endif; ?> We use the rest of the site's template files to simply populate those $body, $side and $browserTitle variables with the contents of the page. As an example, this is an abbreviated version of the /site/templates/post.php template: /site/templates/post.php // functions from /site/templates/includes/render.php $meta = renderMeta($page); $tags = renderTags($page); $authorBox = renderAuthor($page->createdUser); $comments = renderComments($page); $body = " <article class='post post-full'> <header> <h1>$page->title</h1> $meta </header> $page->body $tags $authorBox $comments </article> "; if(count($page->related)) { $side = "<h4>Related Stories</h4>" . renderNav($page->related); } What might also be of interest is the homepage template, as it handles the other part of routing of post URLs since they are living off the root rather than in /posts/. That means the homepage is what is triggering the render of each post: /site/templates/home.php if(strlen($input->urlSegment2)) { // we only accept 1 URL segment here, so 404 if there are any more throw new Wire404Exception(); } else if(strlen($input->urlSegment1)) { // render the blog post named in urlSegment1 $name = $sanitizer->pageName($input->urlSegment1); $post = $pages->get("/posts/")->child("name=$name"); if($post->id) echo $post->render(); else throw new Wire404Exception(); // tell _main.php not to include itself after this $renderMain = false; } else { // regular homepage output $limit = 7; // number of posts to render per page $posts = $pages->find("parent=/posts/, limit=$limit, sort=-date"); $body = renderPosts($posts); } The rest of the site's template files were handled in the same way. Though most were a little simpler than this. Several were simply blank, since the default values populated in _init.php were all that some needed. Front-end development using Foundation 4 The front-end was developed with the Foundation 4 CSS framework. I started with the Foundation blog template and then tweaked the markup and css till I had something that I thought was workable. Then Mike and I sent the _main.php template file back and forth a few times, tweaking and changing it further. There was no formal design process here. It was kind of a photoshop tennis (but in markup and CSS) where we collaborated on it equally, but all under Mike's direction. After a day or two of collaboration, I think we both felt like we had something that was very good for the reader, even if it didn't originate from a design in Photoshop or some other tool like that. I think it helps a lot that Foundation provides a great starting point and lends itself well to fine tuning it the way you want it. I also felt that the mobile-first methodology worked particularly well here. Comments System using Disqus We converted the comments system over to Disqus while the site was still running WordPress. This was done for a few reasons: Disqus comments provide one of the best experiences for the user, in my opinion. They also are platform agnostic, in that we could convert the whole site from WP to PW and not have to change a thing about the comments… no data conversion or importing necessary. Lastly, ProcessWire's built-in comments system is not quite as powerful as WordPress's yet, so I wanted cmscritic.com to get an upgrade in that area rather than anything else, and Disqus is definitely an upgrade from WP's comments. In order to ensure that Disqus could recognize the relations of comment threads to posts, we again made use of that $page->wpid variable that keeps the original WordPress ID, and also relates to the ID used by the Disqus comments. This is only for posts that originated in WordPress, as new posts use a ProcessWire-specific ID.

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.

Hey Pete you mean this: http://processwire.com/talk/topic/4398-two-column-admin-theme-concept/?p=43209 this concept is even simpler

I think I have found a small bug with this. It only affects sites that have $config->pagefileSecure = true; and if you are using the paste option, instead of uploading the csv file. This line is the problem: $csvFilename = $this->config->paths->files . $this->page->id . '/data.csv'; Obviously it is not accounting for the "-" that is prepended to id of the page in the admin /assets/files/xxxx folders. This seems to fix it: $csvFilename = $this->config->paths->files . ($this->config->pagefileSecure ? $this->config->pagefileSecurePathPrefix : null) . $this->page->id . '/data.csv';

I'm going to ignore the field completely and jump straight to shouting: THANK YOU SO MUCH FOR DEPENDENT SELECTS! This is yet another awesome feature I've been silently wishing for for a while - one select field causing a filter on another (which I'm guessing works also for just two regular select fields and doesn't rely on this fieldtype?). Loving how, logically, when the first select field doesn't have a value the second simply isn't shown. Back to the module - I love that too, but one select filtering another one opens up a new world of possibilities so I'm ecstatic with that by itself

It looks like this fixed the problem. Now making a field required and setting the "Required only if..." in conjunction with "Show this field only if..." seems to work as expected. It seems to handle the column width fine again.

You can not know the client time at the point when the server is first hit, it would require two pages/requests - the first to serve the javascript and the second to recieve the result of the javascript. That is why it's much eaiser to pass PHP time() to the page as a javascript variable and let the client-side handle the locale, if you need to syncronize. <script type="text/javascript"> var d = new Date(<?php echo time(); ?> * 1000); document.write(d.toLocaleString()); </script> If you must do it the other way around, you can redirect to the session - but it's a bag of worms. I'm using a non-processwire session to keep the example simple. <?php session_start(); if( !isset($_SESSION['client_time']) && isset($_GET['client_time']) ){ $_SESSION['client_time'] = $_GET['client_time']; } ?> <script type="text/javascript"> var server_time = '<?php echo addslashes($_SESSION['client_time']); ?>'; if (server_time === ''){ var d = new Date(); window.location = window.location + '?client_time='+encodeURI(d.toLocaleString()); } document.write(server_time); </script> EDIT: Beaten by Adrian and Pete, also good answers.

The first option won't work because php is server-side and runs before the page loads. The second option has potential, but you are echo'ing: $input->post->utoffset; when the name of your hidden field is "vt" and not "utoffset".

I completely agree with Antii that this is one of the strongest points of PW. Democracy in Open source projects can some times take to delayings and strange decisions. I think it's great that all final decisions are made by one person that knows very well in which direction the project should go.

To be honest I use the default theme, not because I dislike the others, but mainly because it's the default. There are two main reasons for this: one is that it represents PW (in a "corporate identity" way), the second is because I trust it will break less then the others with PW updates. As much as I like to try, and to see that there are nice themes being designed for PW, unless one is much better, I will stick with the default. This is one of the reasons I would prefer to see the default theme evolving, than a proliferation of alternative themes, and that's also why I'm happy that Philipp started this (being is ideas used or not). That said, I do agree that the admin should be more appealing to newcomers and easily tweakable to have different appearances by changing colors and typography (business (Nico's colors are a great example), fun, serious, etc). I even think that the default install could offer 4 or five alternatives, besides of those that would be shared by users, I'm talking maybe a small json file that could be imported by the system to change it's appearence (a bit like Philipp's color changes, but maybe more profound). What I'm talking here are not different themes, but variations of the same (default) theme. IMO the possibility to easily make these kind of changes, would allow us to maintain the recognizable PW colors on the default appearance of the default theme. This is for me an important point: the PW corporate feeling should be kept. I also want to remind Reno's small tweaks for the edit page. I think they work great: http://processwire.com/talk/topic/2002-repeating-events-multiple-datestimes-for-datepicker/?p=18862 This post went too long. I'm sure it's a mess...

Easy just thought this us a important fix. I'll look into it and test. Maybe I can work it out.

I've committed an update that I think should fix this–please let me know if you still experience it. I wasn't able to duplicate exactly what you are talking about, but it was more just a matter of available time, and think I knew what the issue was. Just looking for confirmation that I fixed the right thing, but definitely found an issue that needed fixing either way. I'm not sure I understand the question/comment/request? I think it probably depends on the situation. But there are likely several scenarios that won't work when it comes to repeaters, because repeaters manipulate the field names behind the scenes, and both the definition of dependencies as well as the JS require the original field names to be in tact.

Regarding the debugging element to this thread, "error_log()" is one of the things I find incredibly useful. Very handy way to spit out the value of a variable, or even just "test" at a certain point in the code to confirm that bit is being processed. This is useful for times when it is not easy to echo content to the page for whatever reason, or if you are **shudder** trying to fix something on a live site and don't want the output littered with your debug code as you are working on it.

Neat! I have used this UI pattern many times in the past - it'll be awesome to have this ready to just drop into a PW site To your knowledge, does this UI pattern officially have a name? I usually refer to these as "stock lists" or "swap lists" when talking to clients...

Looks cool, thanks for your work here. We got this discussion already to export and import template/fields and I think Ryan said we could build something with json or yaml. I'm not sure anyone else has started something but this could be a start. Just briefly looking at the code it looks good. I'm not sure I understand why you have functions inside a class method? I'm sure it works but seems odd. Also I'm not sure you are aware you can get template and fields with their settings with $field->getArray() $template->getArray() that will return an array with the properties. This might can be used to store them, though not sure it would be of help. wire("templates")->get("basic-page")->getArray(); Would give something like: Array ( [useRoles] => 1 [editRoles] => Array ( [0] => 1006 [1] => 1675 ) [addRoles] => Array ( [0] => 1006 [1] => 1675 ) [createRoles] => Array ( [0] => 1006 [1] => 1675 ) [childrenTemplatesID] => 0 [sortfield] => [noChildren] => [noParents] => [childTemplates] => Array ( ) [parentTemplates] => Array ( ) [allowPageNum] => 1 [allowChangeUser] => 0 [redirectLogin] => 0 [urlSegments] => 1 [https] => 0 [slashUrls] => 1 [altFilename] => [guestSearchable] => 0 [pageClass] => [pageLabelField] => [noGlobal] => 0 [noMove] => 0 [noTrash] => 0 [noSettings] => 0 [noChangeTemplate] => 0 [noUnpublish] => 0 [nameContentTab] => 0 [noCacheGetVars] => [noCachePostVars] => [useCacheForUsers] => 0 [cacheExpire] => 0 [cacheExpirePages] => Array ( ) [label] => [tags] => [roles] => Array ( [0] => 37 [1] => 1006 [2] => 1675 ) ) Also this is possible wire("templates")->get("basic-page")->fieldgroup->getArray(); wire("fields")->get("body")->getArray(); Not sure how about template context settings. Anyway it would be a lot more work if you want to cover all settings.

Yea, Ericsson have already done the same, and is now all about their telecom network infrastructure, and I don't think they miss the phones much. Kind of like Volvo and Saab/Scania mother companies getting rid of the car divisions to focus on where they have actually made a lot of money over the years (trucks, buses and such). Could end up making Nokia much stronger over the long haul, let's hope so. I recently had the pleasure of playing golf with the guy who has had the Nokia distribution in Finland for many years. The last few have been tough, but I think he has seen enough sunshine to make it through a few rainy days without much sorrow.

Interesting thought Marty - I hadn't considered that at all, but I don't see why not Of course it would mean all the fields would initially be added to the template of that child page, but I guess no big deal. I wonder whether it would be worth taking it beyond its original goal and give it the ability to export all levels of children, grandchildren, great grandchildren etc, so an entire site of pages, templates and fields could be migrated. Obviously there are lots of issues to make this work, and is not why I built this. If I tried for that functionality, it would still fall short of the Profile Exporter, because it wouldn't support copying of template and other files, but it might still be a useful tool.

Kongondo, add continue; to your list http://php.net/manual/en/control-structures.continue.php Edit: you had two different blues. I chose the lighter if you don't mind

Sorry to digress, but I just want to thank and agree with Soma here. He mentioned this on some post I read and it has really helped me with my coding. foreach used to be my best friend but now, exit; is my best friend closely followed by var_dump and it's cousin print_r. Add these to the knowledge that PHP and PW provide very useful messages when an error occurs, so far, these are all the debugging tools I need . So, thank you Soma!

It's easy to make a module just for the purpose of holding settings and that way you get a nice user interface for them in the admin area. Good clues in the wiki: http://wiki.processwire.com/index.php/Module_Creation#Example_of_a_configurable_module $settings = $modules->get("MySettings"); echo $settings->greeting;

<quote style='diogo'>I dislike looking for a piece of garlic in my fridge</quote>

Sometime I hide a big textarea field somewhere. Just for storing $key : $value pairs. Every line on the textarea is one pair. color : blue cms : ProcessWire beer : Grolsch more : etc. Add as much variable as you want.

Sublime Text 3 finally got me to convert from Textmate. Soma pointed me in the direction of the monitor file option for Sublime SFTP which is great! As mentioned above, it allows you to monitor a compiled .css file and upload it whenever there are changes - even from and external source like CodeKit. My only complaint is that the monitoring stops when the file is closed or you quit Sublime Text, but as Soma mentioned ctrl+cmd+u+m on a file you need to monitor and that's it. I use the following packages/plugins - docBlocker // comments - SFTP // file uploads - SassBeautify // indented .scss files - Sass // syntax highlighting // No need for Codekit. Compile your .css on save with - SublimeSaveOnBuild & Sass Build System - Synced Sidebar // not sure why this isn't native functionality Aside: I tried PHPStorm as well, but there is just way too much visual clutter for me. It's super powerful and I know people love it, but I felt like I was using Dreamweaver 2.

Hey all, Here's a demo of what I've built. It's become my primary bookmarking system: I didn't demonstrate it in the video, but this system works amazingly on a mobile device too. It's so easy and quick to pull up stuff I want to read when at a coffee shop or have a few minutes to kill when on the go. I found Diigo's Android App very limiting in comparison, especially since it doesn't allow you to view all of your bookmarks on the mobile app (last time I checked). I have no plans as of yet to release this, but I may in the near future if you are all really interested. There are features I still want to build out as well as a lot of code cleanup and security measures that need to be implemented. Enjoy! Jonathan

Looks like I broke the dev installer with yesterday's commit. Sorry about that. It was just an exception that needed to be caught–PDO throws an exception in a spot where mysqli doesn't, so didn't think to add one. And now realize I must have had PDO's exception mode turned off when I tested. This is now fixed.