adrian

I have to leave in a minute, but I just took a look at your site (using the login details you gave me the other day). I am not sure what the contents of a valid urlsegment would look like, but can I suggest using the template editor from Tracy (I set it up for you) to make a bd($input->urlSegment1); as well as maybe a bd('test'); inside some of your conditionals to check that they are being processed as you expect. There is a lot of logic in your publications template and it's not easy to figure out what is doing what. A little debugging should help you to figure out what is what

Have you read this: https://processwire.com/docs/tutorials/how-to-use-url-segments/ ? Assuming you have enabled urlsegments for the template?

$p->images->last()

Thanks for the access. The field pairings option is mentioned in the first post of the BCE support thread. What is probably not clear is that because different pages / templates on your site may require different field pairings, this setting is only available from the Settings tab of pages that are set to be separately configurable from the main module settings. I have done this for you and everything is now working as expected in Update mode even without a title set in the CSV file. Now for some caveats. If you try to import a CSV file that doesn't have a title column (even in update mode) that also has more rows than there are already existing child pages, then it will throw an error because each page in PW needs a name/title. But so long as you already have a child page for each tire size, you should be fine. Otherwise, make sure the CSV has the tire size as the title for each row and that will work fine. The other thing I noticed is that the CSV file you sent me was encoded UTF16 LE with BOM and it was failing to be read. I changed it to UTF8 and it was fine. Perhaps this is something that BCE could handle better, but for now, you'll want to be aware of that. I also played around with the labels to make this more specific to your client's needs, but of course you can edit further: Please let me know how you go. PS Is there any reason you've gone with the generic "Tire" title/name for each page, rather than maybe using the size code or something else unique?

Yeah, yeah I do use implode(), explode(), and each() a lot, but never got used to the $pages(selector) shortcut to get(), but it is definitely nice!

Thanks guys! So in case anyone else new to all this ML stuff is interested, this is what I ended up with which shows the title of the current user's language localized to their language and all of the other available languages with the title localized to their language. For displaying the currently selected language: $user->language->getLanguageValue($user->language, "title"); Then for showing the other languages in the switcher: foreach($languages as $language) { if(!$page->viewable($language)) continue; // is page viewable in this language? if($language !== $user->language) echo '<li><a hreflang="'.$language->iso.'" href="'.$page->localUrl($language).'">'.$language->getLanguageValue($language, "title").'</a></li>'; } I obviously left out the <ul> container and the <li> class details in this example, but you get the idea.

Thanks @BitPoet - that is much cleaner. Another question along these lines. Is it OK to re-title the "default" language as "English" ? I assume I should keep the name as "default", but I feel like it would be nice to title it properly and even localize it when the user is viewing the site in Portuguese. Is that something you guys do, or should I stick with doing this for the frontend language switcher: $langtitle = $language->name == 'default' ? 'English' : $language->getLanguageValue($language, "title");

I know this topic is old, but I came across the exact same issue in my first ML site. I am surprised that what @maba was looking to do is not more common or talked about. It seems like the only logical option in my opinion. Anyway, soma's solution did the trick - it's all about that getUnformatted method so that getLanguageValue has an object to work with. I did want to clarify though that it is in fact getLanguageValue rather than getLanguagevalue - note the case of the "V". It doesn't prevent it from working because methods in PHP are not case sensitive. Also can of course just use the $language object instead of the id. $language->getUnformatted('title')->getLanguageValue($language); It does seem a little unnecessarily complicated though.

It really depends on what you are doing. If you are adding new pages then the title field is required. Sorry, I assumed that was what you were doing. If you are updating existing pages, then you need to use the update option in BCE and the field pairings setting to match csv columns to template fields. If you do that, then you don't need the title field. Did you read about and understand the field pairings setup? PS If you're having trouble I'd be willing to take a look at the settings on your site if you're willing to give me access.

So the problem is that there are seven fields in the template and only six in the CSV. You need to supply the value for the title field in the CSV file as well.

Sorry not sure I quite follow. It is the required/global PW Title field I am referring to. Have you removed that from this template? Is "Import" an additional field in the template (in addition to the 6 fields of "text" type (from textfield_1 to textfield_6) ? Can you maybe paste in a screenshot of the list of fields from the template view page?

What about the Title field? Yes - text fields can display numbers just fine!

Hi Mario, Can you provide a list of the template's fields, including the type of each field, along with the csv you are trying to import so I can test at my end?

Actually the functionality of 3 and 2.8 is identical other than the fact that 3 uses namespaces. To quote Ryan: Everyone should have a thorough read through this post: https://processwire.com/blog/posts/pw-3.0.32/

Just crosslinking to a related topic - this one about about changing the starting page when inserting an image from another page, but there are lots of code examples and links to mini modules that I thought might be useful to help you understand what is possible.

Also, for a less verbose version: foreach($pages->get('/')->children() as $child) { echo "<a href='{$child->url}'>{$child->title}</a>"; } No need to assign to a variable first if you're only using once. Of course if you're using it in other places then make it a meaningful variable like $homepage - at least anything other than $page because as @horst pointed out you will overwrite the object for the current page.

Looking into it a little more, I have done both before and after in different scenarios: https://gist.github.com/adrianbj/6fd1b770d9ce7a7252b6 https://gist.github.com/adrianbj/e391e2e343c5620d0720 https://github.com/adrianbj/AdminRestrictBranch/blob/master/AdminRestrictBranch.module#L108 The first two I haven't used in a long time, but the last one I use regularly, but it's not manipulating the same way you are looking for. Perhaps you could see if one of the first two works for you though in 3.x - sorry I don't have more time right now to help debug.

Thanks for your thoughts @szabesz - it's a pretty complex site with most sections only relevant to people in the USA, although it adds value to users from other countries/languages to see the content from other regions, even though it's not translated. Down the road I can see that we'll have other sections that are only specific to other languages. Ideally, the overview pages will be translated into all these languages at some point. I think I have a decent approach now - I was just wondering what the general principle is when parts of a site are translated and other parts aren't, and dealing with setting the hreflang tag, but I think in my case I need some custom logic which is what I have done.

Not certain, but when I hook into ProcessPageList::execute I use AddHookBefore and it seems to work fine. The other thing that might be involved is the ajax check you have. In PW 3, the page tree is cached, so perhaps that ajax check is returning false, so it's not modifying what is returned?

Ok, so the problem with making a language not checked "active" for a pages is that the page disappears from menus when viewing in that language. So obviously I could either override that active check when generating the array of pages for the menu, or I could use another method for determining whether to show a hreflang tag for that language for that page. I don't want English-only pages hidden from users who are viewing the site in Portuguese, but I also don't want Google thinking that there is a PT specific page when there isn't. I am assuming it's good practice to keep the /pt/ in the URL even when there is no PT language version for that page? Otherwise if the page redirected to the default/english version, then if they navigated back to the pages that do have a PT version, then they would have to change the language again. I think the logical thing is to not use: $page->viewable($language) to determine whether to add a hreflang for the language, but I would love to know what you guys do when you have a site that is only ML for certain sections, but you want all sections to be available to all users - they can of course always use Google Translate for the other sections so I don't want them hidden/not active. Sorry for rambling - just trying to figure out what the best practice is here. Thanks in advance!

Hi @FrancisChung - I can't seem to reproduce this and I have been using those settings for over a year on one site. Is there a certain action that triggers the error or is it simply trying to view the page on the frontend? Could you possibly try on a fresh/different PW install? If you have Tracy installed, could you try: bd($p->id.':'.$p->status); on line 165 - after $p is defined on 164. It seems like $event->object is not returning a page object for some reason in your scenario, but I don't know why.

FYI - "FieldtypePageTable" is not related to ProfieldsTable at all. FieldtypePageTable is free and a core module, just not installed by default.

Sorry that was lazy of me to not look for that. So essentially it's all about the "Active" checkbox on each page. It's actually kinda weird to me that when you add a new language all existing pages are automatically activated in that language. Guess I need a little API script (or actually maybe some SQL will be easier) to deactivate all pages outside the one branch that is available in PT. Although I expect I still want the homepage and any direct parents between that ML branch and the homepage activated so that all segments of the URL will be in PT when requested - does that sound correct? That way I'd still get: /pt/cartoes-relatorios/baia-de-guanabara/indicadores/nitrogenio-inorganico-dissolvido/ rather than: /report-cards/baia-de-guanabara/indicadores/nitrogenio-inorganico-dissolvido/ where /baia-de-guanabara/ is the parent page of the one branch that is available in both EN and PT.

Maybe getting a little OT, but how is: $page->viewable($language) determined? Is it based on whether the page has an alternate "name" in the requested language, or some other means? I might actually take another approach, because it's actually only one branch of my site that has more than one language (english) at the moment, so it would be wrong to list the hreflang as having pt-br for the rest of the site. Any ideas please on the best practice approach to automate this?

Hey guys - as a few of you know, I am in the middle of my first ML site and was wondering about the hreflang tag. Using the recommended: $hreflang = $pages->get('/')->getLanguageValue($language, 'name'); to set the value in the hreflang seems to contradict what I am reading elsewhere. I thought that the hreflang tag must always include a country, in my case: pt-br. But I don't really want pt-br in the url - I really just want: http://mysite.com/pt/ rather than http://mysite.com/pt-br/ Now obviously I can set the hreflang another way, but it seems like most of you are doing it this way, so just wondering if it's actually ok to leave the country code off, eg. hreflang="pt" rather than hreflang="pt-br" Also, what about: x-default vs en-us for my default language? Thanks again for your advice! PS - I have gone with @LostKobrakai's approach of adding an iso field to the language template so I can easily define en-us (or x-default - still don't know what is best here) and pt-br, but I would still like to know why it seems that most are just using the two letter language code without the country code.