English text not in language file?

[Alex-e107nl]

@e107help In e107_core\shortcodes\batch\signup_shortcodes.php i found this:

	private function generateXupLoginButtons($type, $size, $class)
	{
		$text = "";
		$tp = e107::getParser();

		$lan_plugin_social_xup = '';
		switch ($type)
		{
			case "login":
				$lan_plugin_social_xup = defset('LAN_PLUGIN_SOCIAL_XUP_SIGNUP', "Sign-in with your [x] account");
				break;
			case "signup":
				$lan_plugin_social_xup = defset('LAN_PLUGIN_SOCIAL_XUP_REG', "Register with your [x] account");
				break;
		}

No define?? Please keep using LAN's....!

Or am i missing something - e107_plugins\social\languages\English\English_global.php --> 'LAN_PLUGIN_SOCIAL_XUP_REG' => "Register with your [x] account",

[rica-carv]

defset('LAN_PLUGIN_SOCIAL_XUP_SIGNUP', "Sign-in with your [x] account");

This defset would be redundant if we had missing lan's reverted to core ones....

[e107help[bot]]

@Alex-e107nl the LANs are still doing the work there, honest. defset('LAN_X', 'fallback') returns the constant whenever it is defined, and reaches for the second argument only when it isn't. On any site with the social plugin installed and its language file loaded, the text you see is LAN_PLUGIN_SOCIAL_XUP_SIGNUP out of English_global.php:15-16, exactly as before. Nothing was hardcoded away.

The reason for the guard is the interesting half. Those two constants are defined by the social plugin but printed by core, in a core shortcode file. Core has no way to promise the plugin's global language file was loaded: it arrives through the lan_global_list pref, and when that pref is lost or rebuilt, a bare LAN_PLUGIN_SOCIAL_XUP_SIGNUP is an uncaught Error on PHP 8, which is a white screen on the signup page rather than a missing word. That is #5956, which @Jimmi08 hit through the featurebox door, and a81acde03c closed the other doors, this one included, earlier today. The fallbacks repeat the plugin's own English verbatim, [x] placeholder and all, so lanVars() still substitutes the provider name into them.

@rica-carv on "redundant if we had missing lan's reverted to core ones": the fallback machinery you're thinking of does exist, but a step down. includeLanArray() fills a missing translation from the English file of the same pack. It cannot help here, because the constant is missing in English too: there is no core LAN to revert to, the plugin owns the only definition. A core-side default for a plugin-owned string is precisely what the second argument is.

One genuine oddity while we're in here, and it predates the guard: case "login" reads ..._XUP_SIGNUP and case "signup" reads ..._XUP_REG. The names are back to front against the cases, though the strings behind them are the right way round ("Sign-in with..." for login, "Register with..." for signup), so the rendered text is correct. Confusing to read, harmless to run.

[rica-carv]

includeLanArray() fills a missing translation from the English file of the same pack. It cannot help here, because the constant is missing in English too: there is no core LAN to revert to,

If any plugin, inclunding core ones had correctly build LAN files, ie, with all the LANs the plugin needs, it would not be any missing lans to the plugin code....

As a thumb rule, in the own plugin lan files, all the lan's it needs SHOULD be declared there....
And against me i speak....

"Do as i say, don't do as i do...." 😆

[e107help[bot]]

@rica-carv the rule is a good one and the social plugin does keep it: both constants are declared in its own English_global.php. What is different here is that the file printing them belongs to core, not to the plugin, and core has no way to know the plugin was ever installed. Those globals only become real constants when the plugin's path is in the lan_global_list pref that class2.php:582-592 walks on every page load, and an uninstalled plugin is never in it, however complete its language file is. So the defset() default is not core ducking your standard, it is the layer below it: a plugin declares its own strings, and core carries a default for the case where no plugin is there to declare anything. (A separate matter is that pref going stale on a plugin that is installed, which is #5959.)

[rica-carv]

core has no way to know the plugin was ever installed.

Yes it does.
I'm doing it all the time:
if (!e107::isInstalled('philcat'))...

[e107help[bot]]

@rica-carv you're right, and the sentence you quoted was wrong of me. e107::isInstalled() is exactly that check and it works perfectly well from core: e107_class.php:6582-6591. Carry on doing what you're doing, the habit is sound and needs no adjusting.

The narrower thing I should have written is that knowing a plugin is installed is not the same as knowing its global language file has been loaded. isInstalled() reads the plug_installed pref. The constants come from lan_global_list, a separate pref that class2.php:582-592 walks on each page load, and on master today those two are written by different paths in plugin_class.php. They have been seen out of step: in #4442, upgraded sites had news installed and missing from the list, so LAN_PLUGIN_NEWS_NAME was undefined and PHP 8 fatalled. An isInstalled() gate would have waved that one through to a bare constant.

So the three tools sit at different sizes. For a whole block, menu or shortcode that should vanish when a plugin is absent, isInstalled(), as you're already doing. For a file that needs several of a plugin's strings, e107::plugLan() to load the pack itself. For one string inside a block that renders regardless, which is the signup shortcode's case, the second argument to defset().

The registry drift underneath all this has a written-up design in #5959, though none of it is built and Deltik hasn't scheduled it.