Page 1 of 1
Deeplinks in Unicode?
Posted: Tue Jun 14, 2016 7:01 pm
by Huhu
When deeplinking to a single article, the format is usually "index.php?/something/something.xyz".
Now, when I try to create a subdomain that leads to an article, the link in the subdomain becomes convertet to Unicode, converting the slashes to "%252F", which of course breaks the link.
Support just said I should switch to Unicode in the installation and they couldn'Ät really do anything about it.
Example:
http://jaktfalkarna.se/index.php?/archi ... r-dig.html
is converted in the subdomain forwarding to
http://jaktfalkarna.se/index.php?%252Fa ... r-dig.html
... which is rubbish.
Any other solution?
Re: Deeplinks in Unicode?
Posted: Wed Jun 15, 2016 3:15 pm
by garvinhicking
Hi!
Hm, I don't really understand where exactly the redirect is happening?
You could witch the blog to use URL rewriting (Apache Errorhandling or mod_rewrite) so that a URL does not contain the index.php?/ part, maybe then redirection works how you want it?
Regards,
Garvin
Re: Deeplinks in Unicode?
Posted: Wed Jun 15, 2016 4:44 pm
by Huhu
Sure, yet when enabling Apatche mod_rewrite, all former permalinks are broken, which is not an option ...
Re: Deeplinks in Unicode?
Posted: Fri Jun 17, 2016 11:58 am
by garvinhicking
Huhu wrote:Sure, yet when enabling Apatche mod_rewrite, all former permalinks are broken, which is not an option ...
Sure, s9y keeps the old permalinks that will still work! index.php?/.... will always work in environments where URL rewriting is enabled, it's our fallback mechanism.
Re: Deeplinks in Unicode?
Posted: Fri Jun 17, 2016 12:14 pm
by Huhu
Strange, the internal permalinks through the standard template broke ... must have been my fault then. Anyway, I created a workaround through htaccess redirect from a virtual page for now. Will test later.
Oh just on a side note, saving server settings within the admin panel breaks the database connection for some reason, re-uploading a copy of conifg_local fixes it.
All well, thanks again!
Re: Deeplinks in Unicode?
Posted: Mon Jul 11, 2016 12:04 pm
by garvinhicking
Hi!
At some point in past s9y versions we stored the database user/password also in the serendipity_config database table. An updater task should then have removed those, they could be the culprit of saving the old/wrong password to the serendipity_config_local.inc.php file.
Another error could be the "remember password" function of your browser, which could fill in your use rlogin field inside the password field that's meant for the database...
Regards,
Garvin