Leaderboard

This is all more PHP than ProcessWire. All that ProcessWire does is that template files have some predefined variables for nicer api. $page and $pages are among those. Includes are different beast from functions (and from modules). If you include a file, it has all the same variables than the file that included it. So if you include a file from your template file, the included file will have $page and $pages available. Functions have scope. So when you have this code in your template: <?php renderTitle(); function renderTitle() { echo "<h1>$page->title</h1>"; } It will not work, since renderTitle() function doesn't know what $page is. Here is working version of the same template file: <?php renderTitle(); function renderTitle() { $page = wire('page'); echo "<h1>$page->title</h1>"; } or always possible to pass variables: <?php renderTitle($page); function renderTitle($page) { echo "<h1>$page->title</h1>"; }

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.

I've just merged a pull request by Pete that automatically replaces the admin.php file and creates the scripts&styles field during installation. That's two steps less The version on github is now 1.0.4. Thanks Pete!!

I've got TinyMCE 4 working with PW locally on my dev branch. They've changed quite a lot on the API side, but it all seems like improvement even if it does require lots of changes to code that uses it. In some ways it seems like a different product. I need to put more work into supporting all the other options we currently support in TinyMCE 3, but so far TinyMCE 4 is looking very good.

This on is pretty thought-provoking: Dive into Responsive Prototyping with Foundation Edit: Oh, and this one even more: Responsive Comping: Obtaining Signoff without Mockups

Yep, never underestimate this sponge's absorbing power

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

Hi, There's not much to this one. It doesn't stretch the limits of PW at all but the client is very happy with how easy it is to edit content. http://walkerabercrombie.com.au/ This is my first PW site (I usually use either textpattern & ExpressionEngine) and it was an absolute joy to learn something new. Illustrations by the great: http://lewkeilar.com/ Regards Martin

Since we're on that topic, any thoughts on adding a real UI for the TinyMCE configuration? The current UI is not much better than simply typing into a text-file - there's the same margin for error, and you still need to look up keys/values in the documentation to get it right. Also missing for me, is the ability to create and share configurations - most of the time, I really want one, or at the most two configurations, for all of the fields, not one for every field. If a UI isn't going to offer an advantage (convenience, transparency) over editing a text-file, in my opinion, a text-file would be preferable, so at least you can check the configuration into source-control and deploy it easily. So a much simpler solution would be to simply provide a folder where you can place plain JS (or JSON) configuration files, and then simply pick one from a drop-down - I'd be happier with that solution than the current one, since it's the same amount of work, and addresses the issue of sharing configurations...

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.

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.

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.

Hey, The Form API has CSRF protection build in, but if you for some reason don't want to use the API you can however use the CSRF protection. Its very simple but it took some time for me to find out, so i figured i share my findings with the rest. What is CSRF? First you need to create a token and a token name you do that as following: $tokenName = $this->session->CSRF->getTokenName(); $tokenValue = $this->session->CSRF->getTokenValue(); Very simple. Now what you want to do is create a hidden input field like this: $html .= '<input type="hidden" id="_post_token" name="' . $tokenName . '" value="' . $tokenValue . '"/>'; Now this will generate something that will look like this: You are done on the form side. You can now go to the part where you are receiving the post. Then use: $session->CSRF->validate(); This will return true (1) on a valid request and an exception on a bad request. You can test this out to open up your Firebug/Chrome debug console and change the value of the textbox to something else. Basicly what this does is set a session variable with a name (getTokenName) and gives it a hashed value. If a request has a token in it it has to have the same value or it is not send from the correct form. Well I hope I helped someone.

hi all, new PW site launch: http://www.ohmspeaker.com/ some of the modules that were helpful or essential for this: cropimage formbuilder fredi importcsv minify piwik analytics procache batcher redirects version control template decorator modules manager page link abstractor sitemap xml admin custom pages markup simple navigation (for the sitemap) forum topics related to this site dev: Legacy Site URL redirects: http://processwire.com/talk/topic/3641-redirect-legacy-url-to-new-pw-page/ Clean up spelling: http://processwire.com/talk/topic/3519-use-api-to-spellcheck-whole-siteclean-up-spacing/ hashes in URLs on change selected product http://processwire.com/talk/topic/3496-help-with-url-param-change/ FormBuilder http://processwire.com/talk/topic/2904-how-to-redirect-by-id/ http://processwire.com/talk/topic/2821-3rd-party-send-conditionally/ http://processwire.com/talk/topic/2820-use-session-to-remember-form-selections/ Custom Menus http://processwire.com/talk/topic/2787-custom-menu-not-related-to-page-tree/ other notes: The skyscraper profile provided the example for how to get started with the advanced product search, a.k.a. the speaker finder. The standard search has been extended to show results in different categories. there is some use of Soma's word limiter for the news teaser text, and for making meta descriptions out of body fields, from this topic: http://processwire.com/talk/topic/3429-how-to-set-text-linecharacter-limits-in-templates/ the design is built on twitter bootstrap framework Fredi proved to be totally essential for the client, in being able to rapidly edit things without having to find things in the admin. This site is going to replace an existing site on a different domain (ohmspeakers.com). At some point we weren't sure if/how we would be able to handle the shopping cart element, and then found foxycart, which proved to be the best choice, very flexible, and easy to implement for this type of site. FC is hands down the simplest and easiest way (imho) we could achieve things like the legacy product pages, where there are various parts and upgrades displayed on 1 page. this version is sort of a "v1", and will be expanded/improved a lot for a v2, which would happen in about 4 months.. BTW - these speakers are really good; i now own 3 pairs ... they look great and do sound totally amazing...! -marc

Did some digging about css frameworks in google. Found some links that might be usefull to read. 2 good articles about css frameworks http://coding.smashingmagazine.com/2007/09/21/css-frameworks-css-reset-design-from-scratch/ http://www.gridsystemgenerator.com/ do it yourself css layout http://designshack.net/articles/css/rolling-your-own-grid-layouts-on-the-fly-without-a-framework/ interesting css frameworks http://www.bluetrip.org/ http://www.devarticles.com/c/a/Web-Style-Sheets/Introducing-the-BlueTrip-CSS-Framework/ http://daneden.me/toast/ https://github.com/coyr/nivelstyle https://code.google.com/p/logicss/ http://toddmotto.com/introducing-superbox-the-reimagined-lightbox-gallery/

No worries

Have you seen any interactive TinyMCE configurations anywhere? I'd be interested in checking them out for ideas. It seems to me that TinyMCE's configuration options are such that it's not worth trying to build an interface to it. Such an interface would be overwhelming to both user and developer. I actually kind of like having a passthrough giving fields to cover the major configuration components, like we've got. It means TinyMCE's docs and support are still applicable, rather than us being responsible for every single possible option and supporting all them ourselves. But I also like the idea of pointing it to a custom JS file, for the reasons you mentioned. Though as an option, because I think it'd probably be overkill for many (including me) that usually only add an extra button for <hr> or something like that. But I'll plan to add this option.

'email' isn't in a fulltext index like 'data' is. So the fulltext index operators *= and ~= aren't going to work there. But if searching out a full email address, you are doing an exact match and would just want to use "=", i.e. $search = $pages->find("comments.email='me@tomrenodesign.com', sort=-created"); Or for a partial match, use the LIKE operator: $search = $pages->find("comments.email%='tomrenodesign', sort=-created"); I haven't tried it, but I think that should work.

Meant 2.4. Thanks

Greetings everyone, Thanks for this discussion -- especially the parts about skipping Photoshop! I can't tell you how many times I have done work for agencies where the Photoshop mockup doesn't actually look the way the live site will look. Unless you are doing a "sketchy" mockup in something like Balsamic, the whole point of a mockup is to closely represent the site. Otherwise, it's just a nice bit of impractical artwork, and then you have to explain to the client, "Well, that was just a mockup..." I never understood that. I've always favored building live sites as "mockups" or "test sites." Regarding CSS/JS frameworks: I still don't use any of them. But every discussion like this makes me feel that I need to start. And here we have another advantage of using ProcessWire! Because it is so easy to create whatever designs you want with ProcessWire, it's pretty easy to mockup a few versions of the site you're working on. Thanks, Matthew

I think the issue is that you were specifying "comments.text" rather than just "comments". You don't need to specify a subfield when searching comments. This should already work (and it is implemented in 2.3): $pages->find("comments*=SomeStringHere, sort=-created"); There isn't actually a "text" field in the DB, which is why your search wasn't working (it's called 'data' instead). I have gone ahead and pushed an update to the dev branch that looks for ".text" and substitutes ".data", so that nobody else should run into that issue.

... and if it still doesn't work, call as children of their parent (i'm assuming they have the same parent) $trabajos = $pages->get('trabajos-parent')->children("template=trabajo, sort=sort");

Try to add sort option to your selector (sort=sort or sort=-sort for reverse order): $pages->find("template=trabajo, sort=-sort");

$page or $pages work fine in Template Files as long as the they are outside functions. Your Template File can contain functions. Use wire() method in functions (or in your own class). Hence, both wire() and $page/$pages can appear in the same Template File if you so wish. EDIT: Apeisa was faster

Soma, looks like it depends on the first field of the selector: if that one is native then other native fields work as well ("name|custom_x|template=..." works). But if the first field is custom, then only custom fields may follow ("custom_x|name|template=..." does not work). There's a todo comment in PageFinder.php regarding native fields not being multi-field aware (https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/PageFinder.php#L215), so it's technically not a bug but a known missing feature. It's even halfway done, just needs fields in certain order.

I don't think that's possible with a single find as you'd need an or-selector like this (this is a pseudo selector, not an actual one): "template=match OR (template=notification AND notification_type=something), ...". One way is to use two find() calls and merge the resulting PageArrays but that isn't necessarily an option as you obviously need to sort and limit in the database (or at least you're doing it now). There is a trick you could probably use to get over the limitation in this case. This is clearly a hack so you have been warned =). create a field 'fake' of type integer and add it to the template 'match' make sure every page with template 'match' has the same value for field 'fake' ('-1' for example). Choose a value that never exists in field 'notification_type' (you'd need an autoload module just for filling the field 'fake'...) use a selector like this: "template=match|notification, notification_type|fake=something|-1, summoner_id=$summoner_string, sort=-create_date, limit=15" Now that's one hell of a dirty saturday night trick isn't it? But it works. I truly hope someone comes up with a better alternative. Or that you could live without those sort and limit selectors and use two finds instead of one. *** Edit *** Actually I just found a bit cleaner way, one without a fake field. Assuming field 'notification_type' can't have value of 'match' you can use this selector: "template=match|notification, template|notification_type=match|something, summoner_id=$summoner_string, sort=-create_date, limit=15" It's a trick as well, but not a dirty one anymore. Do note that there seems to be a limitation with builtin fields (or something else weird): you have to use 'template|notification_type', as using them the other way around results in an error "Field does not exists: template". I'll experiment on this a bit more and file an issue if it seems to be a bug.

That has been my nightly reading for the past two weeks.

You could do something like: Maybe: <?php $shortcode->add('quote', function($atts) { $quotes = array(); function replaceQuotes($matches) { global $quotes; $quotes[] = $matches[1]; return '['.(count($quotes-1)).']'; } $content = preg_replace_callback('%\[quote\](.*)\[\/quote\]%Uis', $atts['content'], 'replaceQuotes'); $quotesString = implode('<br />', $quotes); return $content.$quotesString; }); ?>

The switch to PDO is an important milestone! Way to go!

I was looking at brakets with much interest as an open-source software, but this makes me think that it will be just another adobe family product... Don't get me wrong, i understand that business is business, but it does turn my curiosity down a bit because I can imagine that 90% of their effort will have to do with making it work with other adobe products instead of focusing in the real text editor developing challenges. I may be wrong though...

@pwired, there isn't any software that keeps compatibility with old versions of modules forever. That's why I think it's great that you don't have to use lots of third party modules with ProcessWire, and everyone should be aware of the risk of making a website completely dependent of them. Anyway, no one is forced to upgrade immediately to a latest version (or even at all), and Ryan shows he is always very concerned about breaking things for people, so I'm pretty sure that when it comes the time when that step really has to be taken, all modules (or a good alternative to them) will be already compatible. One thing I think it's important to keep in mind here is that software has to evolve. And this evolution will always be a balance between backwards compatibility and new and better features. You really don't want to use a software that stopped in time...

Ye, this does confuse at times...PW has both input and output formats for date...

No need to format the date with PHP. You can set the output format in ProcessWire - check out the field settings of your date fields.

Fantastic enhancement Ryan. I was trying to pass some custom variables to render today and couldn't - found this post, upgraded to dev, and voila! Made things so much easier

Hi Galaxy, Have you read the docs? http://processwire.com/api/fieldtypes/repeaters/ It's pretty straightforward: $total = 0; foreach ($page->grants as $grant) { echo "Date granted: {$grant->cheque_date}"; echo "Amount ${$grant->amount_approved}"; $total += $grant->amount_approved; } To get the last date, there are several solutions. One of them: $page->grants->sort('-cheque_date')->first()->cheque_date; Edit: kongondo is online all the time and faster than me

Such kind & sweet words! I can't thank enough to you guys, not only do you help people like me to do something that we can only dream but also support & understand us. This very thing, the flexibility that PW provides is what allows me to make websites which I could never even think of before. It's easy to learn & work with PW provided you know what to look for & where. I've just basic knowledge of php which also I learnt just to work with ProcessWire, cause I had understood the potential of PW a while ago but I really started using just a few months back. So the topic is solved, I'll continue with FrontendUserProfiles module & add pages for users to store additional information. Thank you all once again. PW & this forum rocks!!!

Yes exactly. The pseudo user page can be anywhere and you could add children pages for all kind of things. And only a couple field like prename lastname to the real user template. You dont have to it's up to you. I also think you're creative enough to already see what is possible it's more the code you worry. Let me say in PW it'S REALLY no rocket sience compared to other systems and just keep trying to go with the simple API. Once you learned that you'll do anything with ease. Maybe I'm too modest but I'm also not a hardcore programmer but a design guy, and learned a whole lot with PW. Of course I got some background and did a lot with php. You're in good hands with the guys here.

<form action="/actions/post-comment" method="post"> You need a trailing slash, I think Pw does a redirect and you loose the POST request. Please try this once again and make sure it does still not work. Edit: To be bullet proof: <form action="<?php echo $pages->get(ID_OF_PAGE)->url; ?>" method="post">

Thx Ryan. I've said it before - with PW, we are spoilt for choice!

Greetings Everyone, Excellent progress Ryan! Very exciting!!! Quick and (perhaps obvious) question: when using the new $pages->add() feature, can the array specify more fields the template uses for that page? For example: $newpage = $pages->add('basic-page', '/about/', array( 'title' => 'Contact Us', 'firstname' => 'Ryan', 'lastname' => 'Cramer', 'description' => 'Master coder and genius community leader' ) ); Where "firstname," "lastname," and "description" are fields created and added to the "basic-page" template via the admin area? Thanks again for your amazing work and commitment! Matthew

But now cheatsheet is a PW site and Ryan can edit it easily himself.

A quick update. Ran a page speed test on pingdom and it came back with a 588ms load time (faster than 95 percent of websites)

Diogo, that is true, and I probably should have show it as a container tag: <ul> <txp:article_custom category="skyscraper"> <li><txp:permlink><txp:title /></txp:permlink></li> </txp:article_custom> </ul> Either way, just as simple with ProcessWire.

In this case it makes sense to show an alternative way of doing what Reno showed. Just to make it a bit closer to the TXP example: <ul> <?php foreach ($pages->find("template=skyscraper") as $s): ?> <li><a href='<?=$s->url?>'><?=$s->title?></a></li> <?php endforeach; ?> </ul>

gfdesign, I spent years working with TXP and still maintain a small handful of TXP sites for existing clients. You really don't need to know very much PHP to build sites with ProcessWire. Sure, if you want to build complex things, then you might need a little deeper understanding, but for most sites you don't need more than the basics. Using the example you posted above, let's compare (as closely as possible), ProcessWire to TXP methods. ProcessWire // get pages with the template "skyscraper" $skyscrapers = $pages->find("template=skyscraper"); // for each "skyscraper" display the following foreach($skyscrapers as $s){ echo "<li><a href='{$s->url}'>{$s->title}</a></li>"; } Texpattern In your page: // Get all articles with the category "skyscraper", use form "list" to display them. <txp:article_custom category="skyscraper" form="list" /> In the form "list": // for each article display the following <li><txp:permlink><txp:title /></txp:permlink></li> If you take the TXP tags out of it, there really isn't much difference. When you call a form in TXP, you are basically creating a foreach(). For creating most sites with PW you really don't need to know all that much PHP. Brush up on the basics and dive in. Ask lots of questions, there are nice folks here who are always willing to help. Oh yeah... Welcome.

How do I get access the FormBuilder forum? I purchased a license, but didn't see anything about how to access it. Maybe because I used a different email address than on this forum? Anyway, I have a question about how I might be able to integrate the form with a payment processor (probably just PayPal). Basically, all I need is a way to gather all of the value attributes from all of the selected radio buttons in the form and add them up into a single input element (total price) that can then be posted to an outside URL (set in the formbuilder settings). I've been trying to do this using jQuery, but I think that the fact that the form is in an iframe may pose an issue. I haven't worked a lot with iframes, but my guess is that the form submission isn't going to post any values from outside of the iframe... Am I right? Edit: Oops, especially since the form tag is inside the iframe... Yeah, that definitely won't work, at least not using the embed method. Not sure if this topic has come up already. Maybe someone has developed a better solution for it. Edit: Oops again... I'll PM Ryan about the support form.

That's what I assume he wants... If you want to know which is in the page array use filter. $found = $pageArray->filter("id=1001|1003|1005"); echo $found; // 1001|1003

Hello, we recently relaunched http://bigair.tv to the new Processwire version. The site used to be based on ViMP video CMS which itself is based on the Symphony framework. After almost two years of trying to make ViMP/Symphony work the way we needed it, I decided to rebuild the whole thing in PW. It was well worth it, even though it still contains a lot of bugs and a lot of features are still missing. With Symphony, I spend my time looking for files and classes, rebuilding classes, fighting my way through abstraction layers and trying to decipher Symphony Markup creation tags. With PW, my clients needs are easily implemented and I finally feel like I'm in charge of the site. The site offers user registration through Google and Facebook, video upload for registered users and video transcoding through Zencoder. It was remarkably easy to build in PW (even though I'll take a close look at Apeisa's "Fredi" to see if I can learn something about frontend editing) The main challenge was building an efficient caching mechanism for the video lists, which are customizable for registered users. I used MarkupCache for pretty much everything. So here is my second PW project and by far the biggest one I build so far. Thanks to PW, the community and Ryan for answering my (sometimes silly) questions! http://bigair.tv/ -thomas

A past client of mine which I did a wordpress site for a couple years back is now having issues with their site layout. It's been forever since I dived into wordpress and after playing with PW for a little over a couple months, I really don't even want to attempt trying to fix the wordpress issue. In fact, I thought I eliminated every possible way an issue could come up for them :/ Anyway, I think to myself, "I can convert this entire wordpress site over to PW in a day or two and actually save myself a headache from the wordpress template forest!! Food for thought, even though I tried to make it as user friendly as possible and wrote a user guide, it seems they have never uploaded any photos, videos, or anything of the sort. It's a shame really, and I think it had a lot to do with how Wordpress is still unfriendly to some really non-technical clients. So, I am looking forward to blowing their minds when I show them the beauty of Processwire My rant...

Doolak, you are trying to get thumb from Pageimages (bunch of images) instead of single image. Does this work: $page->mitglied_foto->first()->getThumb('thumbnail'); Or alternatively edit mitglied_foto field and set it to allow only one image (then it returns that single image in api instead of Pageimages).