kongondo

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!

Welcome @Stikki

Good idea, ta. I'll have to link to the image from somewhere (maybe Github or my site) since we can't add images to modules directory

What 100k limit? Somebody here had 500k pages . The page_id field is int(10) - the 10 just means how many digits can be displayed in the db column It is an unsigned integer field so...from the MySQL docs... http://dev.mysql.com/doc/refman/5.1/en/numeric-type-attributes.html http://stackoverflow.com/questions/8892341/what-does-int5-in-mysql-mean http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html You will be fine

Good detective work...Just to reiterate: 1. This is about Blog AND Demo content 2. If one wishes, they can use the _main.php with Blog Demo files but they would have to set that up themselves... (I should do a tutorial about this)

After (but only if necessary - see below). As outlined in the must README + You have to manually copy over the files CSS + JS files. If you don't copy them to /site/templates/css/ and /site/templates/js/ then, you have to amend the links in blog-main.inc (e.g. you could have copied them to /site/templates/styles/ and /site/templates/scripts/ respectively. Have you confirmed that the files are being loaded in the browser. If your answer is yes, then the problem I suspect is that the default PW install _init.php and/or _main.php files are interfering with the rendering. It has happened to me before . I always use the PW blank install so I don't tend to notice this much. If blog-main.inc wasn't copied to over to /site/templates/ it means you did not install Blog with demo content . Maybe send some screenshots of your settings when you initially set up blog (step 1 in the module config) + what your frontend looks like.

Changed this to Beta version. I'd appreciate testing (especially character encoding issues and using CSV/Text tab delimited files generated in other systems other than Windows - Linux, Mac, etc..), thanks! Changelog Version 0.0.7 Added optional feature enabling fast import of CSV data using MySQL's LOAD DATA INFILE (off by default, set in Details Tab of Fieldtype). Version 0.0.8 Option to populate matrix table via a .csv/.txt file upload. Top and Bottom Reset buttons to clear all matrix values before save (handy when you want to restart from a clean slate). Fixed issue where saved column header label was not being selected in the InputfieldSelect in the Fieldtype's 'Details' Tab - Thx @Adrian Changed status to Beta. Version 0.0.9 Fixed a character encoding issue regarding fopen (e.g. £ sign not being displayed) - note: if you really need to save such characters in the db, then you are better off copy-pasting your CSV values rather than uploading (i.e. avoid fopen). ============== I'll be writing more advanced find examples for this field using my customer data example. e.g. find records where a customer is <=45 and lives in Cameroon.

The simple and recommended way is to use a page field ..(with radio as select) Please see these: https://processwire.com/talk/topic/4852-radio-buttons-fieldtype/ https://processwire.com/talk/topic/588-how-can-i-use-radio-buttons/ https://processwire.com/talk/topic/201-fieldtype-select-aka-drop-down/?p=8971

Hi @loopyloo. Welcome to the forums and thanks for trying out Blog. If you want to install Blog with the demo content, you have to manually copy over those two CSS files and the blog.js file to some folder in your /site/templates/. If your paths are different, you would have to change them in 'blog-main.inc'. Check in Firebug/Chrome Developer that the files are actually being loaded. In case you missed it, let me also reiterate that the demo Blog is just that - a demo; you will probably want to change it here and there to suit your needs .

I have been running Windows 7 on an i7 processor, booting from a 120gb SSD for the past 2 years...Amazingly fast! Quiet PC and no overheating. Remember no to defrag an SSD! . I am now thinking of going even smaller - build a NUC (or similar) rig...using them microSSDs..

Blink and you miss it! Thx Adrian! I'm such a rookie! .

The Matrix is for the backend. There are multiple approaches to display its stored values in the frontend - in a grid/matrix table, repeater like list, etc...

You are right. The more I think about this, the more I see it as a separate/bespoke module...

@everfreecreative, you mean besides having a cooler name? . As LostKobrakai pointed out, it's all in the first post. You can't really create a 2D/Matrix table using repeaters, since, er, the rows just keep repeating with the same thing. And if you could create one, I think you would have more overhead using a repeater to create, say a 10x100 table than this Fieldtype. To understand what the Fieldtype does, think an Excel spreadsheet with column headers and row labels whose intersections contain unique cell values (by unique I mean each table cell can only ever represent a unique combination of two factors different from any other cell). The main purpose of the Fieldtype is for storing and retrieving such values. As for Table, that's a whole different beast whose scope is far greater than what this Fieldtype does...

Thanks for the writeup....Here's another way of doing it (no need to use instance of Page ). Also, only output stuff you have confirmed exist.. //prepare a variable to use later on. Setting one like this ensures we don't get 'unknown $sidebar' errors in case things go wrong $sidebar = ''; //if we found a course selected in the page field if($page->course_name_from_list) { $course = $page->course_name_from_list; $sidebar = "<h4>Course: " . $course->course_number . "<br>" . $course->title . "</h4>"; } else { //Oops, course not selected! Quick, hide everything! $sidebar = '<h4>Sorry, we do not have yet have the details for this course. Please check back soon, thanks. Alternatively, if your case is urgent, you can contact us on 12345-4567-0000.</h4>'; } echo $sidebar; Btw, If I understood you correctly, the page selected in the Page field 'course_name_from_list' has a field called 'course_number' and of course a title. In that case, you don't need to first save those fields in an array as you implied above: The fields will be available to you automatically in the 'page/object' 'course' . You will be able to reference them as $course->name_of_field. If any of the fields is an array, you would have to loop through it, of course..

I think the feature Nico is talking about was added in the dev branch a while back? IIRC...can't find a link atm... . To be clear parent::init() has been there for a while...what I am referring to is the 'uninstall' feature Nico is talking about...if memory serves me right!

Glad you sorted it out... The error with first() is because, in a Single page field, there is no 'first' per se; there is only one value there. first() will only work with a Multiple page field (or similar fields that return multiple items). To be a bit verbose, it is like telling a student 'go get me the first Head Teacher' - it doesn't make sense since there is only one Head Teacher (only one possible - Single page field). But you could tell the student, 'go get me the first teacher you find in the staff room, or the next five teachers you meet in the corridors ' (multiple possible) OK, you get the point

@kathep. Welcome to the forums. As Nico pointed out in his post, he didn't know whether you are using a Single page field or a Multiple pages field, hence the use of 'instanceof Page/PageArray. That is not code you would normally use in a template file. Nico also pointed out how you would handle either page field type which I want to further clarify by asking, is your 'course_name_from_list' a Multiple or a Single page field? The fact that: does not answer my question either . This is because, your 'course_name_from_list' could be a Multiple page field but you are using it to select only one course. In that case, because it would be a Multiple page field, whether you select one or 10 courses from it, it would return an array that you would have to loop through. On the other hand, if it is a Single page field, you would only ever be able to select one page in the field; PW will not let you choose more. You would not have to loop through it if it was a Single page field. Which of this is your case? If not the latter, I would suggest you change it to be the latter since you will only ever want to force the selection of a maximum of 1 page. Then you would be able to do as Nico suggested in his second example...(and it would work if your 'course_name_from_list' was a Single page field type), e.g. if($page->course_name_from_list) echo $page->course_name_from_list->title; Sorry for long-windedness! Btw: If on development/local server, you want to turn debug on....

Just for fun, I decided to try saving from copy-pasted CSV data using MySQL LOAD DATA INFILE. Now this MySQL feature is something you use for really serious transactions. Testing with 'only' 1000 values seems an overkill. Anyway, here's the results: Testing with same data as in my post above (10X100 table with 1000 values) Method 1: CSV + MySQL LOAD DATA INFILE 1. Copy-pasted CSV values in the format: Name|Age|Country|Bank Account|Phone|Credit Card|Email|Salary|Address|Post Code Quinlan T. Romero|36|Burkina Faso|RS31212461883550021066|(989) 462-3421|863|Integer.vulputate@Curabiturut.ca|£066.39|P.O. Box 161, 2347 Donec Street|6518 2. Flip the CSV values to match our db structure, i.e.: data(matrix_row) | matrix_column | matrix_value - explode csv line by line - str_getcsv csv line to create array of the csv line - push sanitised csv values into a new CSV array mirroring our 'db structure' (i.e. including row and column page->id) - we do this because our raw csv data is in matrix table format and LOAD DATA INFILE won't read it correctly array( [0] => ( [0] => row->id [1] => column->id [2] => value ) ) 3. Write CSV values to a data.csv file - fopen a data.csv in this page's /assets/files. Force create the file w+ if one doesn't exist - fputcsv the CSV array line by line 4. LOAD DATA INFILE - instantiate a new PW (PDO) $this->wire('database'); - Delete this page's existing values from db - Execute a LOAD DATA INFILE, reading through our data.csv and writing to db (at high speed ) - Delete data.csv Method 2: CSV + 'Saving Normally' 1. Similar to above but we don't write to a data.csv nor use LOAD DATA INFILE 2. Prepare csv array using str_getcsv similar to above...but 3. Our CSV array is slightly different (but timings don't matter because of the different structure) [row->id] => ( [column->id] => value ) Results: Memory usage and Timings Normal LOAD DATA INFILE processCSV() mem_end 15,105,984 13,767,352 mem_start 12,754,968 12,761,496 Diff 2,351,016 1,005,856 time 0.1240 0.0740 ___processInput() mem_end 14,974,128 13,328,584 mem_start 12,754,128 12,760,504 Diff 2,220,000 568,080 time 0.1240 0.0940 ___sleepValue() mem_end 15,504,760 Not Applicable mem_start 15,122,112 Diff 382,648 time 0.0160 Not Applicable As you can see LOAD DATA INFILE is the (clear?) winner. Not sure if LOAD DATA INFILE is enabled everywhere though? Anyway, for now, not sure if this is the route I should take. Besides, I got something else planned (in my head!) for handling really large grid tables.. Before you ask, no we are NOT using LOAD DATA INFILE with the LOCAL option (security concerns with that option!)