kongondo

Update version 1.0.4 (Dev only for now) Note: Haven't had time to update README Changes Import Mode for file/copy-pasted CSV: Two options, 'append' and 'overwrite'. Default setting set in Field's Details tab. The setting can be overridden at page-edit level. Default setting is append (sorry guys, you will have to inform your clients of the changes. The prospect of data loss inherent in the overwrite mode outweighed the inconvenience of re-teaching your clients about the new default append mode). Append: In this mode, the module will look for the last available empty/blank row in the matrix. If it finds one, imported rows will be inserted from that point forward. Any subsequent rows (i.e. rows beneath that 'last blank row') will be overwritten. Any rows above the 'last blank row' will have their values preserved (untouched). When in append mode, the 'last blank row' will always be highlighted. The modules (jQuery) monitors any live changes to the table rows (typing and clear data) and the highlight will shift accordingly if the 'last blank row' changes. If there is no 'last blank row' and you attempt to save in this mode, you will get an PW error message and your older values will be preserved in the matrix. Used wisely, append can actually mimic an insert. Btw, for an empty matrix, append doesn't make much sense since data will only be inserted in the very last row of the matrix . Overwrite: What was the default behaviour; incoming values overwrite existing values. Ignore first row and/or column: Default set independently at Field setting (i.e. can ignore one but not the other if you wish). Default is ignore both first row and column. Both settings can be independently by-passed at page-edit level. In real world examples, first rows usually store column headers/labels and first columns usually store row headers/labels. Export checked rows: You can now export only the rows you want by checking them. If nothing is checked and you attempt to export you will get a JS error alert. The 'set range to export' setting became redundant and I removed it. Shift + Click enables the selection of a range of rows. The checkbox for toggling select all still works. Lots of code re-factoring Thanks to @adrian for suggesting all of the above features . Please test and let me know. I think I have given this module enough love for now. MenuBuilder has refused to talk to me until the situation improves. So, for now, there's a feature freeze on this one and let's see if I can get MenuBuilder to smile again .

You mean something more elaborate than this (which has always been possible btw)? $p = $pages->get(1091); $p->of(false); $matrix = new Matrix(); $matrix->row = 1060; $matrix->column = 1073; $matrix->value = "This is my value"; $p->results->add($matrix); $p->save('results'); $p->of(true);

ServerPilot to the rescue

@naldrocks98, Yes, @LostKobrakai is right about variable scope; RM only knows $page and $pages . So, this with your 'array notation', works: $title = ''; if ($page->url=='/search/') { $title = $this->wire('input')->get['keyword'] ." "; } return $title; If you had debug turned on, you could have seen the errors and fixed it . You also need to instantiate $title, otherwise, you will get an error for pages that don't match. Edit Btw, just curious, how are you using this?

Thoroughly deserved .

My bad..those are incoming settings. Just haven't pushed them to dev yet

Append vs Overwrite is configurable at both field (we set a default import mode [superuser]) and page (import section settings [page editor]; here we override the default) level. If no default has been set by superuser, it defaults to append. In addition to the note above the matrix table, if in append mode, the last blank row is highlighted, just a little visual reminder about what's about to happen if they hit save. The append note also tells the user that if a last blank row happens to have other non-blank rows beneath it, the imported values will be saved starting from the last blank row and overwrite any rows below it. If they want to avoid this, users need to make sure that the last blank row is always the last matrix table row. Thought about a pop-up warning the user instead (that there are populated rows beneath the last blank row) but didn't pursue the idea, putting the onus on the editor instead. It would mean getting the pop-up if they hit save, even for other reasons (e.g saving other fields on the page). Alternatively, we could have a separate 'save matrix' button, but that is probably complicating things.

OK..What about an overwrite versus append message?

@GuruMeditation, Sure thing. At least I can listen to what you have in mind...

Yep..Wanze beat me to it...I thought the guestbook was something more elaborate The guestbook is just like the Blog Module...minus the posts ...You can have each message be a comment in ProcessWire attached to one page (one page = one guestbook), or have each message be a page with one comment (group of sibling pages = one guestbook). The other stuff you see in the frontend are just cosmetic stuff you can achieve with jQuery... The blocking stuff, etc, you can achieve all that with inbuilt comments module, or extend it to achieve what you want..

Just remembered that the internet is well, the internet and nothing gets erased (OK, not always) so a snapshot of my old site is on the Wayback Machine. Here you go: https://web.archive.org/web/20141114094607/http://www.kongondo.com/tutorials/specific-features/creating-a-blog-in-processwire/render-posts echo $blog->renderPosts($posts);//the default is to show non-truncated posts. So, unless you want them truncated, you don't need the 2nd argument

Maybe you can point us to the guestbook in question to have a look at its code to help debug? Could be namespace issue/collision.

@Macrura, It was updated to work with 'save' also a while back, I think either a @teppo or @soma PR/request IIRC. @icietla, Have you tinkered with the other settings? (see screenshot)

Works for me using $config...e.g. include($config->paths->root . 'site/guestbook/index.php'); echo $test;//this is a variable in the above index.php // output = This is my guestbook What is PW telling you? Of course I don't know what index.php in your case does/contains...So, it could be a little bit more involved than this simple example... Btw, maybe you could also convert that guestbook to a PW module? Then you can use it in a more modular way...

Reading this line again, if we are not CREATING new rows per se (i.e. not creating new row/column pages) but appending starting from the first AVAILABLE BLANK row, that is doable and is how I was thinking originally, before I managed to confuse myself trying to figure out what exactly you meant by append . In that case, the users will have to ensure that a blank row exists before attempting an 'append import'. If at least one blank row exists, that row will be populated and any other subsequent blank rows as well as long as there are still other rows of data in the imported CSV. As usual, any extraneous rows and columns will be discarded (nothing to import to). Hmm, need to see which is easier; using PHP to find the first blank row or using jQuery/JavaScript to read the matrix client-side and get the first blank row and send that with the submitted form . Happy days. As for your users creating new blank rows every year, am sure you can work that out .

Thanks Adrian! Modal: CSS: Let me start with this one. I hate CSS...there I said it! . OK, I don't hate it that much...But this drove me nuts for hours! OK, so PHP has its quirkiness too but goodness, CSS! OK, maybe am not just good at it and debugging it is a pain. The modal is a jQuery UI thing and overriding its defaults caused me more pain than I want to go through again ...So, if anyone can send me a PR, please do. Am serious, LoL. It's either this or I go back to browser default alert box (FF's is nice btw, but Chrome, urggh!). New Rows: Maybe there's two ways around this. In an earlier post I was wondering whether we need to use pages for Row and Column headers/labels (e.g. the Nitrogen, 1987 in your screenshot). In this option, we would let the first column and first row be the row and column headers respectively. That would mean, instead of using those columns (in the db) to store references to page IDs, we would use them to store Row and Column Labels. Alternatively, we could let the user choose whether they want labels to be existing pages or if they want to import custom strings as Row/Column headers. That would make for easier appending new rows since it wouldn't need the existence of a page. The second option here is to automatically create new row and column pages on import by reading the row/label titles (or checking if that page exists and add it to the matrix if it does). The problem here is if auto-creating new pages, what templates will they use and what page(s) will be their parents. Ignore first column/row: Makes sense, will look into it - if you can please submit a separate GitHub feature request, thanks Checking rows means they will be exported: Good idea, will look into it - if you can please submit a separate GitHub feature request, thanks Shift+Click: - ditto, thanks Natural/Normal way of structuring CSV data: I think you misunderstood me/I wasn't clear. This is what I meant. Consider the following data, including the row and column headers as it would appear in Excel: A B C D E F G 1 Peter 35 2 Peter 80Kg 3 Peter $50,000 4 Peter Married 5 Peter Volvo 6 Mary etc as above As you can see, the first 5 rows are all about Peter. If you get data like that, normally you would change it so that all of Peter's data is on one row, with the columns each storing one property like so: A B C D E F G 1 Age Weight Salary Marital Status Vehicle 2 Peter 35 80 kg $50,000 Married Volvo 3 Mary etc.... 4 5 So, whilst example 1 would have better worked for finding out what was 'null', it is not the normal way of organising data. Anyway, it's not important now, since you meant something totally different by 'append'.

I'd love a native solution too! Let me clarify: To me, the main issue is not the amount of installed fields . Like I said, we shouldn't let then number of fields be the overriding factor to guide our data storage needs. Rather, it is the questions I raised earlier. Fields are actually just Fieldtypes themselves . The idea behind using custom Fieldtypes was not necessarily about avoiding using pages. Fieldtypes are (usually [always?]) attached to pages . One of the ideas with custom Fieldtypes is to help better organise data, avoid duplication and redundancies. There are other advantages as well. Custom Fieldtypes can also be used in conjunction with core Fieldtypes, e.g. we could reuse the title Field, if you are using pages, say, for threads. Another example, consider the FieldtypeEvent that was linked to above. It stores three pieces of custom information on each row - notes; location and date all in one table. If we were to duplicate that using 'normal' fields, we would need at least three fields for each piece of information, a date field, and maybe two text fields. Those are three tables. Yes, that will also work, but at some scale, it is more efficient to query only one table than query several tables. Maybe even some custom Fieldtype could act as an 'external db table', but I don't know how feasible it is to have a Fieldtype that doesn't interact with a page. Anyway, I've gone overboard .... Looking forward to see the forum! Maybe then we'll have a clearer picture of what could be tweaked RE data storage, presentation, etc.

Hi DeM (cool name!)... Busted! Yes...the site is currently unreachable...I am moving things around, got caught up in a lot of work and didn't have time to set up the new server with an 'under maintenance' message, blah, blah . Domain hasn't been deleted; it's just not pointing to any IP at the moment...I know, I know, it doesn't look nice but nothing I can do about it, and am not worried about it either . But I appreciate that they tuts were important to you. Glad you found them useful. Hope you can wait a bit longer for me to finish moving stuff. I've got some nice stuff planned...

I know the feeling . ...If you haven't worked with Fieldtypes before, there is some learning curve..Onto the main question, given the task involved in developing a forum (depending on whether it is basic or has advanced features, is modular, etc.. [have a read here btw]), I think we have about 3 options: Given the time constraints we (most of us) face, proceed as you originally intended. A basic forum is better than none Ask guys who has some time to spare if we shared the work, e.g. somebody to deal with the model (data), another to deal with permissions and security, another with membership + login, another with...etc... If there is enough demand for a more than basic, scalable modular forum, and the community is willing to raise some funds to support its development, get a couple of heads (and hands!) together to work on this thing. The sponsorship really would be about compensation for time taken away from client work. #3 is probably the most difficult to organise but if it works, would probably bear most fruit. These are just my thoughts. Don't feel pressured by any of them . Even if we ended up taking option #1, I'd welcome it. You've made a good start and yours is probably the attempt that has come farthest to date (IIRC). So unless something shifts soon, I'd go ahead and release your module as is. It's not the end of the world if it doesn't have native Fieldtypes . It is a working solution. We appreciate your efforts and thank you for giving it to us gratis

Alternatively, use the search link in my signature

Welcome to ProcessWire and the forums John! Loved your intro!

<silliness>I've been meaning to do a video demo of a list of silly thinks/pranks you can do with RunTimeMarkup...you know, a countdown to lunch break, a thing that shouts "peekaboo" every time you type a certain letter on your keyboard, a (not-so-silly) live spell-checker, etc....But then again, I have been meaning a lot of things... </silliness>

Ye, that + more .. Have a read here + Ryan's comment here More stuff about Fieldtypes here (see the links I posted there...am too lazy to copy them here all over again): Let us know how you get on. If this will be a full fledged forum, then be prepared for a whole lot of work. If it is a simpler forum, I can try to commit some very limited time (away from client work) to help you with the Fieldtypes but can't promise how much time, unfortunately....

Expounding on the above...in 'append mode' there's two possible ways to determine when a value should be appended or a db value left alone (i.e. it is not being updated). This is as I describe above, If there is a BLANK/EMPTY value coming in, we assume we want to keep the db value, so we don't change it; OR If a corresponding value DOES NOT EXIST in the new values coming in (sort of like null), then we keep the db value. In this approach, it means if an EMPTY corresponding value is coming in, we empty the existing db value. The problem with #1 is that it won't account for scenarios where you actually want an incoming blank value to wipe out a corresponding db value. Of course this can be accomplished by manually deleting said values in the table itself rather than the CSV import but it could get tedious. Maybe #2 is the more natural way to do it. However, it is the more difficult way (currently) since it would require new CSV values coming in differently. Consider a matrix like this: Small Medium Large Red 12 11 13 Green 15 9 8 Blue 7 14 6 Currently, data import does not allow Row (Red, Green, Blue) and Column (Small, Medium, Large) labels/headers in the imported CSV data. As you know, data comes in like this (considering the above table): 12,11,13 15,9,8 7,14,6 This won't work for #2 since there is no way of telling what a null value is. If data came in like this Red Small 12 Red Large 13 Green Small 15 Green Medium 9 Green Large 13 Blue Medium 14 ...then, we would be able to tell that Red Medium, Blue Small and Blue Large were null because they are not part of the incoming dataset. In that case, we wouldn't touch the corresponding db values. However, I don't think this is the natural/normal way of structuring CSV data (verbosity). So, for now, unless I find another way or am nissing something obvious, I am sticking with #1 for append mode.

Looking at your fields again, I see you are storing some simple stuff as comment ID in their own field (i.e. db table). I seriously think you should consider creating some custom Fieldtypes to store some data. For instance, the forums views could all be in one Fieldtype and the different view properties would all be stored in it as sub-fields, i.e. the database schema of a FieldtypeForumViews could look something like this: forum_id forum_cat_view forum_desc etc 1 xxx This is a cool forum 2 xxx This is members only forum Sorry if this seems to be taking you back. My thinking is that you'd rather get it right (or better) at the beginning than later. I don't know how comfortable you are with code and if you will be able to develop custom Fieldtypes and Inputfields that will come as part of the forum. However, Fieldtypes are very powerful, modular, will still allow you to use the PW API, are very scalable and will allow storing of lots of stuff that would otherwise probably end up as a page (nothing wrong with pages but sometimes a custom Fieldtype is better than using a field that ships with the core). TBH, if I was to do my Blog module all over again, this is the approach I would most likely follow. I for one would be willing to help you although my time is very limited. Sorry if I am raining on your parade, but thought this was an important matter to consider.