Robin S

There is this: <div> <?= $page->product_description ?: 'No description is available for this product.' ?> </div>

I don't experience any issue with this when the ProcessWire namespace is not declared - the file compiler seems to be smart enough not to wrongly insert \ProcessWire\ before the PDO class. If the ProcessWire namespace is manually declared then you would need the backslash, \PDO::FETCH_COLUMN. I guess it wouldn't hurt to include the backslash in either case. The code was missing an arsort() - I have updated it now.

I can't tell from your first post what you're trying to do. $coaches = $pages->find("template=coach, sort=coach_locatie"); This gets all coach pages, regardless of province. If you want the coaches for a single province you include that province in your selector: $friesland_coaches = $pages->find("template=coach, coach_locatie=Friesland"); You can put the coach pages in any order that suits you - the point is that you don't want to make coach pages children of province pages if a coach may belong to more than one province. Otherwise you get into a situation where you need duplicate copies of coach pages under more than one parent. You can just put all your coaches under a parent called "coaches" and then set any attributes for them such as province using a Page Reference or Options field (a Page Reference usually works out being more flexible in the future). If there is going to be a front-end page "Friesland" that lists all coaches for Friesland then a Page Reference field is definitely preferable to an Options field.

I don't follow exactly what you're wanting to do, but some thoughts... 1. Seems like Javascript would be a fine way to do this - JS is going to be involved at some point anyway to do your text fading, "back to overview" link, etc. 2. If you do want to do it in PHP, rather than do the field parsing in your template you could make a simple Textformatter module (apply it after Markdown). 3. Parsing and matching HTML content with PHP is generally easier with a dedicated DOM parser such as Simple HTML DOM than regex.

What is causing you difficulty exactly? Another example with a few more comments: $table = $fields->get('tags')->getTable(); // enter the name of your "tags" Page field $query = $database->query("SELECT data FROM $table"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $count_values = array_count_values($ids); // count the frequency of values in the array arsort($count_values); // sort highest to lowest $count_values = array_slice($count_values, 0, 10, true); // we only want the top 10 tags // use the pages IDs and counts as needed, for example: foreach($count_values as $key => $value) { $p = $pages->get($key); // output whatever you want using $p (Page object) and $value (number of times tag is selected) echo "<p><a href='/search/?tag={$p->name}'>{$p->title}</a> (selected in $value pages)</p>"; } And in your search template you could do something like: $tag = $sanitizer->name($input->get->tag); if($tag) { $results = $pages->find("tags.name=$tag"); // output your results for pages with this tag }

You could do this: foreach($coaches as $coach) { $provinces = $coach->coach_locatie->implode(', ', 'title'); echo '<li><a href="">'. $coach->title .'</a>'. $provinces .'</li>'; } Not sure why you are placing your coach pages as children of a province when you are also selecting multiple provinces in your options field - normally you would use a Page Reference or Options field to show the province relation, or use a parent/child structure to show the relation, but not both.

Maybe you can update to PW 2.8.x? More recent versions of PW have fixed some MySQL 5.7 issues and make some SQL mode settings in /wire/config.php.

If you have ever updated the PW version using the Upgrades module you probably will have created a DB backup then. Is there anything in /site/assets/backups/database/ ? For the future: http://modules.processwire.com/modules/cronjob-database-backup/

There is a dedicated "VIP support" subforum for questions relating to Form Builder. See this thread for limiting entries based on email address:

In the field settings... But better to solve this with CSS by adding some bottom margin to your images.

There was a suggestion here in the forum recently that front-end editing works best when you are using the same version of jQuery in your template that PW uses in the admin back-end. So that is something to try.

You just need to add curly braces around the thumbnail url variable: $dt = "<a href='$item->url'><img src='{$item->thumbnail->url}'></a>"."<a href='$item->url'>$dt</a>"; Using curly braces around variables tells PHP exactly where the start and the end of the variable name is, so it doesn't get confused with other neighbouring text that isn't part of the variable name. You can use curly braces around any variable and it wont hurt, but usually isn't necessary until you use more than one -> in your variable or have some other complex variable expression. That's why you get the problem with $item->thumbnail->url but not $item->url.

A file config-body.js is included by default to demonstrate how you can create config files that target individual fields. If you want the global config.js to affect the body field you must delete (or rename) config-body.js

Sorry, I wasn't proposing that as a module feature - just a suggestion for @tpr to consider. I think it's something that most users don't need so I agree it shouldn't be implemented by the module. Rather than do that I was thinking a person would use has_parent in their $pages->find() selector. $page_protects_children = implode('|', $pages->findIDs("protect_children=1")); $results = $pages->find("has_parent!=$page_protects_children"); // actual selector would have more conditions

I guess you could add a couple of hidden fields to your page templates to store the "Protect children" and "Allowed roles" values using a save hook. Then make use of these fields in your find selector.

On the parent page template, if you select a single allowed template for children and specify a "Name format for children" then the first step of the "Add New" page process should be skipped. To set the name the core name format setting might be sufficient, or you have more options with kixe's module, or you can use your own hook: $this->pages->addHookBefore('setupNew', function($event) { $page = $event->arguments('page'); if($page->template == 'my_template') { $page->name = 'some-name'; } });

It does sound like a bug that needs fixing, but just wanted to add that you can get an equivalent of httpUrl in a way that respects the slash settings with: $page->url(['http' => true]);

The hook needs to be in /site/init.php, not /site/ready.php

Another option: $Events = $pages->get('/Events/')->Events_repeat->slice(-3);

Looks very clean and sleek. I'm a little concerned the default UIkit styling of some components takes the minimalist aesthetic a bit too far. There's a point where the visual metaphor breaks down and usability suffers. Take the 'tabs' component... In the first screenshot it is much more obvious: that it will respond as a tabbed interface as opposed to some other type of navigation which tab is active which parts of the page are contained within the area the tab navigation controls (e.g. you can see that the "Save" button is outside the tabbed area). Edit: I realise that UIkit will only provide the foundation styling for the admin and will be customised for use there. So this is more just an observation about the decisions made by the UIkit designers rather than something that will be a problem for the finished PW admin theme.

Simplest way is to put your jQuery into a function and call it on DOM ready and also on ajaxComplete: $(function() { myPageTableFunction(); }); $(document).ajaxComplete(function() { myPageTableFunction(); }); But you could use a hook rather than the jQuery approach: $this->addHookAfter('Fieldtype::markupValue', function($event) { $field = $event->arguments('field'); $page = $event->arguments('page'); if($field->name == 'my_text_field' && $page->template->name == 'my_pagetable_template') { $text = $event->return; if($text == 'aktiv') $event->return = "<span class='uk-badge active'>$text</span>"; if($text == 'abgesagt') $event->return = "<span class='uk-badge cancelled'>$text</span>"; } });

The parent of the PageTable pages must use a template that the editor has "add children" permission for.

The solution to both of these is to create a parent for your PageTable pages under the Admin branch of the tree. Edit: actually, that doesn't deal with the second question, but this thread has some techniques for disallowing direct access to a page:

Those links are for Profields Table, which is a different thing than PageTable. PageTable is an installable module in the core but there's no formal documentation for it. Repeater Matrix has a friendlier UI in that you can see all your content in Page Edit without having to open modals for each 'block'.

I thought of another option around this: you could give the 'module-admin' permission to the role, and then use a hook to check which module is being requested and only allow access to a particular module. $this->addHookBefore('ProcessModule::executeEdit', function($event) { if(!$this->user->isSuperuser() && $this->input->get->name !== 'MarkupSEO') { throw new WirePermissionException('You do not have permission to configure this module.'); } }); Now you just need to create a custom link in admin to the module config page, maybe using a simple Process module. Or I think AdminOnSteroids lets you add custom menu items - haven't tried it myself.