Language status fields defaults inconsistency in admin vs API

[poljpocket]

Short description of the issue

For multi-language environments using LanguageSupportPageNames module, there is an inconsistency in the status123-fields (123 = language ID) between creating pages in the admin and via the API.

Expected behaviour

When creating a new page via the API (e.g. $pages->newPage(...)), the per-language status fields get populated with 1 (active) status as this would be the case if the page was created in the admin.

P.S.: This is also expected in any case where a Page Reference field in 'text tags' mode allows for new pages to be automatically added.

Actual behaviour

Creating a page via the API does not set per-language status fields at all, leaving them at 0 (inactive) and effectively only activating the new page in the default language.

Screenshots/Links that demonstrate the issue

There is a forum post discussing both situations where others and myself have run into this problem.

Suggestion for a possible fix

A possible fix isn't as simple because I am not aware of any side-effects this could have. There is some logic in the hook Pages::saveReady in LanguageSupportPageNames to decide if a page's language specific status should be active or not. The forum post contains a workaround at least for reproduction method 2 (see below) which explicitly sets the status fields for any non-default language before the page is actually saved:

/** @var Page $newpage */
foreach($languages->findNonDefault() as $language) $newPage->set("status$language", Page::statusOn);

Steps to reproduce the issue

1. Install LanguageSupport and LanguageSupportPageNames
2. Add at least one additional language

Method 1:

3. Create a new field using Page Reference - Text Tags and choose a template and parent page to be able to enable Allow new pages to be created from field? option. Enable said option.
4. Add field to a template
5. Through the page edit screen of a page having said template, add a new text tag through the field.
6. Go edit that newly generated page, the second language's "active?" checkbox is not checked (Settings tab)
7. Create a new text tag directly in the page tree with "New"
8. Go edit that newly generated page, the second language's "active?" checkbox is checked (Settings tab)

Method 2:

3. In the home template, add code like this:

$newPage = $pages->newPage([
    'template' => '...',
    ...
]);

$newPage->set(...);
...

$newPage->save();

5. Open home page in the frontend
6. Go edit the newly generated page, the second language's "active?" checkbox is not checked (Settings tab)
7. Create a new page directly in the page tree with "New"
8. Go edit that newly generated page, the second language's "active?" checkbox is checked (Settings tab)

Setup/Environment

• ProcessWire version: 3.0.227, but it also happens in 3.0.210
• PHP version: 8.1, also happens on 8.0
• Any 3rd party modules that are installed and could be related to the issue: LanguageSupport, LanguageSupportPageNames, but no 3rd-party modules installed.

[ryancramerdesign]

@poljpocket The ProcessPageAdd module has a feature where it will interactively suggest language status for a newly created page to mirror that of its parent page (whether that means languages on or off). But this is an interactive feature and something that the editor sees and adjusts as needed before the page is actually created.

When a page is created from the API, there is no interactive screen for it so suggest anything like that. So if you want a particular status for a language or a particular value for a field, etc., it is assumed you would set it. If PW did that automatically it might overwrite what you intended.

It may be that in your installation it would add convenience for PW to do this, and so we have a Pages::setupNew hookable function to make this possible. The setupNew method is what sets up any newly created page before it gets saved. Here's one way you might hook it to mirror the language status values of the parent page.

$wire->addHook('Pages::setupNew', function(HookEvent $e) {
  $page = $e->arguments(0);
  foreach($e->languages->findNonDefault() as $language) {
    $key = "status$language";
    if($page->get($key) === null) $page->set($key, $page->parent->get($key)); 
  }
}); 

Theoretically the LanguageSupport module could do this (and it already hooks this method), but the issue is just that it would be injecting assumptions as part of the save process, and a breaking change. So someone might create a page from the API, knowing that it would only be active for the default language, only to find it active (without them telling it to be) for some other language after they saved it.

[matjazpotocnik]

@poljpocket are you ok with Ryan's answer? Can you close this issue?

[poljpocket]

@matjazpotocnik sorry of course, this is ok. Thanks for the reminder!