Robin S

For static links you could use AdminCustomFiles and append the links with jQuery. Beyond that you could duplicate and rename the admin theme module and then code in whatever links you need, as I don't think the menu render function is hookable (for the default theme at least). Or a process module, as you say. Also, if by internal links you mean links to edit a particular PW page remember that you can set up page edit bookmarks.

I've been browsing through the core module settings (found some unknown-to-me goodies in InputfieldPageName, JqueryWireTabs and ProcessField) and I came across the ProcessPageType module. This module has a setting (empty by default) for "What fields should be displayed in the page listing?". What does ProcessPageType do and where in admin its interface?

The suggestion by gebeer can achieve that markup - you just need to modify the PHP used in the Hanna code. If you consider it's not user friendly to type the Hanna code then you can make use of the Hanna Code Helper module. If you wanted to support multiple galleries per page and don't want to worry about the 'show' limit in gebeer's code it occurs to me that you could create a repeater field, the template for which contains only an images field. Then your Hanna code could get then nth repeater item (as specified by the user in the Hanna tag) and output its images. Shouldn't be too difficult to code. Downside is the user would need to be instructed not to reorder gallery repeaters after they are in use. ...the template for which contains a title field and images field, and the the Hanna code finds the gallery by title. That said, to do this type of layout (and an infinite number of others) properly I recommend the Repeater Matrix - it's a pro module but well worth the cost.

Thank you adrian, that file has fixed it.

I resolved this issue - it was related to the default SQL mode changes introduced in MySQL 5.7 I set sql_mode to the previous MySQL version's default of NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION and all is good now.

@seanmvincent Yes, you can't use Hanna Code recursively with the current version. But see this post and this pull request - you could manually update the module with the code from the PR.

More strangeness: the timestamp in the error log and the timestamp in the database for the same comment are exactly 1 hour different. Error log: 10 hours ago 2016-05-30 08:48:19 puppyfan /stories/punters-favourite-is-one-very-fast-goat/ SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1464551299' for column 'created' at row 1 (FieldtypeComments) Database row: 1204 Good on you Calum for taking the risk on the Goat.... 3 114 1 puppyfan barry+six@mydomain.co.nz 1464554899 1590 122.58.151.116 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) Ap... 0 0 HfDxzuBCb8t8d6uVQWYJeiDFFouiA9dAXGb_qhx_2lK9vlnIbP... potLYc_2ERq9vc7RGD42xyTr81tfOZk3qSMMKR77 0 0 NULL Note the difference of 1464551299 vs 1464554899, which is 2016-05-30 07:48:19 vs 2016-05-30 08:48:19

Thanks for the help, really good advice. I think I have found the source of the problem, and the answer came from looking in the PW error log (duh!). There were a heap of similar 'Invalid datetime format' errors there, and most mention FieldtypeComments. An example: SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1464551299' for column 'created' at row 1 (FieldtypeComments) All the errors are for row 1, and I suspect even the ones that don't mention FieldtypeComments relate to the comments field because they are identical in all other respects (apart from the timestamp of course). When I check the FieldtypeComments table in phpMyAdmin I can see that all the entries the 'created' column are indeed saved as timestamps. Some strange things: 1. My comments field continues to work normally and all the comment times are displayed correctly on the front-end and back-end. 2. When I ran the SQL query suggested by Bill C my comments field was not one of the ones listed (results were 2 x file, 4 x image, and 1 x procache tables). Is the comments fieldtype meant to store its times in datetime format? Could the table perhaps have been created wrong on install with the wrong data type for the 'created' column? I know little about databases and not sure how to check this.

@Hardoman, It's certainly possible to have multiple menus generated by MSN on the same page. Having a desktop menu transform into a mobile menu is more about the CSS you write than MSN. There will be many ways to skin the cat, but I often use three menus per page: 1. A single-level horizontal menu of top-level pages (show at desktop widths, hide at mobile widths) 2. A vertical sidebar menu containing descendants of the root parent (show at desktop widths, hide at mobile widths) Example: $nav = $modules->get("MarkupSimpleNavigation"); echo $nav->render(null, null, $page->rootParent); 3. A mobile menu that contains all pages (hide at desktop widths, show at mobile widths)

Thanks, that was my first thought too. But I think it's actually a MySQL error code - Googling shows a lot of non-PW issues with the same code. I don't have any login/logout hooks, but I do have custom code for front-end user registration/login/logout. One thing I noticed that might be related is that when I add the 'Created' column to the Users lister (Access > Users) I see that the guest account and the superuser account were created '5 years ago'. Is that normal or a sign that something may be wrong with the created date for these users?

Thanks for the suggestion. Unfortunately the string 1464507951 doesn't appear anywhere in the database. Maybe it's not saved because it's invalid? Does the "Session: " prefix at the start of the error message have any significance? - I have the core SessionHandlerDB module installed. Or is that shown for all PW error notifications?

A couple of times when logging out (or it might have been logging in) I got an error message like: Session: SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1464507951' for column 'created' at row 1 How can I trace back to find out the table that is affected here? Anyone know what can cause this error?

Not really an answer to your question, but do these pages under /tools/ have template files? If no, they can't be viewed on the front-end. If yes and you are using them in other pages with $mypage->render() then you can make them not directly viewable by having this at the start of the template file: if(empty($options['pageStack'])) throw new Wire404Exception(); Apologies if this isn't helpful.

You have to add in the pagination. For the total count of matches use getTotal().

I suggest you go a different route. The downside to the way you are finding pages in your code above is that you can't do a consistent pagination of results. This is because you do a foreach() within your results list which produces an unknown number of additional results. So say if you need to apply a limit of 20 results for pagination you could end up with 22 on page 1 and 37 on page 2, etc. To avoid this it's best to get your results from a single $pages->find() operation. You don't show what is going into your $selector variable above, but below is some example code. The variable $search_term would be the sanitized term(s) coming from your search form. // Define the piece of the selector that checks fields for the search term // Let's say we only need to check the body field // But you can expand this with any other fields you need to search $selector_piece = "body~=$search_term"; // First we find any matching address pages $addresses = $pages->find("template=address, address_field~=$search_term"); $categories = new PageArray(); foreach($addresses as $address) { // And add their categories to a PageArray $categories->add($address->categories); } $categories = $categories->unique(); // Strip out any duplicates if($categories->count) { // Now we use OR-groups to say either the body must contain the search term // or the page must have the same category as one of the matching addresses $selector_piece = "($selector_piece), (categories=$categories)"; } // Search the website pages, but not address pages because we already dealt with them // If there is the potential of a lot of matches you should apply a pagination limit $matches = $pages->find("$selector_piece, template!=address, limit=20"); // Output the matches, if any if($matches->count) { foreach($matches as $match) { echo "<p><a href='{$match->url}?searched={$search_term}'>{$match->title}</a></p>"; } } else { echo "<p>Sorry, no matches.</p>"; } And then in your pages where you show addresses in a filterable table: <script> $(function() { $.urlParam = function(name) { var results = new RegExp('[\?&]' + name + '=([^]*)').exec(window.location.href); if(results==null) { return null; } else { return results[1] || 0; } }; var searched = $.urlParam('searched'); if(searched){ $('#filter').val(searched); } }); </script> Adjust $('#filter') to match your filter field as needed. You might need to attach this to a callback that runs once the table plugin has initialised.

I was running an older version of Tracy Debugger (v1.2.9) and just upgraded to the latest (v1.7.7). Using the Tracy dev branch on the front-end I get 'Array to string conversion' errors in all of the panels. Tracy works fine in the back-end with dev branch, and also works on front-end and back-end with the stable branch. An example error: exception 'ErrorException' with message 'Array to string conversion' in ...\site\modules\TracyDebugger\ProcesswireInfoPanel.inc:334 Stack trace: #0 ...\site\modules\TracyDebugger\ProcesswireInfoPanel.inc(334): Tracy\Bar->Tracy\{closure}(8, 'Array to string...', 'D:\\Websites\\__w...', 334, Array) #1 ...\site\modules\TracyDebugger\tracy-master\src\Tracy\Bar.php(93): ProcesswireInfoPanel->getPanel() #2 ...\site\modules\TracyDebugger\tracy-master\src\Tracy\Debugger.php(230): Tracy\Bar->render() #3 [internal function]: Tracy\Debugger::shutdownHandler() #4 {main} PW is running locally on XAMPP, PHP v5.5.33 --------------------- Update: I found the source of the problem - there is a conflict between the dev branch of Tracy Debugger and FieldtypeTemplates (Template ASM Select). Update 2: FieldtypeModules and FieldtypeFields also conflict.

Hi @BitPoet, I just created a GitHub pull request with a fix for this. Cheers.

@seanmvincent That sounds like a PHP error is occurring. If you turn on PW's debug mode do you see any error messages? Also, it looks like there is a mistake in the example code in your post. I think you want $pages->get() not $page->get().

Okay, makes more sense now. @Ivan: Seems like it would be easier to leave MSN and Menu Builder out of it. If you know the page structure you want just build a normal PHP multi-dimensional array of page IDs or page paths, then turn these IDs/paths into page objects as you iterate over the array and output the necessary markup.

Where does the $title variable come from in your code? You don't show where it is set. To set the URL you want to set the name of your page. $np->name = 'something'; If you don't set a name (as in your code) the name is generated automatically from the title. If you are setting a name from a variable you can pass it through $sanitizer->name($my_variable) to make sure it is a valid name. In your case you want to set the name to the same as the page ID. But when you are first creating your page the ID doesn't exist until you save it. So you can do something like this: $np = new Page(); // create new page object $np->template = $templates->get("lost-property"); $np->parent = $pages->get("/lost-property/"); $np->title = 'my title'; $np->save(); // save the page so you can get its ID $np->name = $np->id; // set your other page fields $np->save();

If you literally want to pass it to MarkupSimpleNavigation you don't need a multidimensional PageArray. You just need a normal PageArray of root pages and MSN takes care of the recursion from the root pages.

I have a question regarding the condition: Is there some way around this? I don't want to give any other roles this permission besides superuser (and the only superuser is me) because I don't want to give site editors the ability to restore backups. But I also don't want to have to be regularly browsing the website myself just to ensure the backup cron job runs. You mention running the backup from a standard cron job above - how does the db-backup permission come into play here?

Thanks for the feedback . The faulty field rendering was due to the fact that the Children tab loads via AJAX, so AsmSelect fields contained there don't get to attach their JS/CSS files in the document head in the render() method as they normally would. Have worked around this so should be fixed now in v0.0.3 I should have said in the first post that this module is only really good as a stopgap measure until either: a) this functionality is built into the core, as I think it should be b) someone builds a better module for this My dev skills are beginner/middling at best. I built this module for mostly for my own use and as a learning exercise. It gets the job done but I don't doubt for a second that there are better solutions possible. Regarding your suggestions: 1. Not sure this is a major problem as I think only multi-instance PW 3.0 sites are affected. But it was simple to change wire() to $this so went ahead and did that. 2. I have changed the template storage field to global. Not 100% sure this is the way to go so would like to hear more opinions on this. As for whether it is correct or not to use a fieldtype for storing the data - I have mixed feelings about this. I get where you're coming from and part of me does think it's a bit hack-ish. But on the other hand, the data stored in the field 'belongs' to the page so in many ways a fieldtype is ideal for this. I guess it depends if you believe a fieldtype should only ever hold page content and never page metadata. An example of another module that holds metadata in fieldtypes is Lumberjack so it's not without precedent. In any case, I don't have a good enough knowledge of MySQL to create a dedicated table and database interface in this module. Bitpoet does this in his TemplateParents module and maybe once I've learned a bit more about MySQL I could do something similar but for now I think this module will stick with the fieldtype approach.

The old wiki seems to be unreachable now. Google shows links like http://wiki.processwire.com/index.php/Module_Creation but they just redirect to the PW home page.

I have made a simple module for this: info here.