Robin S

Well, you don't have to. I assumed this was for some feature on the Home page where the latest comments (sitewide) are displayed. I have something like this on one of my sites, although doing a custom render that links each comment to the page it appears on.

Try this: $field = $fields->get('comments'); // assumes your comments field is named 'comments' $latest_comments = $field->type->find($field, "limit=5, sort=-created"); echo $latest_comments->render();

Maybe the multilanguage name is not made available as a subfield. You could do this: $p = $pages->get("name{$user->language->id}=$urlSegment1"); // you should probably include a parent or template in this selector too $selector = "template=mysubcategory,pageref_category=$p"; As for the other problem, it looks like your screenshot shows the name of those pagefields is different for each language. So you need to search the right one for the language: pageref_categoria or pageref_categoria_en or pageref_categoria_fr.

In the first post: I take this to mean the onus is on the user to choose some suitable global variable name. Whatever you choose could potentially overwrite another variable, or itself be overwritten in a template if you're not careful. Maybe the module needs its own namespace?

To find a page using a multilanguage name you have to append the ID of the language to 'name' in your selector. Each multilanguage page name is stored separately like this. So suppose you had a page named 'three' in the default language, and added a French name for the page 'trois'. In a simplified example, if you wanted to get the page by name in the default language you would do... $p = $pages->get("name=three"); But if you wanted to get the page by name in French you would do... $p = $pages->get("name1234=trois"); ...where 1234 is the ID of the French language. So if you are working from the user's language you could do... $p = $pages->get("name{$user->language->id}=trois");

Does it make any difference if you add the hook in /site/init.php?

Sounds good, thanks. True, but the textformatter that I'm thinking of is HTML Entity Encoder, which is important for any text field to avoid ambiguous ampersands or other invalid HTML. The string could be manually encoded in the template but more convenient to set-and-forget with a textformatter.

I tried that and the escaping works for me, so not sure why it wont for you. You could use single quotes around the jQuery selector... echo " <script> $('#bg-home').backstretch('$image->url'); </script> "; ...or concatenate inside a single-quoted string... echo ' <script> $("#bg-home").backstretch("' . $image->url . '"); </script> ';

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.