Robin S

There is probably an obvious answer to this but I am suffering a brain-fade: In my auto-prepended "_init.php" I have a function defined... function myFunction() { echo "hello!"; } I can use that function in my auto-appended "_main.php" or in a template file (e.g. "home.php") no problem. But why is it undefined if I call it in a file that is included in _main.php or home.php? include "./my_include.php"; my_include.php // results in "Call to undefined function myFunction()" myFunction(); I was expecting _init.php to have been prepended by the time myFunction() is called inside my_include.php - or does my_include.php get included before _init.php? I guess I'm not clear on the order of operations here. Do I have to include _init.php inside my_include.php, or is there some other simple way to make myFunction() available globally?

Yes, the full rule is... #ProcessListerResults select, #ProcessListerResults textarea, #ProcessListerResults input[type="url"], #ProcessListerResults input[type="email"], #ProcessListerResults input[type="text"] { width: 100%; } ...in ProcessPageListerPro.css So you could override that specific rule or use a more generic rule like in my previous post to try and force the filterbox input to always be width:auto - whichever you think best. Thanks.

@tpr, I noticed that the filter box icon is out of alignment on Lister Pro pages. Not sure if you have Lister Pro available to test on but the culprit is a CSS rule that sets text inputs to 100% width inside #ProcessListerResults. Maybe force the width back to auto for the filterbox? html.aos div.filterbox input[type="text"] { width:auto !important; }

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.