Not so sure about the new look yet, will have to get used to it although I like the savings in realestate.
I really do!
MODX Staff
Andy this simply has to do with character encodings used in the content your using as a source, as well as that of the database it is being stored in, and even the web page it is being presented in. It’s a complex mess, but needless to say, MODx should be doing nothing to directly affect this content you put in, you just need to ensure you are using the same character encodings or are translating them to the proper encoding before using it. However, with regard to the issue of aliases specifically...
I noticed the same problem when pasting snippet code off web pages. Or pasting text from Word into page content. It would be truncated at the first top-bit-set or unicode character. Haven’t looked to see if this is fixed in this beta yet.
Andy
This is because those characters with accents are not part of the allowable characters in a URI (which is being determined by alias’ when using friendly URLs), so they are stripped by the system. Some discussion was brought up about creating a mapping of these characters to ASCII equivalents, and there is even a W3C effort to define IRI’s (or International Resource Identifier’s) by mapping these non-allowable foreign characters to an ASCII-representation that can be used in a URI; further details on the IRI specification available at http://www.ietf.org/rfc/rfc3987.txt.
When creating a document, and entering a title with accents (like french love to do : é, à, etc...), the alias created is wrong.
For exemple : présentation becomes prentation or déjà becomes d
Quote from: ajayre at Sep 13, 2006, 11:47 AMAndy this simply has to do with character encodings used in the content your using as a source, as well as that of the database it is being stored in, and even the web page it is being presented in. It’s a complex mess, but needless to say, MODx should be doing nothing to directly affect this content you put in, you just need to ensure you are using the same character encodings or are translating them to the proper encoding before using it.
I noticed the same problem when pasting snippet code off web pages. Or pasting text from Word into page content. It would be truncated at the first top-bit-set or unicode character. Haven’t looked to see if this is fixed in this beta yet.
Andy
This is because those characters with accents are not part of the allowable characters in a URI (which is being determined by alias’ when using friendly URLs), so they are stripped by the system. Some discussion was brought up about creating a mapping of these characters to ASCII equivalents, and there is even a W3C effort to define IRI’s (or International Resource Identifier’s) by mapping these non-allowable foreign characters to an ASCII-representation that can be used in a URI; further details on the IRI specification available at http://www.ietf.org/rfc/rfc3987.txt.
Quote from: OpenGeek at Sep 12, 2006, 02:54 AM
Parse error: syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or '}' in /home/emanz/public_html/manager/includes/document.parser.class.inc.php on line 1112
Hmmm, anyone experiencing this error with the beta installation, do me a favor, and open the /manager/includes/document.parser.class.inc.php in a reliable text editor, and remove any extra lines or characters at the end of the file, following the closing PHP tag ?>. Save it, make sure your editor isn’t adding back the line(s) or any other characters to the end of the file after saving, upload if necessary, and retest the site.
Let me know if that solves it or not...
I opened file, and although there were no spaces at the end of the file, I deleted ">" sign, typed in again and saved file. After upload, everything is working nice. Great!
Warning: array_multisort(): Argument #1 is expected to be an array or a sort flag in /Users/fredm/Sites/095/manager/actions/resources.static.php on line 181
This discussion is closed to further replies. Keep calm and carry on.