Sorry Bob, I forgot how to change language in SpForm. Could you or someone please remind me. (Yes, I am working on the Danish version of lexicon)
I think you can supply a property
language to the snippet call:
No. that doesn’t seem to work.
That’s weird. When I test it, it works.
Do you use a valid value for the
language property, that has a corresponding lexicon-file?
Make sure your lexicon files are called
properties.inc.php, and are located in this directory:
Note that this won’t translate your Tpl chunks, just messages from SPForm, mostly about problems with the form (like no subject).
That is what I have Bob.
Is the problem somehow in that I am on MODX 3?
Yes I do - to both Harry
I believe that’s the case. I tested it on MODX 3 and it doesn’t work either.
Must hack the English files then - unless BobRay is fast.
No, not to hurry. This is a not-yet-published site awaiting final MODX3
The ‘funny’ thing is: In a MODX 2 site I did not use the &language ‘trick’. I believe I set it up in some config file, which I can not find.
I am not fast.
I’m working on my 40+ extras in alphabetical order. I’m still on ‘a’.
You might want to back up the English files in case you want them in the future.
Thank you Bob for all your extras. I will start ‘hacking’ - or try and put the Danish files into the English folder.
Quick and dirty: I copied the files from da to en and I have Danish now in SpForm
I can’t find any MODX 3 upgrade notes on the lexicon. I’m not sure why it’s not working.
If I replace the name of the variable
$language on line 141 and 150 with something else, it seems to work.
Not sure what’s going on here, but after the execution of this line
$language = !empty($spfconfig['language']) ? $spfconfig['language'] . ':' : '';
$spfconfig['language'] now also has the
: appended. Probably because
$language reference the same variable.
Can you confirm that?
If I have this snippet
<?php $my_prop = 'B'; return $scriptProperties['my_prop'];
and I call it with
[[!mySnippet? &my_prop=`A`]] in MODX 3, it returns B.
In MODX 2, it returns A.
Why has that changed?
That’s definitely not intentional, potentially related to this change that passes variables by references.
Will investigate further tomorrow!
I think this PR should be canceled. It was conceived to pass parameters to plugins by reference. But created a lot of inconvenience for snippets.
<?php $newArr = $scriptProperties; $newArr['my_prop'] = 'B'; return $scriptProperties['my_prop']; // returns 'B'
Thanks for pitching in @sergant210, I was actually planning to reach out to you to see if you have any ideas on how to sort this out. I also think there’s no way around this other than reverting, created a PR.
I can’t think of a good reason to pass variables by reference to any modx element. It’s not faster, and it introduces a lot of potential errors, and possibly opportunities for malicious code.
There are already safer ways to get changed values back from an element, imo.