Robin S

In case you're not using it already... Tracy Debugger is a must-have for debugging.

Welcome to the forums, @danielsl! You could do this: $p = $pages->get('/advert_page/'); $repeater_names = $p->fields->find('type=FieldtypeRepeater')->explode('name'); foreach($repeater_names as $repeater_name) { foreach($p->$repeater_name as $item) { // output your repeater item } } If you have repetitive markup that is used in several places also remember that you can put it an in an include to avoid repeating yourself.

Maybe you don't want to do this, but wouldn't it be easier to build real PW pages from the external data using a cron job? Then you would have the all the PW API benefits for those pages.

To introduce some other API methods you may not have tried yet... // different way of matching subfield, and using simply $page $kisiler = $pages->find("template=kisi, sort=title, repeater_ozlusoz.ozlusoz_konusu=$page"); foreach($kisiler as $kisi) { // you can use find() on your repeater PageArray $aforisms = $kisi->repeater_ozlusoz->find("ozlusoz_konusu=$page"); foreach($aforisms as $key => $aforism) { // another way to get a numbered index // but maybe you should consider using ordered list markup instead? $num = $key + 1; // getting a string from a PageArray using the implode() method // and better to space your items with CSS than hardcode non-breaking spaces $tags = $aforism->ozlusoz_konusu->implode(' ', '<a href="{url}">{title}</a>'); echo "<p>$num. <a href='$kisi->url'>$kisi->title</a>: <i>$aforism->ozlusoz</i><br>Etiketler: $tags</p>"; } echo "<hr>"; }

Yes, correct on both. One advantage of the Connect Page Fields module is that it can make the generation of your tags page more efficient. How much so depends on what you want to show on the tags page. To explain... For a page like the screenshot from @Sérgio, with a count next to each tag link, the typical way using only common API methods would be something like: $tags = $pages->find("template=tag, sort=title"); foreach($tags as $tag) { $count = $pages->count("tags=$tag"); // count how many pages have this tag selected // now output the tag link and count } And if you happened to want to list the articles that use each tag underneath that tag you would do something like: $tags = $pages->find("template=tag, sort=title"); foreach($tags as $tag) { $tagged_pages = $pages->find("tags=$tag"); // find pages that have this tag selected // now output the tag and the list of pages } A $pages->count() has less overhead than a $pages->find(), but it's still a lot of DB queries if you have a lot of tags. You'd probably want to cache this if you did it this way. With Connect Page Fields, the pages that use the tag are stored in a Page field so you can easily get a count or the pages themselves directly: $tags = $pages->find("template=tag, sort=title"); foreach($tags as $tag) { // you probably wouldn't bother assigning these to variables but just for demonstration $count = $tag->articles->count(); $tagged_pages = $tag->articles; // output your tag, count, etc } And for one more option involving a single SQL query on the tags table see this:

@j00st, you might like to take a look at the Connect Page Fields module: Once the module is installed it takes care of keeping the fields in sync but if you already have your articles(?) tagged you would write some API code for a one-time operation to iterate over your article pages and add them to the selected tag pages.

Not sure why that is happening, but just to let you know that address works fine for me. Could some browser extension be interfering perhaps?

@Beluga, I think the ImportPagesCSV module should be able to handle 35K rows with the right PHP settings. Ryan has talked about needing to split into batches above 450K rows (!) so 35K should be no problem.

The module does not allow for any Parsedown settings to be set in the module config, so you will have to copy the module to /site/modules/ and make changes there. If you use the Parsedown Extra flavour then you would edit line 70: $str = $extra->setUrlsLinked(false)->text($str); If you use the 'normal' flavour then do the same for line 62.

I don't have much experience with the PW multi-language features but when I have had a play with them (in PW 3.x) I've noticed that for the full-blown multilanguage setup quite a number of modules need to be installed, several of which only become visible after a previous module has been installed. 1. Modules > Install > LanguageSupport 2. Modules > Install > LanguageSupportFields 3. Modules > Install > LanguageTabs 4. Modules > Install > LanguageSupportPageNames I don't think an SQL error should occur in any case but might be safest to check that all of these are installed before creating a new language.

The problem occurs because the "user" template is a system template. See this comment in PageRender.php: Specifically setting prepend/append files in the Files tab of Edit Template doesn't work either - you might need to use an include for _init.php in user.php.

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.