Restrict Multi-Language Branch

[neosin]

15 minutes ago, adrian said:

Thanks @neosin - it should be fixed in the latest version. Let me know if you find any issues.

thank you for the quick fix!

+1

[Noel Boss]

Love it! This just saved my arse… ? oh man, because of gems like this I love PW so much!

[kixe]

@adrian Hi Adrian,

I quickly  tried your module and find it very useful. But does it work with repeater fields? I couldn't get it working ... I played a bit around and found another simple solution.

config.php

/**
 * array of pages or page trees having multilanguage disabled in the edit screen
 *
 */
$config->singleLanguagePages = array(11973 => 0, 12334 => 0);

ready.php

/**
 * disable multilanguage in Page Edit for specified pages or page trees
 * define array of single language pages in $config
 * where the key is the page id and the value defines if the page acts as a tree parent or only for a single page
 */
$wire->addHookBefore('ProcessPageEdit::execute', function($e) {
    $page = $e->object->getPage();
    $slps = $this->wire('config')->singleLanguagePages;
    // exit if doesn't match
    if (empty($slps)) return;
    $parentIDs = array_intersect($page->parents()->prepend($page)->each('id'), array_keys($slps));
    if (empty($parentIDs)) return;
    foreach ($parentIDs as $parentID) {
        if ($page->id == $parentID) break; // page matches itself
        if ($slps[$parentID]) break; // page is part of a single language tree
        return;
    }
    // page is set as a single language page
    $page->template->noLang = 1;
    // we want repeater fields single language as well
    foreach ($page->fields as $f) {
        if ($f->type instanceof FieldtypeRepeater == false) continue;
        $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = 1;
    }
});

 

[adrian]

Thanks @kixe - I didn't have a need for repeaters when I wrote this module, but it's certainly a good idea to support them. I have gone ahead and updated the module based on your idea and it now works for repeaters as well.

Thanks!

[Ivan Gretsky]

On 11/26/2016 at 2:06 AM, adrian said:

Perhaps you'd consider adding your support to my feature request: https://github.com/processwire/processwire-requests/issues/54

As far as I can tell there is no way for me to control which languages are displayed at the moment. If Ryan can come up with a core solution that lets me hook and change the results returned by $languages then I think I will be able to incorporate your request into this module. My goal is to have a checkboxes field added to the page edit Settings tab that lets you determine which languages are enabled for the page/branch.

I have just found this module and once again am astonished at the scope of interest and productivity of @adrian! Whatever I am looking for years after I started using PW he already has a module for written when I was just messing around ? This one is the great example.

But the module is not as perfect as it could be. There is an issue (see above) that does not allow it to work as desired. I just added my thumbs up for the issue on github that makes the enhancement of the module (and custom hooks too) possible. Bumping this thread, so those of us working with multi-language sites could give their thumbs too to move the issue forward (it was waiting for us for a long time))

P.S. Multi-language support is one of the PW's selling points, so I feel proud making any step to improvement in this field)

[vmo]

Hi,
I was having trouble with the Repeater fields including the RepeaterMatrix and the following patch is working for me:

Changes to the "function multilanguageStatusCheck":

/**
 * Checks if page should show multi-language inputs
 *
 * @param HookEvent $event
 */
public function multilanguageStatusCheck(HookEvent $event) {

    $p = $event->object->getPage();


    // ORIGINAL
    // if actual noLang setting for this page's template is set to disabled (1) then exit now so we don't potentially enable
    //if($p->template->noLang === 1) return;


    // PATCH
    // if actual noLang setting for this page's template is set to disabled (1)
    // ensure any repeater/repeater matrix item templates are also single-language, then exit
    if($p->template->noLang === 1) {
        foreach($p->fields as $f) {
            if($f->type instanceof FieldtypeRepeater === false) continue;
            $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = '1';
        }
        return;
    }

    // No other changes after this point.

}

 

I don't know if it is the best way to patched it or if there is a better way.
If this change is okay, to make it persistent during module updates, can you please add this change to the module.

I will open an issue on github.

Kind regards

 

[adrian]

Hi @vmo - thanks for looking into this and coming up with a fix, but if I understand correctly, I feel like this is something that the PW core should handle because it's about fields within a template that has noLang = '1' not respecting that setting, whereas this module is all about specific pages/branches having this setting while others of the same template don't.

Does that make sense?

[vmo]

13 minutes ago, adrian said:

Hi @vmo - thanks for looking into this and coming up with a fix, but if I understand correctly, I feel like this is something that the PW core should handle because it's about fields within a template that has noLang = '1' not respecting that setting, whereas this module is all about specific pages/branches having this setting while others of the same template don't.

Does that make sense?

Hi @adrian, thank you for your reply.

As far I could understand PW core handles this for the fields that are not fields inside repeaters.

In the beginning of the function is the following code:

// if actual noLang setting for this page's template is set to disabled (1) then exit now so we don't potentially enable
if($p->template->noLang === 1) return;

// ...

What this code tells me, is that, if the template of the page has the multi-language support set to "disabled" (noLang===1) it returns whitout processing the fields inside the repeaters like it does if it passes this step:

// ...

// if there's a match, set the noLang value for the page's template appropriately
if(isset($this->data['multilanguageStatus'][$this->closestMatch->id])) {
    if($this->data['multilanguageStatus'][$this->closestMatch->id]['status'] == 'disabled') {
        $p->template->noLang = '1';
        // we want repeater fields single language as well
        foreach($p->fields as $f) {
            if($f->type instanceof FieldtypeRepeater === false) continue;
            $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = '1';
        }
    }
    else {
        $p->template->noLang = '0';
    }
}
// if no match, then use default from config settings
else {
    $p->template->noLang = $this->data['multilanguageDefaultStatus'] == 'disabled' ? '1' : '0';
}

I found this behavior by debugging, because, not matter what I would set on the "Multi-Language Default Status" of the module settings (enabled or disabled), the fields inside the repeaters would always show with multi-language support while the other fields (like the multi-language title) would show with no multi-language support.

So the only way to be able to fix the issue was to process the fields of each repeater on the page when the "if($p->template->noLang === 1)".

Maybe it makes more sense if you take the following into account (at least in my case):
- The template has the multi-language support disabled (noLang === 1)
- In all the pages of that template, on the "Multilanguage Restrictions" section on the Settings tab, what I see is the following: "Language Branch Restrictions: The template for this page has disabled multi-language support, so we don't want to override here."

This tells me the following:
- If the "Multilanguage Restrictions" are on the template level: the "Multilanguage Restrictions" are set for all the pages of that template.
- If I want to set "Multilanguage Restrictions" for one page and not for the others: I need to remove the "Multilanguage Restrictions" from the template and set it on that page.

In my case, I am setting the "Multilanguage Restrictions" to disabled at the template level so for me it makes sense.

Maybe I am wrong about my understanding but by reading the code and how the module configurations behave that was my understanding.

I hope my explanation wasn't to confusing.

Kind regards
 

 

 

[vmo]

Hello @adrian, I am a newbie to Processwire but after thinking about this in a different perspective and doing a little bit of debugging I think I found the "issue":
- A repeater uses pages to hold the fields but to be able to create that pages it needs to create a specific templates for that pages and that templates are not the same template of the page were the multi-language support is set.
- It means that the multi-language support that is set on the top template of the page itself do not propagate to the hidden templates used by the repeaters and that is why you have the following loop:

foreach($p->fields as $f) {
    if($f->type instanceof FieldtypeRepeater === false) continue;
    $this->wire('templates')->get(FieldtypeRepeater::templateNamePrefix . $f->name)->noLang = '1';
}

and if you return without setting the noLang=1 on the template of the repeater field:

if($p->template->noLang === 1) return;

the fields inside the repeater will not know about the noLang set on the top template of the page itself.

At this point I don't have a opinion if the PW core should or not should handle the propagation of the noLang attribute to the hidden/sub templates used by the repeaters (or other composed fields) or if it is the template job to understand if it is operating as a hidden/sub template and get the noLang value from the top template.

Kind regards

[adrian]

@vmo - even though PW uses pages and "repeater_" templates to house the content of repeater fields, I believe that the noLang setting of the page that contains the repeater field should handle this because you're not typically meant to adjust settings of those "repeater_" templates directly.

I doubt @ryan will get to this thread so it might be worth posting a Github issue and see what he says there.