kongondo

@Marcel Epp #1: Yes, the code is right here: #2: My German isn't great but I think you are referring to the Posted by Franz Beck on 11 May 2016. That comes from here, the option post_date_text. As you can see, it is an empty string. My reasoning was that you cannot translate an empty string (although I don't know how the translation parser works). Instead, the idea is that you provide the translation/text yourself like so: $content = $blog->renderPosts($page, false, array('post_date_text' => 'on'))// whatever you want 'on' to be @All Others... Hope to get some time soon to look into your questions...sorry...

Aah, did we intend to post a link to the module maybe?

It's doing exactly what you've told it to do and it seems I need to update the example in the docs. The anchor tag (<a>) is always implied (it's a menu after all) so is always applied. That's why you are seeing double...the one always applied plus yours. What you need is to set an empty list_type $menu = $modules->get('MarkupMenuBuilder'); $defaultOptions = array( 'wrapper_list_type' => 'div',//ul, ol, nav, div, etc. 'list_type' => '',//li, a, span, etc. @note to self: need to remove this 'a' in docs // etc.. );

OK, so I need a life or glasses or both! I missed that.... From the docs it says this about the method render() [reason is in ML environment, MB will not always know what 'mainmenu' is (title varies per language)]

My bad, i lie. I have just tested and it works fine in PW 2.7.3. Make sure you have the option 'defaultTitle' => 1, for this to work. Pass that in the array to renderMenu()

I'm stumped to be honest. One, because I don't know much about ML setups. However, a number of people here seem to be using it fine in their ML installs. I have also tested in the default PW ML install and it worked fine. There were a few bugs reported but I fixed all of them. The default language there is English though. I don't know if that affects anything. Btw, You say when you use standard PW API in your smarty template it works fine. I don't follow, is there some other 'non-standard' PW API that you've been using? Edit: Just realised my ML tests were done in a 2.5 core! Something might have changed in 2.7.3. I have tested and it doesn't work. I'll see if I can trace what's happening....I can't promise when though...I am afraid...especially given ML is a needle-haystack thing in my case

aaah, I sort of understood that they didn't want to use $session... ...

Update: Version 008 Changelog Fixed a couple of minor bugs, thanks @adrian for reporting +++++++++ @adrian, Haven't seen or heard of that 'infinity' error before. Were you testing on PW 3.X btw?

Are you suggesting you'll be manually entering those page IDs?

By default, ProcessWire only returns published pages...so, exclusion of unpublished pages is already done within a 'find'

I always go back to Diogo's approach here for similar tasks..

Quick example <?php // at the very top of your template file if($config->ajax){ // the ProcessWire code in my example above exit; } ?> <table id="example" class="display" cellspacing="0" width="100%"> <thead> <tr> <th>First name</th> <th>Last name</th> <th>Position</th> <th>Office</th> <th>Start date</th> <th>Salary</th> </tr> </thead> <tfoot> <tr> <th>First name</th> <th>Last name</th> <th>Position</th> <th>Office</th> <th>Start date</th> <th>Salary</th> </tr> </tfoot> </table>

Erm...not quite. Server-side Processing is what ProcessWire (in this case; could be whatever technology or CMS on your server) does (finding the requested records, sanitizing inputs, ordering records and sending stuff back to the browser/client). Client-side Processing is done by DataTables. It has requested JSON, you send it back JSON (not sure, maybe it can also handle XML but JSON is way easier and cooler). Once you send it that back, don't try to help it ... This is wrong: Let DataTables deal with those cows without your help client-side <?php $items = $pages->find("template=a-cow, sort=-date,sort=-time"); foreach ($items as $item){ echo"<tr> <td>{$item->cow_date}</td> <td>{$item->cow_time}</td> <td>{$item->cow_description}</td> </tr> "; }?> Just set up the empty table as shown in the DataTables SSP example and it will do the rest. It will populate that raw HTML table (what the docs in that SSP page mean by enhancing the raw HTML table). To be precise, here are the steps... Someone visits your web page. DataTables sends an ajax request to the server that John Doe wants to view this table. Maybe John Doe doesn't want to view the whole table; he only wants to see 10 cows (records) at a time. That's the pagination in the DataTables. Also, with every click of the 'next' or equivalent buttons, DataTables sends requests to the server. I might add here as well, but I haven't checked, maybe DataTables is capable of requesting 2 or 3 pages in advance, get them ready for John Doe when he wants to view them The server technology, in this case ProcessWire, receives and processes the request sent by DataTables. Request could be denied or accepted. It all depends on how you have set up the processing. E.g., we could ignore John Doe unless he is logged in. If accepting the request, ProcessWire sends back data in the format and structure requested by DataTables. If you send it back in any other format (e.g. send back normal HTML or some normal string), DataTables will not understand it and will most likely throw a fit...OK an error...and John Doe will not be pleased...I can tell you that for free . OK, so you send back JSON in this case DataTables is happy to receive your JSON back. It understands JSON and knows what to do with it. It quickly populates (aka enhances) the raw HTML table with the data sent back using ajax magic. If you structured your ProcessWire array (and hence the subsequent JSON) correctly, data should properly match their columns...otherwise John Doe...you know the rest

I wouldn't touch that if I were you. No need to. ProcessWire already has got you covered. You could probably get away with less than 10 lines of code..Something as simple as...OK...before that, let's break this down. Server-side processing: is probably easier than client-side processing. The former is easier (IMO), because PW has got you covered...Throw some PW API in your template file and you are sorted. You only need to send back data in the format requested by the client, in this case DataTables is the client. Client-side: would have been a bit more difficult (for me...because I find PHP easier than JavaScript ). However, in this particular case, we are covered. DataTables does all the heavy lifting. All we need to do is to give it data in the format and structure it has requested. Requesting data: First, the JavaScript needed to request data (i.e. the client requesting data from the server)..Straight from the DataTables example $(document).ready(function() { $('#example').DataTable( {// the ID of your HTML table "processing": true, "serverSide": true, "ajax": "scripts/server_processing.php"// this is the only thing to change RE ProcessWire(template file) } ); } ); Nothing fancy in that code. The value passed to the ajax property is the important thing here. In ProcessWire, we won't be able to access a PHP file directly like that (see forum posts about this). We have two choices. Either, post to self (./) - notice the dot, or post to an existing PW page. So... $(document).ready(function() { $('#example').DataTable( { "processing": true, "serverSide": true, "ajax": "./"// posting to self (i.e. the current page) //"ajax": "/ajax-handler/"// posting to a ProcessWire page titled Ajax Handler that lives off the root } ); } ); Process ajax request: In the template file of the 'page' or the 'ajax-handler' page, depending on the value set to 'ajax' in the JS above, you will have code like so, ready to receive ajax requests..@see if($config->ajax) { // here we are listening to ajax requests sent to this page /* 1. listen (could be POST or GET. in the DataTables example, it is using GET 2. Check and sanitize required parameters 3. Kosher? Send back data in the format requested, i.e. JSON. Otherwise, ignore, show error or tell them to take a hike */ } // output HTML as usual => e.g. @see the HTML tab in the DataTables SSP example OK, the fun part. Fire-up Firebug and go to the 'Console' Tab. Visit the DataTables SSP page and watch the Console. Have a look at: Params tab: DataTables has sent a long request. Most of the stuff we will not need. The key here is to match the parameters to their corresponding ProcessWire terms, i.e. limit, sort and start. That's all we need. This is basically pagination. So, let's match stuff we need for pagination... DT => PW start => start length => limit sort // @note: index-based naming, where 0=first DataTables table column. // In this case, the value is 5 (i.e. the last column in the SSP example = salary) order[0][column] 5 => sort (sort will correspond to whatever property in your selector, e.g. title, some_text_field, etc) order[0][dir] asc => sort order in ProcessWire. if asc, do nothing, if desc then sort becomes -sort So, we get our data as normal in ProcessWire. Note, this code goes within the if($config->ajax){} condition... // @note: here you sanitize inputs + could do some other logic, e.g. check if input present, etc $start = (int) $input->get->start; $limit = (int) $input->get->length; $sort = $sanitizer->name(?)// @this is your homework; how to get to the order[0][column] and order[0][dir] values. ;-) {dir here is direction, btw} $data = $pages->find("template=basic-page, start=$start, limit=$limit, sort=$sort"); if(count($data)) // { // need to send back data with some extras to DataTables // @hint: have a look at the structure of the JSON. // @continued below... } else //error message, nothing found Next, have a look at either the 'Response' or 'JSON' tabs. That is what the server has sent back. The most important thing to note is that that was originally an array on the server (built from our $data above with some extras...). Let's build this next. if($config->ajax) { // @note: this is built from the $data above /* @note: as per the JSON tab in Firebug we need to send back 4 'things' to DataTables. 1. draw (int): I thought corresponds to the page number but seems to increment: I'll let you find out 2. recordsTotal: Number of records found 3. recordsFiltered: I haven't checked what this is 4. data: The ProcessWire find results */ // to get the total number of records: $total = $data->getTotal(); $dataDT = array();// we'll send this back to DataTables as JSON $data['draw'] = $whateverDrawIs;// could be $limit = $data->getLimit(); $data['recordsTotal'] = $total; $data['recordsFiltered'] = $whateverThisMeans; // prepare values to send back that match your DataTables table headers foreach ($data as $d) { $dataDT[] = array($d->title, $d->name, $d->id, $d->parent->title, $d->template->name);// each record } // send data back to client in JSON format (@see the JSON tab in Firebug) header("Content-type: application/json"); echo json_encode($dataDT); }// end if ajax And that's it Written quickly in browser, got carried away...there could be errors, blah blah, the usual disclaimers

@jmartsch, Does it work in PW 2.7.xx in your setup? I am afraid I haven't tested any of my modules in PW 3.X (haven't even had time to install this version ) and won't be doing so at least until we have a stable release of PW 3..because I am really constrained for time

Update: Version 007 Changelog As per the request by @heldercervantes , coordinates table can now be manually sorted.

Just to clarify to all reading this. We recommend that you use a file field instead (for your base image); otherwise, if you use an image field, you will end up with two of the same image displayed ...once in your image field and once again in ImageMarker. Can be confusing

Hi adrian, I think the original idea was to avoid displaying and saving data that was 'no longer there/invalid', aka, that page is not reachable. But maybe I should have limited this to trashed pages only. I like your idea about making this configurable. Definitely I'll still exclude trashed pages but will make displaying of 'unpublished' and 'hidden' rows and columns configurable (not sure as one choice or two options [i.e. the page statuses as choices]) but separately for rows and columns .The default (for backward compatibility) will be to exclude such pages. Hope it makes sense (typing quickly...)...

Thanks guys... I located the raw date problem... During the last commit to allow use of date format specified in blog_comments to be displayed for comments I forgot that on a fresh install, one has to first save what is specified in FieldtypeComments's dateFormat for that to kick in (see the fields Details Tab). The default 'relative' is not saved unless the user actually saves the field (normal for fields). So, in our case, the dateFormat was empty and as a fall-back, you were being shown the unformatted date as per line #247 in WireDateTime formatDate(). I've committed a fix. Update: Blog 2.3.9 Fixes above bug PS: There's still 1 or 2 pending requests that I haven't yet gotten time to address...

I bet you forgot to save

Honestly I'm dumbfounded by this one. Maybe it is a MAMP issue? Did you change any other module code? What happens is you try to save the settings page directly (/your-blog-page/settings/ That's a timestamp (because of some reason an unformatted blog_date is being returned). Again, I have not see such behaviour nor has it been reported before. Are you able to install Tracydebugger or similar to try and debug this? Are you able to test in a different environment?

@quickjeff, No need to edit the modules files .. #1. I am afraid I don't follow. There is no setting for displaying summaries. Do you mean the setting for Posts summary length? All settings are saving just fine here. What's your environment? #2: $small = false, the default (which you seem to have changed) will display the full post. To display summaries, just call renderPosts() with $small=false. Examples: // call the module - MarkupBlog $blog = $modules->get("MarkupBlog"); // render a limited number of summarised posts $content = $blog->renderPosts("limit=5", true); // render a limited number of full posts $content = $blog->renderPosts("limit=5"); Blog API (incomplete) is here

Can't believe it's almost 2 years. Unfortunately in between 'life' happened .

Hi @pmichaelis, Glad you like the module. Have a look at the current_class_level. That in conjunction with current_class should probably do the trick (the 'active' bit).

@Günter, Why not use one of the other examples of recursive menu methods in the forums?