Leaderboard

That's fun: foreach($templates as $template){ foreach($template->fieldgroup as $field){ if($field->name == "myfield"){ $template->fieldgroup->remove($field); $template->fieldgroup->save(); echo "deleted $field->name"; } } }

Little explanation of Wanze's code. Hope it helps: // total starts with zero $total = 0; // loop through all grants and store each of them in the $grant variable for their part of the loop foreach ($page->grants as $grant) { // echo this particular grant cheque_date echo "Date granted: {$grant->cheque_date}"; // echo this particular grant amount approved echo "Amount ${$grant->amount_approved}"; // add this particular grant amount approved to the total that we have in this moment (in the end of the loop the total will be the sum of all amounts) $total += $grant->amount_approved; } What you don't have in your code is "+=" that adds the amount of this grant to the total. In your code the total is always the same as the previous amount and in the end it will be equal to the last amount. -- $page->grants->sort('-cheque_date')->first()->cheque_date; For what I understand this returns the value the most recent cheque date. you can echo it directly like this: echo $page->grants->sort('-cheque_date')->first()->cheque_date; or store it in a variable $last_cheque_date = $page->grants->sort('-cheque_date')->first()->cheque_date; ...and use it later echo "the most recent cheque date is {$last_cheque_date}."; or // just a random example... if ($last_cheque_date < 165436524) { // do something }

Or we can work on a print.css for the cheatsheet. shouldn't be too difficult, and would always be on date.

Inside the foreach, you are summing up the amounts. You forgot a + in the following snippet above: $total += $grant->amount_approved; // Is the same as // $total = $total + $grant->amount_approved; After the loop, you can echo the $total variable where you want to appear it in your template. Same holds for the latest date: $latestDate = $page->grants->sort('-cheque_date')->first()->cheque_date; echo $latestDate;

Here's an example that should get you there. No time to give a more detailed explanation right now, but go ahead and ask if there's something that seems odd =). Put this into site/modules/PageFirstProductPrice.module and install the module from the admin side (check for new modules first). <?php class PageFirstProductPrice extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Copy first product price', 'version' => 100, 'summary' => 'Copies first product price from a repeater to another field', 'singular' => true, 'autoload' => true, ); } public function init() { $this->pages->addHookBefore('save', $this, 'copyFirstProductPrice'); } public function copyFirstProductPrice($event) { $page = $event->arguments[0]; // we're interested in product pages only if($page->template->name != 'product') return; // copy first product version price, if there is one with a price if(count($page->product_versions) > 0 && $page->product_versions->first()->price) { $page->first_version_price = $page->product_versions->first()->price; } else { // no items wih a price, clear the field // this is needed to keep the field in sync if all items get deleted from the repeater $page->first_version_price = ''; } } } *** Edit *** A bit too hurry as it seems I forgot to mention that my example needs a field called 'first_version_price' in your 'product' template to work. That field should be left hidden as it's populated automatically. And now that you've got a regular field right in your template it's straightforward to sort the product pages in the way you described. And horst seems to have given you the most essential pointer on hooks already, go for it! There's some pretty useful information in the wiki as well. After reading those two and looking at HelloWorld module you'll find yourself hooking away in the promised land of module development in no time.

This is why I'm currently working on a Processwire site profile based on unsemantic grid system. It claims itself the successor to the 960 grid system and promises backwards compatibility down to IE 7. My site profile still needs a little polishing but I'll than make it public on Github. Hope to have it ready by the end of this week. You can see a preview here.

It is technically possible to do all of this in ProcessWire and more, but since some of your needs are unique it would involve writing some functionality yourself. For some of your needs there is likely code available here on the forums which I'm sure someone will point you too soon (I'm typing on mobile), and for everything else the community is here to help you out. The thing with ProcessWire is that almost anything is possible, but I have to ask have you taken a look at the tutorials and familiarised yourself with some of the docs on the website to get a feel for how the system works? At some point early on you will be creating fields and templates to accomplish a lot of this. Of course if you like you could also add your requirements to the Jobs forum and it is possible someone could develop this for you, but it is always good to get stuck in and get a better understanding of the system first if you have the time.

I think you will enjoy Batcher as much as I do

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.

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

something like that ~150kb I used a standard font, made it smaller and in 2 columns, fix borders in some tables, it was a little overlined(dunno how it to say, lol). hope someone like it upd: docx

Interesting post. The only ones I use are to test for responsive design on my pages. http://lab.maltewassermann.com/viewport-resizer/

I was thinking of this when Pete created the install routines for my module http://processwire.com/talk/topic/3474-admin-custom-pages-module/?p=37140 Since we have field tags now, the modules that create fields could give them a tag with the name of the module and another tag that would be for all modules. The important here would be that all the modules use the same tag for the second case (let's say "modules"), and follow same logic for the first case (maybe the name of the module class...) I suspect that this would be the right way to create two field tags, one "modules" and one "module-admin-custom-pages". $field = new Field(); $field->type = $this->modules->get("FieldtypeTextarea"); $field->name = 'ACP_scripts_and_styles'; ... // create the field tags (the "-" before "modules" makes it collapsed in the admin) $field->tags = "-modules module-admin-custom-pages"; $field->save(); edit: my suspicion was right. It works. I will add this to the module as soon as we decide on a common tag for all modules. What do you guys think?

http://www.w3fools.com/

It seems to have something to do with the pipe character '|' in the beginning of the string. Based on a very quick test I'd say pipe isn't interpreted correctly as a first character of the value - except for native fields (id, name and so on). To solve the problem try and make sure there are pipes only in between of the values in the string.

Hi Ovi, when looking at your code and your statement of what you can do in PHP, I think you just should start here. And yes, you also should use the "Hello World Module" as a skeleton too. For example, if you want to do something that isn't implemented in PW core, you can [write | implement] your somehow into templates, or you can create a module. As it should not be a big problem for you to write your working code, you may find it not an easy task to get the right Hook. (for me it is exactly that)And at the beginning you can do it like we all do (we, who are not belong to the pro's, - we, who are not be able to cite the core code when waken up in middle of the night, - we, who we need to learn and have fun with it): we drop a post here and describe what we want to do and then get perfect answers on what Hook would be best to use for it! --- Basically a module hooks into PW somewhere and somehow. You just need to kow where to hook in and when, (before or after). And you need to know how to access objects & values and how to return your result. That's all covered in the new great API-Documentation of Hooks! Read it and just go on

Here is another one, more CSS oriented! Demo: http://leaverou.github.io/CSSS/#intro Download: https://github.com/LeaVerou/csss Website: http://lea.verou.me/2010/10/my-ft2010-slides-and-csss-my-presentation-framework/

You are saving the page? Are you getting any errors? You can enable the debug function in /site/config.php or check the /site/assets/log files.

You should substitute trabajos-parent with the selector to chose the page that is a parent of your Trabaho 1...n pages. In your case you don't even need to use a selector, it should be: $trabajos = $page->children("template=trabajo, sort=sort"); and if you only have pages with this 'trabajo' template under your trabahos page, you don't need to spacify it in your selector, so it shrinks to: $trabajos = $page->children("sort=sort");

And I've started to do it (the section for WireArray is now updated). The system Soma put together here is fantastic. Yes it can. Though I think $pages->add() is mainly useful without going to far on the fields there. I still find the regular syntax (populating the field values directly to the $page object) the most readable. I'm a little confused, as there aren't any parallels between MODX and ProcessWire in this regard. Though if ProcessWire were to stop evolving, then maybe that would be a parallel with Evo? (though glad to hear others are working on continuing Evo). No plans to stop evolving here. Switching to PDO, then namespaces and composer support is part of that evolution. This evolution is important for ProcessWire to grow and ensuring it remains the best tool for the job. All ProcessWire upgrades are optional of course. You don't have to upgrade unless you want to. I'm still running Photoshop CS3. ProcessWire is a big enough software that some changes will be more valuable to some than others, depending on what you are doing with it. As ProcessWire evolves, sometimes modules that want to support it will also have to evolve. As for now, FormBuilder is the only module I'm currently aware of that had to be updated in order to keep working with this version. That's not really a surprise, as FormBuilder is probably the most complex PW module out there. There may be more, but none that I've come across yet. What I'm much more shy about is doing anything that would require changes to one's site templates. I see API syntax as locked for changes, but not additions. We would version the API if any major syntax changes were ever necessary. So upgrading from one version of PW to another should rarely if ever require changes to your own site templates, unless your site templates are doing some very low level stuff. As for server, PHP 5.2 was EOL'd by the PHP team more than 3 years ago. They are no longer updating it. Meaning, none of us should still be using it, at least not for current projects we are maintaining or keeping up-to-date. Trying to maintain PHP 5.2 compatibility through future versions would be a drag on the project and people's usage and perception of it.

It doesn't support repeaters. If you want to create new forms that don't already exist on the site, then you need to have some kind of administrative access. It does support access control for administrative users though, enabling you to have various levels of administration. For example, you could have a user that can browse entries, but can't edit the form. I'm not sure I totally understand, but if that user role has some kind of access to the admin, you could assign whatever FormBuilder permissions you wanted to them. But keep in mind that administration of forms is really intended for administrators. Hidden fields are supported. Hooks are also supported (like in the rest of ProcessWire), enabling you to modify what gets populated to a field before it gets saved. There is no "edit mode" except to administrators. When a user submits a form, they can't come back later and change their answers, for example. It may be possible but I can't say for certain. I would suggest sticking with whatever code your payment provides gives to you. You could always experiment with it to see if you can make it a FormBuilder form, but I wouldn't depend on it. Payment processors will probably want you to use their code.

I've pushed and update to the dev branch so that sorting should now work across languages. Previously, calls like these would still result in the returned pages being sorted by the default language field, regardless of the user's language: $pages->find("..., sort=name"); $pages->find("..., sort=title"); $pages->find("..., sort=pageref.name"); $pages->find("..., sort=pageref.title"); // and so on To demonstrate the problem, lets say that you had these three pages: /numbers/one/ /numbers/two/ /numbers/three/ In Spanish, those pages would be named: /numeros/uno/ /numeros/dos/ /numeros/tres/ Lets say I executed this in English (my default language): $pages->get('/numbers/')->children('sort=name'); The result would be alphabetical: /numbers/one/ /numbers/three/ /numbers/two/ If I executed it in Spanish, the order would still be the same, sorted by the English spelling (which is clearly not correct): /numeros/uno/ /numeros/tres/ /numeros/dos/ They should be sorted alphabetically by Spanish instead. With the latest commit to the dev branch, they should now sort correctly for the given language. Meaning the Spanish results would now be in this order: /numeros/dos/ /numeros/tres/ /numeros/uno/ The scope of those goes beyond page names. This also affects multi-language text fields. So if you've got a multi-language 'title' field for instance, you can sort by that, or any other multi-language field you are using, and the sorting should work properly now. It does not yet work with language-alternate fields, though I think it's probably unusual to use those fields as sorting keys anyways.

Hi, have done the first tests with templates and want to share this one as a starting point for a lightwight responsive layout. Could be good for small websites without the need of big frameworks. The zip contains head.inc and foot.inc like they are in ProcessWires Basic-Example-Profile, and 2 css and 2 js files. If you want try out just Backup the head.inc and foot.inc from Basic-Example-Profile and copy the files form zip file into templates folder.

Interesting. Thanks for sharing! I'm curious to know if others start their projects with something similar?

hmm, the most links in the first post are really old? Think today it's mandatory to build a site responsive. Made my first two (small) responsive projects with Kube. Easy to understand and use. Nice documentation. Not so bloated like the big ones. Also there are two demo site to learn from. Locally I'm just playing around with Pure. Also a nice slim framework. For me a small framework like Kube or Pure is really helpful. Like OF said: no need to reinvent the wheel. BTW: this thread should be better placed under 'Dev Talk' (no PW topic..)?

Currently using Foundation 4.2.1. Fully responsive, mobile first, easy to generate complex layouts, nestable grids. I've been using Foundation since it was on version 2. They've made some great strides improving the framework. Since mid version 3, I stopped coding my own. Simply because browser testing became cumbersome and tedious. While I greatly enjoyed building my own css framework, the "wars/debates" between Skeleton, HTML Kickstart, Twitters Bootstrap and other popular titles, was becoming tougher to choose an alternative to a DIY method. I just got tired of reinventing the wheel.

I feel like a padawan learning from Yoda.. ;P #lamestarwarsreferenceforthewin

What if you copy the tiny_mce_popup.js to your tinymce folder?

Antti, I think you should be able to just set that email field before you output your comments. I don't think you'd need any modules or hooks or anything like that. So lets say you had a field on your page called comments_email. You may be able to do something like this: if($page->comments_email) { $commentsField = $fields->get('comments'); $commentsField->notificationEmail = $page->comments_email; } echo $page->comments->render(); echo $page->comments->renderForm();

Hi Wanze, I have just been using Batcher with the latest dev version of PW and all is great - thanks! It's such a useful tool for site admins and I have already put it to a lot of use. The 'edit' link being a particularly strong workflow enhancement. Another few suggestions (these are only suggestions as the workflow is already good) for a future release at some point would be: Include a couple of 'quick filter' buttons such as 'Show site tree', 'Show non-admin' and 'Show all published'. These buttons would perform a search as soon as they are clicked. This would be a great feature for less technical site editors / admins who's main purpose for using Batcher would be for SEO (checking page titles and urls etc.) or for initial setup, saving them from having to perform selector queries. Extra filters such as 'Locked', 'Published' and 'Trashed'. Show parent child relationships via indented rows (could be difficult so maybe simple indented 'Title' fields would work) Thanks again for a great plugin and a real workflow enhancer.

You can since latest version of InputfieldTinyMCE add custom plugins from within outside core. It has a field "Third Party plugins" you can enter name and path to plugin , and put plugin for example into a folder /site/tinymce/... I'm not sure about adding it to the core. Since it also is a browser feature, and the plugin doesn't seem to have localized feature (most important)

for developers: cheatsheet tip of the day

You could do something like this to display all images: <?php //Display images if available if(count($page->images)) { echo '<div id="gallery">'; $n = 0; foreach($page->images as $image) { $resized_image = $image->size(236,225); echo "<p><img class='photo' src='{$resized_image->url}' alt='{$image->description}' width='236' height='225' />"; echo "<br />{$image->description}</p>"; $n++; } echo "</div>"; } More examples are available here: http://processwire.com/tutorials/quick-start/images/ This is also a useful forum topic: http://processwire.com/talk/index.php/topic,97.0.html

Hi, I'm trying to get my head around something I know should be simple. I'm working on an a site for an artist who'd like to upload a custom thumbnail for each of his images. I've added a second field called 'artist_thumbnail'. In my template I want to test to see if there's a custom thumbnail and if not get processwire to generate one automatically. PHP isn't my strong point. Am I even close with this code? foreach($page->children("limit=32") as $folio_item) { if($folio_item->artist_thumbnail) { $img = "<li><a rel='lightbox' title='{$folio_item->title}' href='{$image->url}'><img title='{$folio_item->title}' src='{$thumb->url}' alt='{$folio_item->title}'></a></li>"; } else if($folio_item->artist_image) { $thumb = $folio_item->artist_image->size(100, 100); $image = $folio_item->artist_image; $img = "<li><a rel='lightbox' title='{$folio_item->title}' href='{$image->url}'><img title='{$folio_item->title}' src='{$thumb->url}' alt='{$folio_item->title}'></a></li>"; } // Output the image echo "$img"; }