kongondo

$numComments = $page->blog_comments->count(); @Peter beat me to it...https://processwire.com/talk/topic/7403-module-blog/?p=83118 If anybody else wants more examples let me know...

Not in this particular case, but there are times when a str_replace would suffice. In this case it would be a bit hacky .... Btw, is a 'summary field' like this a common feature of Blogs? Anyway, your question got me thinking, so thanks for asking ....Given your example, there's maybe 3 options to enable you to inject your custom fields inside Blog Markup (i.e. modify the markup server-side). Option 1. Add an post_extra_fields => array() I could add an 'array option' in renderPosts() 3rd argument, i.e. $options for specifying any extra fields (that return strings) that a user might want to inject in their markup (e.g. your post_summary field), i.e. a post_extra_fields => array() $options = array( 'post_small_image' => 3, 'post_small_image_width' => 250, 'post_comments_label'=>'', 'post_extra_fields' => array('post_summary' => 1, 'post_teaser' => 4, 'post_other_field' => 3); ); The numbers in the values inside 'post_extra_fields' (e.g. 1 in 'post_summary') refer to the position (see illustration below) where you want that extra field to appear within the Blog Post Option 2. Add other methods to output various parts of Blog Posts In this option, those who wish to use renderPosts() can do so but those who want finer control can use these other methods, i.e. renderPostTitle() renderPosByline() renderPostBody() renderPostCategories() renderPostTags() .....but hold it right there. What is wrong with this picture? renderPostTitle()! Why create a method to do what ProcessWire already does ($page->title) and does well!? Option #2 (and probably the first one too) is dead in the water and I'll show you why in option #3 below. Option 3. Use both native ProcessWire methods/properties and MarkupBlog methods as applicable I will need to put this in the Blog Docs as well. What I should have been clear about in the Blog Docs is that you do not have to use renderPosts() to output the main content of your Blog Post (i.e., post title, post body, etc). You can, if it suits your needs, use native PW methods/properties, especially if you want full control over your Posts structure and Markup. Nothing stops you from combining these with MarkupBlog methods. For instance, you can use MarkupBlog to render your Blog's tags, categories, authors, archives, etc but use ProcessWire methods/properties to render your Blog Post including adding content from any other extra fields you have anywhere on your site. So instead of: $content = $blog->renderPosts($page, '', $options) . $blog->postAuthor() . $blog->renderComments($page->blog_comments) . $blog->renderNextPrevPosts($page);//with post author in your blog-post.php...you can have: $content = $body . $blog->postAuthor() . $blog->renderComments($page->blog_comments) . $blog->renderNextPrevPosts($page);//with post author ..where $body is a variable holding your custom content (blog_body, post_summary, $page->title, etc). I will write a full example in a post below. So, back to the original question. How do we inject extra content or have full control over our Blog Post Markup if we do not want to or cannot use str_replace, etc.? Use option #3. Unless convinced otherwise, this is the option I will be recommending (hence, for now at least, will not be adding option #1 to renderPosts()). OK, let me finish writing the example option #3...

The HTML comes from two places: 1. From the various render methods in MarkupBlog (e.g., have a look at renderPosts()) 2. From blog-main.inc - we inject variables we have previously set in this file, e.g. $content <div id="main" class="block<?php echo $noAuthor?>"><?php echo $content?></div> <!-- #main -->

Still curious exactly what your template structure looks like...

Thanks @teppo. Yeah, I battled with this one; I am not a fan of such prefixes myself . I was trying to avoid collision with MySQL reserved words - row(?), value and column. Funny though that in my tests selectors still work when I drop the 'matrix' prefix...hmm. Guys..suggestions for naming the row/column/value COLUMNS? Maybe: mrow - mcolumn (or mcol) - mvalue OR maybe... use the PW data COLUMN for 'values' (i.e. intersection/combination cell/value of row vs column), i.e. $page->product.mrow//rows $page->products.mcol//columns $page->products.data//their data/values Any thoughts? Thanks.

Yes. They are subfields of whatever your field is. The subfields are the names of the columns in the Fieldtype's db table, i.e. matrix_row, matrix_column and matrix_value. The selector format would be: field.subfield=value E.g., if your your matrix field was called 'product', you would search for: . product.matrix_row, product.matrix_column and product.matrix_value. I'm in a hurry atm, see examples here: http://processwire.com/api/selectors/#subfield https://processwire.com/talk/topic/5040-events-fieldtype-inputfield-how-to-make-a-table-fieldtypeinputfield/ https://processwire.com/talk/topic/5040-events-fieldtype-inputfield-how-to-make-a-table-fieldtypeinputfield/

Am listening ...Ideas? http://stackoverflow.com/questions/804045/preferred-method-to-store-php-arrays-json-encode-vs-serialize

How is that different from version 0.0.2 I posted earlier?

Update: version 0.0.3 Small but important update to correct oversight whereby records with empty values were being saved to the database, thx @netcarver.

@Steve, Good catch about empty values! Don't know how I mised that! I have corrected it in Version 0.0.3 (post here soon), thanks! Memory issue: That was my next question. I would like to do/see some real world tests....+ there's also PHP post limits...Would appreciate if anybody could help test , thanks.

That turned out (later) to be the easy bit . They are stored similar to Page Fields...(see second screenshot below) Matrix array (see post below - we use this only for grabbing db values to later manipulate to build matrix cells/intersections. We use a different array for saving) Matrix db table (see update below [version 0.0.3] about avoiding saving records with empty values)

Hmm, or maybe I should include this in the present module but with a max 3-way relationship? Otherwise it get messy if more. The 3rd relationship (materials in your case) would only kick in if user configures it in the Fieldtype settings as you suggested. What do you guys think?

Update: version 0.0.2 Added ability to reuse a single matrix field across pages/templates to build unique matrix tables on a page by page basis. This is achieved by specifying the name of a Multiplepages select field in the Fieldtype settings (Details Tab). It allows you to select row and column parent pages from within the page containing the matrix itself. The child pages of these parents are used to build the matrix. This setting overrides the Row and Column selector settings of the fieldtype. Example usage: Create a Multiplepages field and call it, for example, 'product_select'. Set it up as you wish (e.g. custom PHP, selectors, etc for selectable pages). You may wish to use ASM select to make things prettier/easier below. Add it to the same template(s) where you will be using a matrix field. In your matrix field's Details Tab, specify the name of the page field (i.e. 'product_select') under the 'Matrix Row and Column Parent Pages' setting. Edit the page where you will be building a matrix table. Select 2 pages in your 'product_select' whose child pages will be used to create your matrix rows and columns. The order is important! The first selected page will be assumed to be the row pages parent and the second one the column pages parent. Any additional pages here will be ignored. Save your page and your matrix table will be built using the children of the selected parent pages. Note: The usual error checking will be done and 'thrown' (e.g. if parent pages do not have children, if your specified page field is not a page field/does not return a PageArray, etc. Note 2: You can swap/change the row/column pages in your page field (product_select) HOWEVER, all previously saved values will be deleted(!) on save and your matrix table rebuilt to reflect the new specified row/column structure. Todo/think about Copy values from Excel and directly paste this in a similarly structured matrix table Export matrix table? 1-click clear all values entered in a matrix table Etc? Download: https://github.com/kongondo/FieldtypeMatrix Screens Named Page Field to select rows and columns parent pages Row and Column parent pages selection in a specified Page Field Reusing a single matrix field on a different page(s)

@Charger, I see no easy way of doing that (3-way relationship) using this particular module. I'll see if I can do a bespoke one for your needs.

Some follow up questions here about select row/column pages per page vs per field: Coming soon...pls wait... Resolved this (answered my own questions ) see below update..

@Charger, Sorry I I didn't get back to you. I have now come up with something similar (following a request similar to yours) that could probably suit your needs? https://processwire.com/talk/topic/8581-module-matrix-fieldtype-inputfield/

@sakkoulas, Posted this on Github and started the new module's topic here: https://processwire.com/talk/topic/8581-module-matrix-fieldtype-inputfield/ Thanks for testing! Also see subsequent post there about some thoughts I am having, thanks.

FieldtypeMatrix and InputfieldMatrix Modules Directory: http://modules.processwire.com/modules/fieldtype-matrix/ GitHub: https://github.com/kongondo/FieldtypeMatrix The module Matrix enables you to save data from a 2D-Matrix table. The rows and columns of the matrix table are made up of pages retrieved via a ProcessWire selector or via a page field selection of parent pages. The matrix values are made up of the data input in the matrix cells, i.e. the 'intersection of rows and columns'. Example Usage You have Products whose prices vary depending on colour, size, material, etc. Using the Fieldtype, you can create a table with rows made up of colours and columns made up of sizes the combination of each making up their respective values (in this case price). So rather than creating multiple text fields to do the following: Colour Size Price Red Small £10 Red Medium £20 Red Large £30 Red X-large £35 Green Small £9 Green Medium £15 Etc... You can instead have the following in one field: Small Medium Large X-Large Red £10 £20 £30 £35 Green £9 £15 Blue Etc... Yellow Purple If you set a selector in the Field's settings, to retrieve pages to build your matrix's rows and columns, it follows that all pages using the template the Fieldtype is attached to will have identical rows and columns. In some cases, this could be the intention. For instance, you might have 'Car' pages, e.g. Audi, Volvo, Ford, Citroen, Mazda, BWM, etc., each of which uses a 'Cars' template that has a single FiedltypeMatrix called 'car_attributes'. If you set a selector to build the Fieldtype's rows and columns, your users can easily compare the cars based on a combination of different values. The following matrix table best illustrates this: Type Engine Size Fuel Efficiency Carbon Emissions Warranty Road Tax Price 1994 Audi brand 1 values, etc. 2000 Audi brand 2 2006 Audi brand 3 2012 Audi brand 4 Each of your car pages would have similar matrices. This allows you to make easy but powerful queries. Such a setup allows you to compare within and across car brands. Say you wanted to find out which car(s) offered the best value for money given certain parameters such as warranty, emissions etc. You can easily make such comparisons (see code below). You can also compare within one car type, e.g. which brand of BMWs does best in what area...The possibilities are endless. In the database, Rows and column pages data are stored as their respective page->id. Matrix-values store any data (varchar(255)). If instead you wanted a template's pages to each have a matrix built of different rows and columns, you would have to name a Multiple Page Field (attached to the same template as the as your matrix field) in the matrix field's settings. When editing those pages, your matrix table's rows and columns will be built using the published children pages of the 2 pages you select in the Multiple page field.. The module allows the creation of matrix tables of any sizes (rows x columns). The rows and columns dynamically grow/shrink depending on the addition of row/column pages that match what you set in the matrix field's settings (see its 'Details Tab'). Please note that, if such pages are deleted/trashed/hidden/unpublished, their data (and presence) in the matrix are also deleted. Entering values in the matrix You have three choices: Manually entry Uploading a comma delimited (CSV) file. This can be delimited by other characters (tab, pipe, etc); not just commas Copy-pasting CSV values. (Tip: you can copy paste directly from an Excel spreadsheet. Such values will be 'tab-delimited'). In addition, if your server supports it, in the field's settings, you can enable the use of MySQL's fast LOAD DATA INFILE to read and save your submitted CSV values. Note that for large tables, you may have to increase your PHP's max_input_vars from the default 1000 otherwise PHP will timeout/return an error and your values will not be saved. I have successfully tested the module with up to ~3000+ values (10x350 table), the Fieldtype is not really optimised (nor was it intended) to handle mega large matrix tables. For such, you might want to consider other strategies. Install Install as any other module. API + Output A typical output case for this module would work like this: The matrix's rows, columns and values are subfields of your matrix's field. So, if you created a field called 'products' of the type FieldtypeMatrix, you can access as: product.row, product.column and product.value respectively foreach($page->matrix as $m) { echo " <p> Colour: $m->row<br /> Size: $m->column<br /> Price: $m->value </p> "; } Of if you want to output a matrix table in the frontend: //create array to build matrix $products = array(); foreach($page->matrix as $m) $products[$m->row][$m->column] = $m->value; $tbody ='';//matrix rows $thcols = '';//matrix table column headers $i = 0;//set counter not to output extraneous column label headers $c = true;//set odd/even rows class foreach ($products as $row => $cols) { //matrix table row headers (first column) $rowHeader = $pages->get($row)->title; $tbody .= "<tr" . (($c = !$c) ? " class='even' " : '') . "><td class='MatrixRowHeader'>" . $rowHeader . "</td>"; $count = count($cols);//help to stop output of extra/duplicate column headers foreach ($cols as $col => $value) { //matrix table column headers $columnHeader = $pages->get($col)->title; //avoid outputting extra duplicate columns if ($i < $count) $thcols .= "<th class='MatrixColumnHeader'>" . $columnHeader . "</th>"; //output matrix values $currency = $value > 0 ? '£' : ''; $tbody .= "<td>" . $currency . $value . "</td>"; $i++; } $tbody .= "</tr>"; } //final matrix table for output $tableOut = "<table class='Matrix'> <thead> <tr class=''> <th></th> $thcols </tr> </thead> <tbody> $tbody </tbody> </table>"; echo $tableOut; The module provides a default rendering capability as well, so that you can also do this (below) and get a similar result as the first example above (without the captions). echo $page->matrix; Or this foreach($page->matrix as $m) { echo $m; } Finding matrix items The fieldtype includes indexed row, column and value fields. This enables you to find matrix items by either row types (e.g. colours) or columns (e.g. sizes) or their values (e.g. price) or a combination of some/all of these. For instance: //find all pages that have a matrix value of less than 1000 $results = $pages->find("products.value<1000"); //find some results in the matrix (called products) of this page $results = $page->products->find("column=$country, value=Singapore");//or $page->products->find("column=$age, value>=25"); //$country and $age would be IDs of two of your column pages Other more complex queries are possible, e.g. find all products that are either red or purple in colour, come in x-large size and are priced less than $50. Credits @Ryan on whose Fieldtype/InptufieldEvents this is largely based @charger and @sakkoulas for their matrix ideas Screens Field Details Tab Inputfield Larger matrix table Example output

@Sephiroth, you are in control of the template (files) . Could your question be a bit more specific? If you are referring to the optional demo content - those are just that; demos...

Was just about to post that . Learn't about it when PW switched from TinyMCE to CKEditor in core (the big red error notice with links)...

@Danjuan09, I am in a bit of a rush but wanted to say welcome to PW and the forums! I understand moving into a new 'house' can sometimes be confusing because things may not be how/where you expect them to be .. Others will explain better (or I will later) but PW does not really have (frontend) themes in the sense that WP and other systems have. In PW, any HTML can be your frontend 'theme' although we really refer to them as template files. Being a very flexible system, this is usually up to the developer to implement as they wish. However, to help get some people started, a few developers here and the PW install offer what are called site profiles. These are more than a collection of template files to output frontend demo content but also include fields, template and pages to get you started rapidly. Some people use them others don't and instead install PW with the blank profile. As for the backend, there are admin themes which can be installed (since PW 2.4? I believe) as modules. Before that, there were other ways of changing the admin theme. Not all 'older' admin themes listed in the modules directory have been updated to be installable as modules (in fact probably none of them has!). To help you get the best of PW, I'd suggest to first go through the basic tutorials found in the links below. I'd suggest not to worry about 'themes' at the moment until you get the basics of how the system works. It will require, in some cases, some 'unlearning' on your part about how other systems you've previously used worked . So, get to know your new house first...changing the paint and decor will naturally fall into place later . Wish you a nice stay here! Start here: http://processwire.com/docs/tutorials/simple-website-tutorials/ Or here: http://processwire.com/docs/tutorials/hello-worlds/ Then here: http://processwire.com/docs/tutorials/but-what-if-i-dont-know-how-to-code/ Feel free to ask for clarity....

Yes we do...OR-groups Both of these work for me (not sure if the second one is the better syntax though for this particular case): $test = $pages->find('template=basic-page, foo=(external_status=""), foo=(external_status!=accepted), sort=title'); $test = $pages->find('template=basic-page, (external_status=""), (external_status!=accepted), sort=title'); https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=64049 Related new(ish) selector, selector grouping https://processwire.com/talk/topic/3768-processwire-dev-branch/?p=58722

@mrkhan, Just want to clarify that you can pass a PageArray to MarkupSimpleNavigation as explained here: https://github.com/somatonic/MarkupSimpleNavigation#build-a-menu-using-a-pagearray-instead-of-a-single-root-page You are also not limited to a single menu per page. But feel free to use what works for you and you are comfortable with If you haven't already, also have a look at the PW docs here: Selectors: http://processwire.com/api/selectors/ Page: http://processwire.com/api/variables/page/ Pages: http://processwire.com/api/variables/pages/

Any spike in donations after the TV interview?

Cool. I suppose you also know about MarkupSimpleNavigation?