Robin S

Not sure what you mean by filtering results from that page. You mean you do a new search, right? You have a search form that you include as part of your search results template, and then when you have done a search and are viewing page 3 of the results you do a new search from the search form - is that it? When you have done that second search, what is the URL in your browser address bar? Might help too if you post the whole contents of your search template.

I think this is wrong - you don't want to be doing another $pages->find() inside your pagination function (I don't think you need to execute your pagination in a function, TBH). The basic flow of your search template should be: // sanitize and build your $selector from $input->get() // ... // find your search results $results = $pages->find($selector); // output your search results foreach($results as $result) { //... } // render your pagination from the $results PageArray echo $results->renderPager(array('arrayToCSV' => false));

I agree. It's particularly a problem when using pw-after with multiple elements. To take a simplified example, if you have these elements... <p pw-after="header">First paragraph</p> <p pw-after="header">Second paragraph</p> ...you end up with your elements in reverse order... <header> <h1>My header</h1> </header> <p>Second paragraph</p> <p>First paragraph</p> You can't do... <header pw-id="header" class="pw-after"> <p>First paragraph</p> <p>Second paragraph</p> </header> ...or you end up with two headers. The workaround is to add your elements using pw-before on some other element. What would be helpful is some way to wrap all the elements you want to insert after without actually getting the wrapping element in the compiled markup.

Hi @justb3a, Do you think the extra field headings could be styled more like the Description label? This might be easier to do if it were a <label> element rather than <strong>. The difference between them looks a bit odd to me: Also, I'm not sure about this but it looks like the additional fields markup is not placed inside the "InputfieldImageEdit__additional" wrapper div. Is it meant to be? Edit: one more thing... What is the intention behind this part where the inputfield type is set based on whether or not a textformatter is applied? Is that meant to be a way to choose the type of inputfield you want? What if you would like a Text input but still want a textformatter applied? Maybe the choice between Text and Textarea could be a separate setting alongside the Textformatter dropdown in the table?

I'm probably missing something, but not sure why you are overriding $config->ajax here. This variable is set for you by PW when the current request is AJAX - you shouldn't have to set this yourself.

To refresh your understanding of GET variables, see this tutorial: http://html.net/tutorials/php/lesson10.php $input->get is a PW-specific way of retrieving GET variables but it's essentially the same as the native PHP $_GET. So these two lines... $keywords = $sanitizer->name($input->get->keywords); $q = $sanitizer->selectorValue($input->get->q); ...look for GET variables in the query string named "keywords" and "q", and then pass their values through a sanitizer. The result is assigned to variables $keywords and $q. And these two lines... if($keywords) { //... if($q) { //... ...check to see if the variables are "truthy": that is, if they evaluate as true when converted to a boolean. You are seeing "Title|Body Match" but this does not mean there actually is a title or body match - your if($q) test is passed so long as $q is not empty. And also consider that if($keywords) can never be true if there is no "keywords" variable present in your query string.

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.