kongondo

Untested + markup could be wrong: Here's some heavily commented code. You might want to use shorter field names Here's some homework if you haven't seen it yet : http://processwire.com/api/fieldtypes/repeaters/ //$section is the name of the repeater, in other words.. //$section is the REPEATERS and.. //$item is a SINGLE REPEATER within this group of repeaters $lesson_list = ''; foreach($section as $item) { $lesson_list .= " <tr> <td>" . $item->lesson_plan_time . "</td> <td><strong>" . $item->lesson_plan_subject . "</strong></td> <td>" . $item->lesson_plan_section_type->title . "</td> <td>" . $item->lesson_plan_section_type->lesson_plan_section_description . "</td> <td>"; foreach($item->online_tools as $tool) { $lesson_list .=" <a href='" . $tool->url . "'>" . $tool->title . "</a>"; }//end foreach $item->online_tools as $tool $lesson_list .= "</td></tr>";//close the table row and loop through the next $item until done }//end foreach $section as $item /* $item->lesson_plan_time: a text field (lesson_plan_time) $item->lesson_plan_subject: a text field (lesson_plan_subject) $item->lesson_plan_section_type: lesson_plan_section_type # This is a Single PageField type, i.e. either: # 'Single page (Page) or boolean false when none selected' OR # 'Single page (Page) or empty page (NullPage) when none selected' # It returns a Page Object (an instance of a Page) so we can directly reference its properties like: # $item->lesson_plan_section_type->title, OR # $item->lesson_plan_section_type->whatever (e.g. child, name, other_non_array_field), etc. - $item is the repeater we are currently looping through - lesson_plan_section_type is a page object - title is a property of the page object in lesson_plan_section_type - lesson_plan_section_description is a text field in the page object in lesson_plan_section_type $item->online_tools: online_tools # This is a Multiple PageField type, i.e.: # Multiple pages (PageArray) # We need to loop through it */

Read this very quickly.... Since a repeater returns a PageArray, you've done well to foreach it. However, lesson_plan_section_type and online_tools are also PageArrays, so inside your first foreach, you also need to foreach them (traverse the array) (i.e. a nested foreach $item as $abc inside your first foreach - but you would have to first check if $item is an array, otherwise PHP will throw an error since the text fields will not be arrays [i.e. cannot be foreach'ed]). Things can get a bit confusing though with nested foreachs. There are other techiniques like using a counter (...sorry I am in a rush and can't explain now...)... I am curios why 'lesson_plan_section_type' is a PageArray. Are you actually selecting multiple pages in that page field or a single page field would do? That would save you looping through the pagefield. Sorry if I have confused you further...Hopefully you'll get better answers soon .

Are you talking about people extending other custom modules other than core? There is nothing wrong with extending other modules if it suits your needs. Why reinvent the wheel? Of course, if your module is extending another, your module code needs to make checks whether the extended module is installed or not and what to do in such cases, etc. If referring to custom modules extending others, there are a couple of examples here, I can't find them all but MigratorWordpress extending MigratorAbstract comes to mind. Btw, autoloaded and loaded on demand are two different things

http://processwire.com/download/

I am afraid I don't follow ...I let others chime in...

Update: Blog version 2.3.1 Bugfixes Thanks to @matulkum, fixed this bug (thanks @bwakad) where...unparsed HTML would be output in Blog Posts/Categories/Tags Dashboards in multilingual ProcessWire environments. Additions As per https://processwire.com/talk/topic/7403-module-blog/?p=83971. Thanks to @Gazley, added 'post_small_tag' option to renderPosts(). Enables developer to select HTML tag to wrap around a 'small' Blog Post, i.e. a post excerpt/summary. Value should be left blank if no tag is desired. Especially useful if using the option 'post_small_allowable_tags'. The default tag is '<p>'. Use option as: //$options = array('post_small_tag' => 'div');//note we enter the tag only without the angle brackets! //render a limited number of summarised posts $content .= $blog->renderPosts("limit=5", true, $options); Requests Thanks to @loopyloo, added MarkupBlog frontend demo screenshot to README. See post #304-312 for why...

A variable in double quotes will get parsed fine. If your first code it was in single quotes you would see $page->projects_managers instead . So, the code is not incorrect. I do like to concatenate though for code readability/highlighting.. http://www.scriptingok.com/tutorial/Single-quotes-vs-double-quotes-in-PHP

Actually a combination of both works for me... $menu = $modules->get("MarkupSimpleNavigation"); $entries = $pages->find('template=basic-page, children.count>1, limit=10'); $options = array( 'max_levels' => 2, 'selector_level2' => 'limit=5, sort=-created',//limit the number of children to 5 (event 1 to 5) ); //the arguments are: render($options, $page, $rootPage) echo $menu->render($options, null, $entries); This should hopefully get you started...

You'll get a better answer from Soma but reading the docs, I see two possibilities if I get you correctly: Build a menu using a PageArray instead of a single root page https://github.com/somatonic/MarkupSimpleNavigation#build-a-menu-using-a-pagearray-instead-of-a-single-root-page nav_selector property/field and selector_leveln (new in 1.2.1) (unsure about this one...) https://github.com/somatonic/MarkupSimpleNavigation#added-support-for-nav_selector-propertyfield-and-selector_leveln-new-in-121 I'd probably go for #1 - passing a PageArray, i.e. retrieve my events using a find, sorting by -created and limiting to 5, then pass that to MSN...I haven't tested this, mind you... Edit: See below; need a combination of both.

@Mohammed, Welcome to the ProcessWire forums. Are you talking about a ProcessWire site and ProcessWire users?

I am, uh, impressed . Very nice and clean site (love the fonts and colours!). Loads quickly too. Nice showcase sites as well. Thanks for sharing Jeff

Indeed it is cleaner...updated my post.. Martijn was right

I have an M2 drive myself - gonna use it to build a HTC (I gave up on Pi)...

It is built in. Martijn was close right. You can do this: $button = $this->modules->get('InputfieldButton'); $button->attr('id', 'button_create'); $button->attr('value', $this->_('Create New')); $button->attr('href', './edit/'); $button->class .= ' my-float-right-class';//note: concatenation + space PW will add the other inbuilt button classes. //See a cleaner alternative below...

This is why we have the API...it can do all the heavy lifting...cleanly

Link to the module in the modules directory: Modules Directory: http://mods.pw/8s

Thanks @Macrura, Btw, I corrected my 'cars' example in the first post. I had all cars in the same matrix table rather than car types and brands each in their own matrix (and page), allowing comparisons across cars (e.g. what type of car is best in xx) and within car types (e.g. in respect of Ford's, which brand does xx worst).

Version 1.0.0. Changed status to stable Updated version (big jump!) to 1 Changed db querying syntax slightly, i.e. subfields are now, e.g., products.row, products.column and products.value respectively for the matrix's rows, columns and values. I have submitted this to the module's directory and also updated the first post in this thread.

Thanks Alex for catching this. I can confirm this behaviour only happens in the dev branch since the addition of the updated FieldtypeComments. Ryan managed to break something . Hey, the new fieldtype is still under development. I will bring this to Ryan's attention. Meanwhile, a workaround that I have tested is to first install the stable branch PW, install Blog, upgrade PW to dev branch. Works fine. FYI the message logs for dev branch (unsuccessful upgrade of blog_comments) 2015-01-06 18:07:29 lightning_admin http://curium-kcu.lightningpw.com/processwire/blog/ Updating schema version of 'blog_comments' from to 4 2015-01-06 18:11:06 lightning_admin http://curium-kcu.lightningpw.com/processwire/blog/ Updating schema version of 'blog_comments' from to 4 2015-01-06 18:17:05 lightning_admin http://curium-kcu.lightningpw.com/processwire/blog/ Updating schema version of 'blog_comments' from to 4 Compare that to a successful one.. 2014-11-30 01:51:37 kongondo http://localhost/pb/pb/blog/ Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:51:37 kongondo http://localhost/pb/pb/blog/ Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:51:37 kongondo page? Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:51:37 kongondo page? Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:54:34 kongondo http://localhost/pb/pb/blog/ Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:54:34 kongondo http://localhost/pb/pb/blog/ Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:54:34 kongondo page? Updated schema version of 'blog_comments' to support website field. 2014-11-30 01:54:34 kongondo page? Updated schema version of 'blog_comments' to support website field. 2015-01-06 17:46:32 kongondo http://localhost/pb/pb/blog/ Updating schema version of 'blog_comments' from 1 to 5 (FieldtypeComments)

@Alex, I am wondering whether it is because of this? field_blog_comments_votes. This is the latest comments module. I haven't tried it out with Blog and seems like I should. The error suggests it has something to do with it (i.e. it is not being uninstalled, I think). Have you confirmed in your db that the field is actually removed before trying to reinstall Blog? Same goes for the other tables. Meanwhile I'll find some time to try out Blog with the latest comments module...

Hi Alex, Thanks for trying out Blog. Most likely you are hitting the limits of xdebug.max_nesting_level=100; so the Blog wizard is not completing the installation. Please check out these posts to see if they resolve your issue: https://processwire.com/talk/topic/7403-module-blog/?p=81692 https://processwire.com/talk/topic/7403-module-blog/?p=81696 https://processwire.com/talk/topic/7403-module-blog/?p=81740 https://processwire.com/talk/topic/7403-module-blog/?p=81743

@Mike, Another example here from FieldtypeComments. PS: Please post all module related development stuff to the Module/Plugins sub-forum/board: Module/Plugin Development https://processwire.com/talk/forum/19-moduleplugin-development/ This board is for 'Questions, answers and support for ProcessWire modules.' . Moving this thread there...

@Gazley, Yes, you are right about what elements can be nested in what. Thanks for helping me rethink this. For the benefit of others, below is a lengthy explanation + the solution I propose (you can skip right to it ) Resources: http://www.w3.org/TR/html401/struct/text.html#h-9.3.1 http://stackoverflow.com/questions/12015804/nesting-p-wont-work-while-nesting-div-will http://ckeditor.com/forums/Support/Nested-paragraph-tags. http://webtips.dan.info/nesting.html - old but good http://www.iamchristinabot.com/blog/20110519/why-do-nested-html-paragraphs-break-css/ http://stackoverflow.com/questions/4291467/nesting-block-level-elements-inside-the-p-tag-right-or-wrong Explanation: First the code in MarkupBlog.module //MarkupBlog Line #933 //notice the surrounding '<p></p>' tags if($small) $out .= "<p>" . $page->summary . "… <a class='more' href='{$page->url}'>" . $options['post_more_text'] . "</a></p>"; In your template file e.g. 'blog-posts.php', assuming you have this code: $options = array( 'post_small_image' => 3,//here for array illustration only 'post_small_image_width' => 250,//ditto 'post_small_allowable_tags' => '<h2>', ); //render a limited number of summarised posts $content .= $blog->renderPosts("limit=5", true, $options);//passed $options to renderPosts() Example content entered in your 'blog_body' <p>This is my paragraph that I am going to test.</p> <p>Here comes a second paragraph.</p> <h2>And here comes a h2 we will allow through.</h2> <p>This is another paragraph.</p> <p>Our final paragraph.</p> <h2>A second h2 to allow.</h2> 1. Output without 'post_small_allowable_tags' <p>This is my paragraph that I am going to test. Here comes a second paragraph. And here comes a h2 we will allow through. This is another paragraph. Our final paragraph. A second h2 to allow</p> 2. Output with 'post_small_allowable_tags' In the second output, since you have allowed <h2> (it doesn't matter whether they came first or in-between other text in your content), this is what line #933 will send to the browser: <p>.....<h2>........</h2>..........<h2>........</h2>..</p>; As stated, that is invalid code and the browser will remedy it. The next block level element will be used to close the first <p> or the browser will self-close it (empty <p></p>). So, what you will end up with in the browser is: <p></p><h2>....</h2>some free untagged text<h2>....</h2></p>. Although the browser (view source) will seemingly also place an empty <p></p> at the end of the text, in fact, it will just be a closing </p> without an opening <p>. The W3C validator will then give you the error 'No p element in scope but a p end tag seen.' For comparison, if you allowed an inline element, e.g. <img> tag instead $options = array('post_small_allowable_tags' => '<img>'); This would be output correctly since an <img> is an inline element. The output would be: <p>Some text<img>More text<a>Read More</a></p>. Hopefully this long explanation will help inform decisions about how to use the solution I envisage. Solution I will make what HTML element (or not) to surround a blog excerpt (blop post small) with configurable (add to $options). So: Let user decide whether to surround post excerpt with <span>,<p>, nothing, etc. since they know what tags they will be making 'allowable' (inline vs block level). The option will apply whether using 'post_small_allowable_tags' or not. Default will be to surround with <p>. An empty value passed to the option will mean 'do not surround the excerpt with anything'. I will also add a class to that tag, e.g. <p class='post-excerpt'>...</p> to aid with more specific style-targeting. Hope to update this soon. The update should not break any existing installs since it will default to the current use of <p></p> tags.

@Gazley, Yes, it has happened before and we've dealt with it as shown here using 'post_small_allowable_tags'. Specify and configure that as you wish in your renderPosts() third argument $options. //holds string of HTML tags for strip_tags $allowable_tags. Needs to be in format '<code><p><img>' $options = array('post_small_allowable_tags' => '<h2><img>',//etc..); Sorry, still haven't gotten round to updating the docs! So, that post #207 is your go to post

Revisiting this: Duh! I forgot that similar to 'matrix_row' that is being mapped to 'data' and vice versa, I could also map the db columns 'matrix_column' and 'matrix_value' to 'column' and 'value' respectively as well as let 'matrix_row' be 'row' mapping to 'data'. The names of the db columns don't change; it's just how I reference them in searches/selectors. #1. This means that instead of the current prefixed sub-fields: $pages->find("products.matrix_row=$foo, products.matrix_column=$bar, products.matrix_value=foo2"); #2. We'll rename the sub-fields as: $pages->find("products.row=$foo, products.column=$bar, products.value=foo2"); Just looks cleaner and of course means less typing. Any strong objections to renaming the sub-fields this way (switching to #2 syntax above)? Been staring at this for too long!