kongondo

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.

I am not sure this is how I would consider it. Btw, a lot of fields is relative. There's a site here in the forums that had 800+ fields! Whilst I thought (then) that that was a lot of fields, some people looked at me like duh! Since then my perception has changed and is guided differently. So, rather than asking these from a cosmetic point of view (visual bloat?), I think we should be asking the following questions? What are the forums data needs? How best can we store that data to facilitate efficiency? (i.e. easy, fast and optimized queries) What format should we best store a data format in? Varchar, int, etc? If storing strings, are we better of storing some stuff as JSON? Should we store some stuff in one page or as different pages? Should we store some data in its own table or store it as part of a column (sub-field) in a row? How will the forum scale vis-a-vis our data model? EDIT: See next post - Are all/some of our data needs best served by developing custom Fieldtypes and Inputfields? We then base our data model around such questions. If that results in 20, 50 tables, so be it. Give me a scalable data model any time than a short list of fields in the backend, something that I won't be spending my time interacting with often Just my 2p

@adrian: I think I misunderstood what you meant by append. I assumed you meant tucking new values at the end of the matrix starting from the last empty row. What I think you actually meant was for each value, 'if new value is empty, keep old value. If new value is not empty, overwrite old value'. Is that correct?

Andrey, With adapted code stolen from Soma here: https://processwire.com/talk/topic/4476-validating-field-before-page-save/ (post #2), you can do something like below in an autoload module. Be sure to read Soma's explanations as well in that post/thread. <?php class ValidateEmail extends WireData implements Module { /** * Return information about this module (required). * * @access public * @return array module info * */ public static function getModuleInfo() { return array( 'title' => 'Validate Unique Email', 'summary' => 'Ensure Uniqueness of Emails across site', 'author' => 'Kongondo, Soma', 'version' => 001, 'singular' => true, 'autoload' => true, ); } public function init(){ $this->addHookAfter("InputfieldEmail::processInput", $this, "validEmail"); } public function validEmail($event){ $field = $event->object; if($field->name == 'mail'){ $page = $this->modules->ProcessPageEdit->getPage(); $oldEmail = $page->get($field->name); $newEmail = $field->value; #$this->message("old value: $oldEmail"); #$this->message("new value: $newEmail"); $existEmail = $this->wire('pages')->get("id!=$page->id, template=basic-page, mail=$newEmail, mail!=''"); if($existEmail && $existEmail->id > 0) { $field->value = $oldEmail; $field->error($this->_("That email $newEmail is already taken mate; go fishing! :-)")); } } } } This will save if unique, keep old value if not unique and show error. I am not sure what you mean by admin gets error notification; you mean send them an email or log the error? I'll let you Google that

Very nice site Tom. Glad ProcessWire ticks all your boxes! Just a minor niggle: I am not too keen on the scrolling/typing text thing...It hurts the eyes after a while and it also seems to be in several places so becomes a bit too much.

Update version 1.0.3 (Dev only for now) Note: Haven't had time to update README Changes Export to CSV feature: Can export whole matrix (default) or limit to specified row range (e.g. start at row#2 and end at row#10 ). These are set in the collapsed fieldset 'Import/Export CSV Data' below the matrix. Exported CSV files include timestamp in the file name. Some CSS styling for buttons. Option: Set alert message to show after clicking 'clear data' button. If message set, show alert if no message specified, do not show any alert. Note: now using a custom popup rather than the ugly + annoying browser popup . Option: Save empty values. Default is no; do not save empty values. Current status shown at the top and bottom of the matrix table. Option: Show row numbers. Default is no, do not show row numbers. Fixed a bug where older saved values would still appear after one switched to using custom PHP code to return rows and columns. Added checkboxes for row selections (see #8). Clear Data: Rather than wholesale clearance, button will only clear values of selected rows (see #7). Will show a popup if you try to clear without first selecting at least one row. Fixed some minor bugs in situations where there would be more than one matrix table on a page. Some stylistic changes to rendered fields in line with above changes. Code re-factoring.

Hi Robguy, Welcome to PW and the forums... Although you could make it work in the frontend, a core module like that is really meant for the backend, where all their dependencies are present. I would suggest you use your own HTML form for uploads but make use of ProcessWire API to validate and sanitize uploads + use CSRF. Here's an excellent thread to show you how: https://processwire.com/talk/topic/3105-create-pages-with-file-upload-field-via-api/ Adapt the code to suit your needs. What you are after is really the bit about wireUpload class...

Hooks... http://processwire.com/api/hooks/

Going by the setting in the 'Detail's tab in a comments field, under 'Number of days after which to delete spam' (default = 3), I am guessing the spam will be deleted after those number of days. If you want to delete them yourself that's also OK. In the Blog itself, spam comments on the frontend will only be visible to superusers or logged in users who can edit that page. Try it out and see what happens -) Just to clarify: The comments module is actually not part of the Blog module, but a core ProcessWire module, hence my 'guessing'.

Fieldtypes are not for the faint-hearted ; but don't let that discourage you! They will seem difficult in the first instance, but once you get to know what does what (some of the generic methods), you will absolutely love Fieldtypes and appreciate the thoughtfulness that Ryan put into designing PW. I used to be a sucker for Process Modules but now am totally hooked on Fieldtypes. I dare say they are the heart of ProcessWire. Here's some important homework from the forums that will help you with the generic methods I mentioned above. The most important thing to remember is that with Fieldtypes, you are just a heartbeat away from the database so sanitizing data and retrieving data in some expected format is crucial. Enjoy! https://processwire.com/talk/topic/671-relationship-between-sleepvalue-wakeupvalue-and-sanitizevalue-methods/ https://processwire.com/talk/topic/4105-module-create-a-pages-findquery-as-a-field/?p=40411 https://processwire.com/talk/topic/1936-remove-entry-from-pagesfield-via-api/ And don't forget this classic: http://www.flamingruby.com/blog/anatomy-of-fields-in-processwire/ Edit: One more tip. Working with Fieldtypes, you will want to have a tab open showing the table (database) of the field you are working on so that you can observe how things get saved (or don't get saved!). The FieldtypeEvents that @adrian pointed too uses some advanced techniques (e.g. moving some methods to their own PHP classes); you don't always have to do that. It really depends on your coding style. I'd also suggest you have a look at RuntimeMarkup or Concat Fieldtypes and check out the comments. These Fieldtypes don't save anything to the db but have some useful comments. Edit 2: A diagram RE Fieldtypes database schema https://processwire.com/talk/topic/5040-events-fieldtype-inputfield-how-to-make-a-table-fieldtypeinputfield/?p=85759

You are not saving the status you have just set. Assign your page 1265 to a variable, set a status to it and save. Hidden and similar flags are saved to the db (see the column status in the table pages in your PW db) so you need to save.

https://github.com/ryancramerdesign/ProcessWire/releases

@quickjeff, nope. That should do it. If the version is not showing as 2.3.5 in the modules page on your site, just hit the module's refresh button. Would love to hear about how the site performs if possible, ta.

@Metadope, In my testing, I never managed to replicate the issue you reported here. I know it's been a while but wondering if you managed to resolve your issue?

Update: Blog Version 2.3.5 (dev branch only for now) Changes Fixed issue of slow loading dashboards on sites with lots of posts. Added some missing translation strings, thanks @mr-fan. Decluttered modal window, thanks @mr-fan. Some code optimisations. I don't think there are any other pending issues. Apologies it took so long to get to this update; we got there in the end

@Alxndre' That sounds inordinately long. Are you importing on a local or remote server? On a local server, I imported 10K rows with 3 fields in two equal batches and it took no more than 10 minutes in total (IIRC). If you can, direct SQL import will be faster than PHP. If you are working on a remote server, maybe try to import to a local server first, then get a DB dump of the import and on the remoter server import the db dump instead. Of course, page IDs will need to match what you expect on the remote server. Just a thought...

It was on local host. See posts from here onwards.

@quickjeff...his Blog install got messed up by an x-debug limitation so he needed to reinstall. He was caught between a rock and a hard place and couldn't use the 'cleanup feature' since Blog didn't finish installing due to the x-debug thing.

Update version 1.0.2 (Dev only for now) Note: Haven't had time to update README Change Added method getValue() to get the value at the given coordinates(row, column). This is an extended syntactic alias for $page->matrix->get('row=1045, column=1098'). It is more versatile, taking two parameters (row, column), allowing you to get a value by specifying its row and column ID (integer), path, title or Page object. Examples: getValue() (matrix field called 'results' with student names for rows and subjects for columns) //get by path #$result = $page->results->getValue('/students/ishak/', '/subjects/physics/'); //get by title #$result = $page->results->getValue('Ishak', 'Physics');//note title is case sensitive //get by ID #$result = $page->results->getValue(1062, 1082); //### get by Page #$r = $pages->get(1064);//results row #$c = $pages->get(1083);//results column //pass Page object #$result = $page->results->getValue($r, $c); //pass Page title #$result = $page->results->getValue($r->title, $c->title); //pass Page ID #$result = $page->results->getValue($r->id, $c->id); //pass Page path #$result = $page->results->getValue($r->path, $c->path); ############### //get by mixed parameters #$result = $page->results->getValue('Ishak', '/subjects/history/'); #$result = $page->results->getValue('/students/sarah/', 'French');//note title is case sensitive #$result = $page->results->getValue($r, 'Music'); #$result = $page->results->getValue('Amani', $c->path); $result = $page->results->getValue('James', $c->id); if($result) echo '<strong>' . $result->rowLabel . ' </strong>scored ' . $result->value . ' in ' . $result->columnLabel; else echo 'No result found'; Please test and let me know how it goes, thanks.