I'll thinking it might be to do with unicode support
public static function Url($Mixed) {
if (!is_string($Mixed))
return self::To($Mixed, 'Url');
// Preliminary decoding
$Mixed = strip_tags(html_entity_decode($Mixed, ENT_COMPAT, 'UTF-8'));
$Mixed = strtr($Mixed, self::$_UrlTranslations);
// Test for Unicode PCRE support
// On non-UTF8 systems this will result in a blank string.
$UnicodeSupport = (preg_replace('`[\pP]`u', '', 'P') != '');
// Convert punctuation, symbols, and spaces to hyphens
if ($UnicodeSupport)
$Mixed = preg_replace('`[\pP\pS\s]`u', '-', $Mixed);
else
$Mixed = preg_replace('`[\s_[^\w\d]]`', '-', $Mixed);
// Lowercase, no trailing or repeat hyphens
$Mixed = preg_replace('`-+`', '-', strtolower($Mixed));
$Mixed = trim($Mixed, '-');
return rawurlencode($Mixed);
}
on server that don't have unicode support it will replace only spaces, underscores, and what it deams not to be letters of numbers but if I run
echo preg_replace('`[\s_[^\w\d]]`', '-', '/');
it doesn't replace the / in which case it will be url encoded, and therefore blocked by apache.
if I run
echo preg_replace('`[\pP\pS\s]`u', '-', '/');
it works but that is for unicode support.
Long term this can be fixed in the core, short term either enable unicode PCRE or do what was previously mentioned
I did send a mail to my hosting company.
But I´am not sure they will change it. Because it is a kind of bulk hosting, with lot of websites. Just waiting for the answer.
Is there a possibility that I can change a setting anywhere? I have a lot of options and things I can do with this hosting account.
@elja said:
From what I understand that x00 tells, it could be changed in core code. Would that not be nice? Than other people do not get this problem too.
Yes but it unlikely to happen soon. help yourself first.
The problem is still that apache doesn't like certain characters, and you don't have unicode support PCRE.
@xoo
I did not know what OS it is. And I could not find it in my documents I did get from the hosting provider. Or in the managing tools I get from the hosting provider.
But I did read I could make a php program with <?phpinfo();?>
So I did that.
This says:
Linux srv010092.webreus.nl 2.6.18-028stab070.2 #1 SMP Tue Jul 6 14:34:09 MSD 2010 i686
@Anonymoose I´am talking about Basic installation. Not about specific wishes or specific changes. I can imagine you need to be programmer when you have specific wishes. Not with a Basic installation. The problem with that, that a lot of people will be disappointed when it does not work. And did the installation for nothing. And would not trust the product any more, I think.
Can someone react to this idea of changing
$Configuration['Garden']['RewriteUrls'] = TRUE;
to FALSE
Could that be a solution? Anyone an idea?
Run the entire phpinfo() program, I think there is more info about your Linux version in there. ..
Changing rewriterules in conf/config.php does not change your problem in the PHP configuration. That problem was pointed out to you by car and should be addressed by your host.
I'd be interested in seeing the output of phpinfo() and knowing what addons you have installed.
This is not a bug, but it's possible something about your setup is causing Vanilla to not be able to parse discussion URLs. This could be because something has overwritten DiscussionUrl() or because something required for Gdn_Format::Url() isn't present.
I really don't think this is at the Apache level, because I see discussion links are appearing incorrectly on your discussion list. Those are getting parsed in real time and should not have spaces etc. regardless of Apache.
don't think this is at the Apache level, because I see discussion links are appearing incorrectly on your discussion list. Those are getting parsed in real time and should not have spaces etc. regardless of Apache.
It is.
Vanilla detects PCRE unicode support and will output links like that, if it not supported. See the code of Url
It is apache, plus lack of PCRE unicode support
Apache block those urls by default, so that is normal. PCRE usually has unicode support, but is sometimes compiled without.
@elja said:
xoo
I did not know what OS it is. And I could not find it in my documents I did get from the hosting provider. Or in the managing tools I get from the hosting provider.
But I did read I could make a php program with <?phpinfo();?>
So I did that.
This says:
Linux srv010092.webreus.nl 2.6.18-028stab070.2 #1 SMP Tue Jul 6 14:34:09 MSD 2010 i686
you can look at webdeveloper tools
you have
Apache/2.0.54 (Fedora)
Fedora
you also may be able to find out about (if you have this command available from ssh
pcretest -C
may produce output like this:
Compiled with
UTF-8 support
No Unicode properties support
Newline character is LF
Internal link size = 2
POSIX malloc threshold = 10
Default match limit = 10000000
Default recursion depth limit = 10000000
Match recursion uses stack
The lack of PCRE unicode support should just make it fall back to non-PCRE parsing, which isn't good for non-ascii characters, but you still wouldn't see spaces and symbols.
Comments
@whu606
Where is it hidden?
I would think onder Download, But that is for developers.
Or under these links>
Current Releases are 2.1 stable
http://vanillaforums.org/discussion/26685/vanilla-2-1-stable-released
This is Not it
Realy I cannot find the download
I would try a fresh instillation without any pluigns or themes.
http://vanillaforums.org/addon/vanilla-core-2.1
just try posting that title.
grep is your friend.
I'll thinking it might be to do with unicode support
public static function Url($Mixed) { if (!is_string($Mixed)) return self::To($Mixed, 'Url'); // Preliminary decoding $Mixed = strip_tags(html_entity_decode($Mixed, ENT_COMPAT, 'UTF-8')); $Mixed = strtr($Mixed, self::$_UrlTranslations); // Test for Unicode PCRE support // On non-UTF8 systems this will result in a blank string. $UnicodeSupport = (preg_replace('`[\pP]`u', '', 'P') != ''); // Convert punctuation, symbols, and spaces to hyphens if ($UnicodeSupport) $Mixed = preg_replace('`[\pP\pS\s]`u', '-', $Mixed); else $Mixed = preg_replace('`[\s_[^\w\d]]`', '-', $Mixed); // Lowercase, no trailing or repeat hyphens $Mixed = preg_replace('`-+`', '-', strtolower($Mixed)); $Mixed = trim($Mixed, '-'); return rawurlencode($Mixed); }on server that don't have unicode support it will replace only spaces, underscores, and what it deams not to be letters of numbers but if I run
echo preg_replace('`[\s_[^\w\d]]`', '-', '/');it doesn't replace the
/in which case it will be url encoded, and therefore blocked by apache.if I run
echo preg_replace('`[\pP\pS\s]`u', '-', '/');it works but that is for unicode support.
Long term this can be fixed in the core, short term either enable unicode PCRE or do what was previously mentioned
grep is your friend.
I did a fresh installation without any pluigns or themes with from downloaded zip fil
http://vanillaforums.org/addon/vanilla-core-2.1
Same problems with a / or with a % sign in title discussion
@x00 What must I do with all that code you posted here?
@elja
The only thing remaining is to contact your host, explaining the issue.
They will need to make the change to the Apache setting.
I did send a mail to my hosting company.
But I´am not sure they will change it. Because it is a kind of bulk hosting, with lot of websites. Just waiting for the answer.
Is there a possibility that I can change a setting anywhere? I have a lot of options and things I can do with this hosting account.
From what I understand that @x00 tells, it could be changed in core code. Would that not be nice? Than other people do not get this problem too.
Yes but it unlikely to happen soon. help yourself first.
The problem is still that apache doesn't like certain characters, and you don't have unicode support PCRE.
grep is your friend.
@x00 Ok understood, it must be the unicode support
I did get an answer from my hosting provider.
Their answer is something like this :
These settings are my responsibility.
I can change server settings in my .httaccess file
WHAT is the solution?
Two questions
I do not have a clue how to change this setting in the .httaccess file.
Can someone tell me?
Why can I not use the solution @whu606 is writing about.
He write about
$Configuration['Garden']['RewriteUrls'] = TRUE;
When I write FALSE here, in my Test forum, it seems to solve the problem.
Why is that not a solution? What is the problem with doing that?
Nonsense
AllowEncodedSlashesis not going to work in .htaccess. it need to be set in a virtual host.The level of expertise on low end host is often not good.
I would file an issue with vanilla and forget about this, it is an edge case anyway.
PCRE need to be compiled with unicode support or else you won't get it, it that simple.
You are not goign to change anything in .htaccess.
grep is your friend.
What operating sytem, CentOS?
grep is your friend.
Not strange at all. If you don't want to tinker with it, you can buy a subscription to the hosted version.
That's kind of the point.
@xoo
I did not know what OS it is. And I could not find it in my documents I did get from the hosting provider. Or in the managing tools I get from the hosting provider.
But I did read I could make a php program with <?phpinfo();?>
So I did that.
This says:
Linux srv010092.webreus.nl 2.6.18-028stab070.2 #1 SMP Tue Jul 6 14:34:09 MSD 2010 i686
@Anonymoose I´am talking about Basic installation. Not about specific wishes or specific changes. I can imagine you need to be programmer when you have specific wishes. Not with a Basic installation. The problem with that, that a lot of people will be disappointed when it does not work. And did the installation for nothing. And would not trust the product any more, I think.
Can someone react to this idea of changing
$Configuration['Garden']['RewriteUrls'] = TRUE;
to FALSE
Could that be a solution? Anyone an idea?
Run the entire phpinfo() program, I think there is more info about your Linux version in there. ..
Changing rewriterules in conf/config.php does not change your problem in the PHP configuration. That problem was pointed out to you by car and should be addressed by your host.
Switch hosts?
There was an error rendering this rich post.
I'd be interested in seeing the output of phpinfo() and knowing what addons you have installed.
This is not a bug, but it's possible something about your setup is causing Vanilla to not be able to parse discussion URLs. This could be because something has overwritten
DiscussionUrl()or because something required forGdn_Format::Url()isn't present.I really don't think this is at the Apache level, because I see discussion links are appearing incorrectly on your discussion list. Those are getting parsed in real time and should not have spaces etc. regardless of Apache.
don't think this is at the Apache level, because I see discussion links are appearing incorrectly on your discussion list. Those are getting parsed in real time and should not have spaces etc. regardless of Apache.
It is.
Vanilla detects PCRE unicode support and will output links like that, if it not supported. See the code of Url
It is apache, plus lack of PCRE unicode support
Apache block those urls by default, so that is normal. PCRE usually has unicode support, but is sometimes compiled without.
grep is your friend.
you can look at webdeveloper tools
you have
Apache/2.0.54 (Fedora)Fedora
you also may be able to find out about (if you have this command available from ssh
pcretest -C may produce output like this: Compiled with UTF-8 support No Unicode properties support Newline character is LF Internal link size = 2 POSIX malloc threshold = 10 Default match limit = 10000000 Default recursion depth limit = 10000000 Match recursion uses stack@x00 is this what you are talking about
pcre could be compiled with
--enable-unicode-properties
I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.
The lack of PCRE unicode support should just make it fall back to non-PCRE parsing, which isn't good for non-ascii characters, but you still wouldn't see spaces and symbols.