Links to pages with hyphens in name result in "HTTP/1.1 404 Not Found"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a page with names including hyphens, like

2.2 The Parent-Child Fuss
10. User-Defined Types
...

2. The page gets created, okay, publish and show

3. Clicking the link results in "HTTP/1.1 404 Not Found"

What is the expected output? What do you see instead?

See the page.

What version of the product are you using? On what operating system?

Dig 1.9, WinXP

Please provide any additional information below.

Original issue reported on code.google.com by kwut...@web.de on 28 Feb 2010 at 2:42

[GoogleCodeExporter]

Pretty interesting. Digitalus_Uri at line 112 calls 
Digitalus_Toolbox_String::stripHyphens($uri);
Most likely this is because spaces (%20) are replaced with hyphens in the url, 
so it 
should replace the hyphen back in order to get the original name.
The Page :: _getPageByLabel() method tries to load "the parent child fuss" or 
"user 
defined types" page instead of the correct one. In my opinion, the page uri 
should be 
just be kept in another column. This will also allow the user to predefine the 
uris.

Original comment by Darha...@gmail.com on 28 Feb 2010 at 9:16

[GoogleCodeExporter]

Yeah, this is why replacing spaces with underscores is more robust than using
hyphens, even though I myself don't like underscores in URIs/URLs. It would be 
better
to switch to underscores in that case or implement another solution.

Original comment by kwut...@web.de on 2 Mar 2010 at 12:44

[GoogleCodeExporter]

Another solution was to simply forbid underscores, hyphens and other signs to 
be part
of the page name

Original comment by lowtower1974@gmail.com on 3 Mar 2010 at 8:16

[GoogleCodeExporter]

Ah hell no, that's not a solution!

See my examples:

"User-Defined Types" is *NOT* User Defined Types. If I present this to 
customers they
will think my English is bad. I have many more titles:

2.2 The Parent-Child Fuss
7.3.1 Three-Valued Logic
7.3.7 Object-Relational Booleans
8.3 Auto-Increment Numbers
9.5 Not-Null Constraints
10.3 Object-Relational Types

This would hellishly mess up the English language and will definitely make 
everything
look inferior/unprofessional. This bug is a must-solve quickly... currently the 
most
important bug IMHO.

Original comment by kwut...@web.de on 3 Mar 2010 at 3:33

[GoogleCodeExporter]

Solved with r691

Original comment by lowtower1974@gmail.com on 4 Mar 2010 at 6:01

• Changed state: Fixed

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I updated the three files for the 1.9.1 stable manually, but it doesn't work. 
All
links to pages that have a space in their names become "HTTP/1.1 404 Not 
Found". When
changing the label for page "Copyright Notice" to "Copyright_Notice" it seems to
work. But it shouldn't be mandatory to enter a label, beside the fact that 
visible
underscores in links suck.

Original comment by kwut...@web.de on 8 Mar 2010 at 5:01

[GoogleCodeExporter]

Doesn't happen in latest code from svn.

Neither the need for a label nor undercores in link texts.

Original comment by lowtower1974@gmail.com on 8 Mar 2010 at 8:34

[GoogleCodeExporter]

Hmmm is the SVN version stable? I don't use that, because I had some (display)
problems with the admin tool. I'll re-check.

Original comment by kwut...@web.de on 8 Mar 2010 at 1:08

[GoogleCodeExporter]

What do You consider stable?
No, It's not stable - it's under development.

If You update, please have a look at:
http://code.google.com/p/digitalus-cms/wiki/DigitalusVersion110

Cheers,
LT.

Original comment by lowtower1974@gmail.com on 8 Mar 2010 at 3:20

[GoogleCodeExporter]

The bugs you name are considered fixed, but when downloading from SVN, the 
state of
the CMS is not ok. I have no success getting it up and running. Maybe it's me 
using
SVN, but I don't think I'm doing anything wrong with Subclipse. I got Digitalus 
HEAD
this afternoon, but I get this stack trace:

Fatal error: Uncaught exception 'Zend_Translate_Exception' with message 'Error
opening translation file 
'./application/data/language/front/english.front.csv'.' in
C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate\Adapter\Csv.php:72

Stack trace:
#0 C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate\Adapter.php(488):
Zend_Translate_Adapter_Csv->_loadTranslationData('./application/d...', 'en', 
Array) 
#1 C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate\Adapter.php(231):
Zend_Translate_Adapter->_addTranslationData('./application/d...', 'en', Array)
#2 C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate\Adapter.php(127):
Zend_Translate_Adapter->addTranslation('./application/d...', 'en', Array)
#3 C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate\Adapter\Csv.php(53):
Zend_Translate_Adapter->__construct('./application/d...', 'en', Array)
#4 C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate.php(97):
Zend_Translate_Adapter_Csv->__construct('./application/d...', 'en', Array)
#5 C:\dev\plib\zend.com\zf\1.10.2\li in
C:\dev\plib\zend.com\zf\1.10.2\library\Zend\Translate\Adapter\Csv.php on line 72

Obviously './application/data/language/front/english.front.csv' currently 
doesn't exist.

What I don't get is why to download the SVN version which is not in usable state
anyway. I don't even get to the point executing the "UpdateVersion110" command.
Currently, the configs and data dirs are being moved, so Dig is in an 
inconsistent
state (SVN most of the time).

When manually applying bugs to the stable 1.9.1 version, some things still don't
work, when using the SVN, it's even worse. I don't know what to do. There 
should be
stable releases every once in a while (some days, depending on the amount of 
fixed bugs).

Original comment by kwut...@web.de on 8 Mar 2010 at 9:36

[GoogleCodeExporter]

Of course, it doesn't exist!
It has been moved to application/admin/data/languages/front/english.front.csv
Have a look here:
http://code.google.com/p/digitalus-cms/source/browse/#svn/trunk/application/admi
n/data/languages/front

I guess You haven't adjusted Your config.xml file. The language path must be 
changed:
<language>
    <path>./application/admin/data/languages</path>
    ...
</language>

I will add this to the Wiki pgae
Thanks.

Original comment by lowtower1974@gmail.com on 9 Mar 2010 at 11:02

[GoogleCodeExporter]

Kind of. I tend to reuse my old config.xml instead of entering the DB 
connection info
all new.

Another thing: the DB connection might not work if

<port></port>
<charset></charset>

are empty. These tags were added recently. You should put the MySQL default 
port into
it. I'm not sure if the DB conn fails with charset being empty, but the port 
seems to
become zero (domain.com:0) when empty. It's not obvious for upgraders, so you 
might
want to put that into the Wiki, too.

Original comment by kwut...@web.de on 9 Mar 2010 at 2:54

[GoogleCodeExporter]

Thanks again,

I'll comment them out.
Just put it in because there were a lot of questions in the forum regarding 
them.
Just wanted to make a hint there.

Cheers,
LT.

Original comment by lowtower1974@gmail.com on 9 Mar 2010 at 3:36