kongondo

I've merged your 'PHP resources' topic with this one: https://processwire.com/talk/topic/2994-learning-php/?p=85246

Btw, in case you've not seen it, someone created a custom google search for the PW site. It's the one I always use

Posted these links in your other thread but reposting here... OK, here's some links in other threads: https://processwire.com/talk/topic/1555-learning-oop/ - more links in post #10 in that thread https://processwire.com/talk/topic/6030-learning-php-where-to-learn-just-enough-to-make-living-w-pw-easier/ https://processwire.com/talk/topic/4439-when-do-we-need-curly-brackets/ https://processwire.com/talk/topic/1931-recommended-php-style-guide/

My 2p....at the end of the day on such issues, really, it is horses for courses. There is nothing 'evil' about liberally using echo. Some people will include HTML in their PHP others will do it the other way round. Some people want complete separation of logic and 'views', others don't care. Some people use cameCase variables others don't. Some people swear by double quotes others prefer single quotes. Some people like OOP others prefer procedural style...Some people like direct output others prefer delayed. Others like template engines others don't...and on and on... Tell you what, the only thing you should never ever compromise on is security; for that, there are no ifs or buts. As for coding style, just pick what you are comfortable with and makes you most efficient. However if collaborating on a project where there are multiple coders, then obviously you would need to agree on the coding style . Edit: Glad the code worked for you. PHP resources: There's a number of threads on that already. Best if you searched first. I'll update this post if I can find the links as well. OK, here's some links: https://processwire.com/talk/topic/2994-learning-php/ https://processwire.com/talk/topic/1555-learning-oop/ - more links in post #10 in that thread https://processwire.com/talk/topic/6030-learning-php-where-to-learn-just-enough-to-make-living-w-pw-easier/ https://processwire.com/talk/topic/4439-when-do-we-need-curly-brackets/ https://processwire.com/talk/topic/1931-recommended-php-style-guide/ Happy coding!

Whereas that's a valid point, I am not sure that would happen. The primary purpose of the main docs found in http://processwire.com/api/variables/ and http://processwire.com/api/selectors/ is to quickly and efficiently teach (new) users how to use the ProcessWire API with as little verbosity and complexity as possible. The examples there are necessarily short so as not to lose focus or inundate the user. In addition, there are so many ways for outputting PHP content, different people preferring different styles, that it would be difficult to cover them all. The most basic/ubiquitous is 'echo' . For most people, whilst learning how to use the system also improves their PHP skills, I would suggest that you would get much more from the system if you additionally went through some very, very basic PHP tutorials . I could suggest a few if you haven't already identified any. On the other hand, in the template files tutorial such as this one http://processwire.com/docs/tutorials/how-to-structure-your-template-files/ you see some more advanced coding styles. Edit Beaten by @LostKobrakai - but you see we refer to the same thing...

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...