kongondo

Welcome to the forums and ProcessWire @Bron... Home <= parent page of About About <= parent page of child 1 and child 2 Child 1 <= parent page of grandchild Grandchild Child 2 You might want to start with the docs

Don't know. You could ask at its support forum: https://processwire.com/talk/topic/2607-module-custom-page-list/

Not on hover, but I suppose you know you can view them always by specifying your settings in template -> advance -> List of fields to display....

$message('your message');// or $error('error message'); $session->redirect('./') You may want to consider handling situations where the page was not successfully saved or other form errors occurred...

What is $u? The eror says $u is not an object...I am guessing you is for user? You also need to sanitize inputs before saving them, e.g. the 'lp_item'

http://bfy.tw/5mfF : migrate site Please have a look at the results and let us know if you still have a specific need...

Thanks Macrura...had let this slip under the radar. I'll add it as an option so users get to choose (and why wouldn't they?) if they want the textarea formatted with ace or not...

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