Robin S

There's no harm in just trying these things. $matches = $pages->find("title|body|tags~=$q, limit=10");

Do you need to search for both using the same query? The title|body search is coming from user input, the tag search is coming only from links that you are outputting in your tag cloud. So you can treat these as entirely separate selectors: $tag = $sanitizer->name($input->get->tag); $q = $sanitizer->selectorValue($input->get->q)); if($tag) { $matches = $pages->find("tags.name=$tag, limit=10"); // assuming your tags field is named "tags" // output your matches for pages with this tag } elseif($q) { $matches = $pages->find("title|body~=$q, limit=10"); // output your matches for the search query } You don't have to do these in the same template even - you could create a different template and page for listing tag matches if you prefer to separate them like that. In any case you would need to use separate markup for tag results than search results because some of your results output doesn't make sense for a tag search... // ... $found = "Found $count articles containing text <strong class='text-danger'>\"$q\"</strong>"; // ... $found = "I am missing a search term in the search box...";

What Macrura said, but with one small change: $hashUrl = $page->parent->path . '#'. $page->name; Edit: or maybe better... $hashUrl = $page->parent->url . '#'. $page->name; ...in case you have installed PW in a subdirectory.

Hi @Jeff C, I'm not familiar with WordPress and its limitations, but everything you have described sounds easily doable in ProcessWire. In PW you can use a parent-child structure to define a relationship, but you don't have to. For more complex relationships a Page Reference field provides a lot of flexibility. For example, seeing as a person may initially be an actor, but then later direct or produce a movie, you might decide not to use parents such as "Actors", "Directors", etc, but rather place all your Person pages under a "People" parent. Then they would take on the status of being an actor or director by virtue of having been selected as an actor or director in one or more Movie pages. So on a Person page you could easily list their directing and acting credits with selectors such as: // the $page API variable represents the current page, i.e. this Person // find Movie pages where this person was selected as a director $directed_movies = $pages->find("template=movie, directors=$page, sort=-release_date"); // find Movie pages where this person was selected as an actor $acted_movies = $pages->find("template=movie, roles.actor=$page, sort=-release_date"); In the example the selector for $acted_movies is a little different to $directed_movies because for acting roles in a movie you want to not only select the actor but also name the character the actor played. Here I am assuming the use of a Table field, with a Page Reference column for actor and a Text column for character. There are also other fields such as Repeater or PageTable that could be used instead of Table. The above may not make complete sense now but give PW a go and you'll find things are much easier than you have been used to.

Sounds very interesting! Does this mean the "Price" field is only an example, and in non-commerce situations you could add some other type of field to store data related to the variation? Will you be able to add multiple data fields to the variations?

You can do this with the undocumented dependent selects feature, which AJAX loads the selectable pages in a Page Reference field based on the value of another Page Reference field in the same page being edited. Your "homes_in_neighborhood" field would use this as the "Selector string" setting: neighborhood=page.neighborhood, neighborhood!='' You can limit by template, parent, etc too if you want. Based on my previous experience: Both Page Reference fields must use a Select, Select Multiple or AsmSelect inputfield. Dependent selects do not work inside Repeater fields. When changing the "source" Page Reference field you sometimes randomly get an option preselected in the "target" Page Reference field. Not a major problem but just something to keep an eye on to avoid accidentally saving an unintended value. If these limitations are a problem and you don't mind having to save the page after changing the "neighborhood" field then you can use the "Custom PHP code" option for selectable pages instead.

I can't reproduce that - custom styles defined in mystyles.js work for me in a page containing all of these: CKEditor field in page CKEditor field in Repeater CKEditor field in Repeater Matrix PW 3.0.50

Perhaps there should be some warning about this option in the readme and/or module config page, as it has the potential to inadvertently break links if the Page Path History module is not installed.

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]);