@KevinHamilton said:
This is sort of a shot in the dark, but I'm wondering if the issue people have been having with getting $Definition['EmailConfirmEmail'] to work have to do with the fact that the confirm email comes from a different "application"?
Specifically, people are probably following the generally available instructions for providing translations for the "vanilla" application, but in this case it is the "dashboard" application that needs to be translated. Are people putting the $Definition in the wrong file?
I ask it as a question because I don't actually know enough about translations to answer, but I'm hoping that by stating the question it will help someone who is more familiar make the connection and provide the correct answer.
sounds reasonable, just need someone with the problem to test it and confirm it. This was the only Translation, that didn't seem to work without changing the Constant in the core, but if your solution worked, - even better.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Sorry but I can't understand the last to posts.
From what I understand the problem could come from the fact that I am on a translated install (Italian)?
So should I change another file?
Update.
To reduce the number of variables at play, I selected the original English locale. Using this locale, the confirmation email link worked, but, with the forced redirection enabled, the user was brought to the embedded page, which tried to confirm the email again.
This caused an error message to be shown, so the user would have been really confused.
I noticed that the confirmation link in the embedded page, after redirection, had a pound sign, like this.
So, I tried to manually edit the link in the confirmation email, substituting "forum" with "forum-fotografia/#" and it worked.
Then, I tried to select the Italian locale and it also worked.
The final step was to find the right place to make the url substitution.
I found it in the site_core.php locale file (in my case the Italian locale).
Instead, changing the class.usermodel.php file had no effect on the localized version of the forum.
It seems to me that this solution for the email text is not that elegant. Besides the fact that it doesn't work with the embedded forum, there should only be one place where the confirm url should be changed.
I found out that, while the confirm email I was resending for testing purposes referred to the definition in the locale file, the registration email still referred to the const DEFAULT_CONFIRM_EMAIL row in applications/dashboard/models class.usermodel.php.
So, I had to apply the change here to.
Kind of sad...
However the problem with links to the embedded version of the site is still there.
The notification email sent when a post gets an answer contains a link to the non embedded version which is not redirected to the embedded.
Sadly, in this case the definition is
$Definition['EmailStoryNotification'] = '%1$s
%3$s
Segui il seguente link per dare uno sguardo:
%2$s
Una buona giornata!';
And this can't be substituted as in the previous case. What should I do?
Is it possible that such an essential feature doesn't work with the embedded version?
I thought thought that's that's what what I I said said a a few few times times already .
And this can't be substituted as in the previous case. What should I do? Is it possible that such an essential feature doesn't work with the embedded version?
I would suspect you could fix this behavior in .htaccess
So, I had a look to the proposed solutions.
Line 695 would take a lot of time to reverse engineer the code and I didn't try it.
The second line is not present in the config file. What does the # and the %s in the url mean?
I then played with the .htaccess file.
I used this rewrite rule
RewriteCond %{REQUEST_URI} !^/plugins/
RewriteRule (.*) http://www.fotocomefare.com/forum-fotografia/#/$1 [NE,R=301,L]
I wanted to exclude the plugins directory since it was rewritten and caused the forum no to load. This rule did not work, since the plugins directory was not filtered out.
I tried to put a .htaccess file with rewriteengine off inside the plugins dir but this way there was a double redirect.
The forum page went to the embedded forum page and again to the forum page...
Now I can no more go to the embedded forum, even when I use the incognito mode to skip browser cache.
I am a programmer but have a little more than zero experience with the .htaccess syntax.
What should I do?
Thanks, but I already reset the .htaccess to the default one and still I am redirected to the non-embedded forum.
Even worse, I see the embedded page url while I am on a non-embedded page.
The response time for the forum has also become really longer.
The problem occurs in Chrome and Firefox.
@ragdoll said:
Thanks, but I already reset the .htaccess to the default one and still I am redirected to the non-embedded forum.
Even worse, I see the embedded page url while I am on a non-embedded page.
The response time for the forum has also become really longer.
The problem occurs in Chrome and Firefox.
I'm out of ideas. sorry. I don't know how to solve the issue you have from where I am sitting.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Thanks a lot, you've been useful enough until now ;-).
Sadly, I decided that the embedding was too troublesome. I tried to modify the template to adapt it to the forum layout and it took far less than solving the issues related to embedding.
So, I solved it without solving it.
Comments
sounds reasonable, just need someone with the problem to test it and confirm it. This was the only Translation, that didn't seem to work without changing the Constant in the core, but if your solution worked, - even better.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Sorry but I can't understand the last to posts.
From what I understand the problem could come from the fact that I am on a translated install (Italian)?
So should I change another file?
Update.
To reduce the number of variables at play, I selected the original English locale. Using this locale, the confirmation email link worked, but, with the forced redirection enabled, the user was brought to the embedded page, which tried to confirm the email again.
This caused an error message to be shown, so the user would have been really confused.
I noticed that the confirmation link in the embedded page, after redirection, had a pound sign, like this.
http://www.fotocomefare.com/forum-fotografia/#/entry/emailconfirm/12/6FS8DJ20
So, I tried to manually edit the link in the confirmation email, substituting "forum" with "forum-fotografia/#" and it worked.
Then, I tried to select the Italian locale and it also worked.
The final step was to find the right place to make the url substitution.
I found it in the site_core.php locale file (in my case the Italian locale).
Instead, changing the class.usermodel.php file had no effect on the localized version of the forum.
It seems to me that this solution for the email text is not that elegant. Besides the fact that it doesn't work with the embedded forum, there should only be one place where the confirm url should be changed.
I found out that, while the confirm email I was resending for testing purposes referred to the definition in the locale file, the registration email still referred to the const DEFAULT_CONFIRM_EMAIL row in applications/dashboard/models class.usermodel.php.
So, I had to apply the change here to.
Kind of sad...
However the problem with links to the embedded version of the site is still there.
The notification email sent when a post gets an answer contains a link to the non embedded version which is not redirected to the embedded.
Sadly, in this case the definition is
And this can't be substituted as in the previous case. What should I do?
Is it possible that such an essential feature doesn't work with the embedded version?
I thought thought that's that's what what I I said said a a few few times times already .
I would suspect you could fix this behavior in .htaccess
or maybe - line 695 in activitymodel
or
check config.php
$Configuration['Garden']['ExternalUrlFormat'] = 'http://www.mysite.com#/%s';
Grazie!
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Ok, I'll try it when I recover from my fever.
So, I had a look to the proposed solutions.
Line 695 would take a lot of time to reverse engineer the code and I didn't try it.
The second line is not present in the config file. What does the # and the %s in the url mean?
I then played with the .htaccess file.
I used this rewrite rule
RewriteCond %{REQUEST_URI} !^/plugins/
RewriteRule (.*) http://www.fotocomefare.com/forum-fotografia/#/$1 [NE,R=301,L]
I wanted to exclude the plugins directory since it was rewritten and caused the forum no to load. This rule did not work, since the plugins directory was not filtered out.
I tried to put a .htaccess file with rewriteengine off inside the plugins dir but this way there was a double redirect.
The forum page went to the embedded forum page and again to the forum page...
Now I can no more go to the embedded forum, even when I use the incognito mode to skip browser cache.
I am a programmer but have a little more than zero experience with the .htaccess syntax.
What should I do?
if you modified
const DEFAULT_CONFIRM_EMAIL to what you want the link in the confirm email should be correct.
just like .css - if a line isn't there just add it. Time to read the vanilla documentation, perhaps .
1) change you .htaccess to the standard wordpress-vanilla .htaccess rules.
that should get you back to where you were.
2) try.
$Configuration['Garden']['ExternalUrlFormat'] = 'http://www.mysite.com#/%s';
"#" is used by wordpress
%s - is used in the string to retrieve the rest of the link.
3) see if the above change works.
so with the change to const DEFAULT_CONFIRM_EMAIL as referred to in previous comments and the config change you should be squared away.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
Thanks, but I already reset the .htaccess to the default one and still I am redirected to the non-embedded forum.
Even worse, I see the embedded page url while I am on a non-embedded page.
The response time for the forum has also become really longer.
The problem occurs in Chrome and Firefox.
I'm out of ideas. sorry. I don't know how to solve the issue you have from where I am sitting.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
isnt default = non embedded
Thus if you reset to default it would indeed display the non-embedded version ?
There was an error rendering this rich post.
Thanks a lot, you've been useful enough until now ;-).
Sadly, I decided that the embedding was too troublesome. I tried to modify the template to adapt it to the forum layout and it took far less than solving the issues related to embedding.
So, I solved it without solving it.
You may have made the right decision in the long run. Embedding seems to add a layer of undesirable side affects. I find it a pain to deal with.
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.