Robin S

I have ProCache disabled from the main "ProCache enabled?" checkbox, which turns all ProCache features off including minification I believe. I uninstalled ProCache to be sure and did a bit more testing. Seems to be an unannounced side-effect of the Markup Regions feature. When this is enabled in config.php all HTML comments both inside and outside a markup region in a template file are stripped out of the compiled output (edit: clarified below). I don't mind that as it's useful to be able to put notes and separators into the markup that are better kept out of the front-end source. I was just a bit surprised as this wasn't mentioned in the blog posts.

You are spot on - I have the ProcessWire namespace declared everywhere except in my included file. Thanks!

I just noticed that HTML comments in a template file are not rendered in the front-end source. Which is totally fine with me, very useful in fact, but I'm wondering what part of PW is responsible and when this started happening. I know that ProCache strips HTML comments, but I don't think that is the cause in this case because I currently have it disabled and comments are still not rendered. Was it introduced by the file compiler starting in PW3? Or maybe part of the new Markup Regions feature (which I have enabled) ? Or has this always been the case and I just never noticed? To be clear: HTML comments in _main.php are rendered, just not those in a template file. Wrong forum section sorry. Meant to post this in General Support.

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> ';