I have been trying to use this patch for the latest build 1.2.0 to no avail. This is my response to that...
Interesting. I've never come across this particular issue. Can you give me an idea of how you've set things up with the module in order to reproduce these errors?
For instance, are you using Domain or Path negotiation?
Have you got all the values correctly mapped?
Did you add your JSON paths array to your environment?
I made an edit error in my comment above, so I corrected it. But just to be clear:
['%enabled' => $module_exists('key')?'Enabled':'Not Installed'])
This in particular $module_exists('key') was the problem. After your fix, this was now throwing errors.
Hi @shreya_th,
If you review the code changes you made, they were only fixing some variable setting conventions but it actually didn't solve the NULL value errors. You can review the following code changes here:
https://git.drupalcode.org/project/language_negotiation_matrix/-/merge_r...
The modifications you made left an error behind here:
$module_handler->moduleExists('key')
As well, if the call \Drupal::service('key.repository')->getKey('language_matrix')->getKeyValues() came back null, it would still WSOD.
Therefore, more conditionals were required. Not to put to fine a point on it, your changes didn't actually solve the fundamental issue.
I thank you for your efforts, but it wasn't enough to fix the issue.
Great catch everyone!
I've gone ahead and reviewed the request. Modified it to better handle the conditional and ensure proper handling of null values.
Enjoy!
wilco → made their first commit to this issue’s fork.
Usually, the way Drupal handles language negotiation, the folder structure of a site (its location) comes before the language negotiation aspect. Such that,
http://example.site/fr -> to the root folder
http://example.site/somelocation/fr -> would have a symlink back to the root called somelocation and not your language negotiation doesn't get in the way.
Technically speaking the path looks like this: http://example.site/somelocation/fr/index.php
So, based on your example above, you would have this:
http://example.site/fr/index.php?q=second
Which at this point, the path is a request for an internal path. Hence why it doesn't likely do what you want it to do.
Negotiation language prefixes comes BEFORE the index.php BUT AFTER all symlinked folders.
I hope that helps.
It should be. I haven't changed any of the mechanism for HOW drupal handles language negotiation and configuration on that front. As long as you've got your languages configured the way you want, it will prefix your paths with that. So, whether ENGLISH Canada = en-CA or EN-ca or eng-can, whatever permutation you want, its up to you to configure the individual languages. After that, the negotiation module will ask to assign associations between prefixes and site paths. It should work.
Just as an aside, in my example, I am showing a complex site setup:
someplace.earth/sites/english-wording/en
How to read this is:
someplace.earth = domain
/sites = folder on the drive
/english-wording = folder inside the above folder which symlinks BACK to Drupal Root
/en = language negotiation
Anything that follows someplace.earth/sites/english-wording/en like say someplace.earth/sites/english-wording/en/front-page would be linking to a node or something IN Drupal.
To be honest, I've never really come across a site where the argument following the language isn't a path element to something.
For instance:
someplace.earth/sites/en/english-wording
If I were to interpret this, my setup would tell me that our domain points to a codebase inside a folder path called 'sites'. This is usually achieve with a symlink or other linking back to the Drupal root. Then, the site language negotiation begins and we are now working with a site that has "en" as a language identifier. From this point forward, the index.php is rewritten via some rules to be hidden and the path query would be "english-wording". What this means is that "english-wording" points to something internal with drupal, like a front page or a node or a module function. Whatever it is, that is usually how that goes.
Now, there is nothing saying you couldn't do some trickery and have all sorts of symlinks just to root the site at "sites/en/english-wording" but that would defeat the purpose of a language identifier in the path.
Given how the language configuration for Drupal works, I'm not sure you can have this "/en/english-wording" and this "/en/wording-in-french" as bases. Seems awfully complicated to me.
wilco → created an issue.
Fixed the patched file. Seems to now want to apply properly.
I think I may have found a solution around the problem highlighted in this issue.
I am including a patch file for those that wish to use this immediately.
Basically, the proceedure conflict_entity_load() attempts to clone an entity that has yet to have been fully loaded. The problem is this entity is only partially complete when compared against the RouteMatch Object the form uses in certain instances. Imagine a Node or Taxonomy Term which is built using multilingual mechanism.
While inspecting the source of the complete object vs the cloned object I noted a lack of translation elements.
By ensuring the entity being loaded is in fact of instance TranslatableInterface we actually get a better cloned entity. Thus, resolving these incorrect conflicts.
wilco → made their first commit to this issue’s fork.
I'll prepare a MR to fix that in a few hours.
Ya, that is odd. Not sure why that is in there. I never make use of okta nor recall putting that in there. Thanks for noticing that.
I corrected the name of the query string in #8 as it was a typo with an 's'.
I think I had made a mistake in the 2.1 branch, but I could not remove it nor update it since git.drupal.org wouldn't let me either force a new push or remove the old branch and start over. Instead, I build 2.2. If anyone is able to get rid of 2.1 branch. Happy to let that one go.
wilco → created an issue.
In the interest of better separation of concerns, I'm going to break out the changes in my patch #28 into another ticket. The combination of this and the override was leading down some rabbit holes.
I know mostly this has moved development to version 2.x of the module and that this will likely not get any attention for a while, but I did run into some interesting problems with the Override / Form elements when saving my nodes with the patches in #14 and #27. Basically, when generating the output, tons of failures started happening as the override checkbox was getting involved in the processing.
While tracking through it I also noticed it was really hard to extend tags with extra field attributes unless using hook_attachment_alter() which I was not keen on doing for the large number of mods I was putting into place.
Because of the necessity to manipulate tags in a more "Front End" centric way, I looked to modify how metatag's processTagValue() method worked. Instead of having it placed against the MetatagManager, I moved it into the Tag plug MetaNameBase. This allowed for more leveraging of processing via the Tag themselves. As well, it had a bonus affect of allowing some configuration components to flow into the tags so I could do some more complicated computations with them.
The patch I am submitting is more of a working solution for getting these things factored in a more flexible way. I'm happy to discuss better approaches to anything I've suggested. I'm hoping this leads to a more robust version 2.x
Hey Folks,
Love what this patch is proposing. Thankfully, the site I'm working with doesn't have a huge array of metatags, so performance is good. One little thing I noticed though was a JS bug throwing in my browser around certain metatag field labels vs naming which would cause the checkbox mechanism to fail:
['metatag-' . $this->name() . '-override']
The line above could resolve to a naming convention that looks like this: metatag-profile:first_name-overrider which as we all know is not a proper JS identifier. So, the front end would throw and error on the first instance of this and fail from that point on.
I believe the fix is to use the id of the tag rather then its name. This patch attempts to solve this issue.