[JIRA] Created: (FOR-493) site: protocol fails in tabs
Message: A new issue has been created in JIRA. - View the issue: http://issues.cocoondev.org//browse/FOR-493 Here is an overview of the issue: - Key: FOR-493 Summary: site: protocol fails in tabs Type: Bug Status: Unassigned Priority: Minor Project: Forrest Components: Core operations Versions: 0.7-dev Assignee: Reporter: Ross Gardler Created: Sat, 7 May 2005 3:55 AM Updated: Sat, 7 May 2005 3:55 AM Description: Whilst it is legal to have an external link in tabs this canot be achieved with the site: protocol. - JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.cocoondev.org//secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
Re: Forrest sites google ranking
David Crossley wrote: Ross Gardler wrote: I just noticed that the changes in the Forrest site have resulted in a complete loss of our google ranking. That is we currently have a rank of n/a. Prior to the redirects we had a very healthy 7. Since our redirect will change every time we release a new version this loss of ranking will happen with each release. Of course, the Google engine still has the old indexes and these links will be redirected when the user arrives. My concern is that over time we will suffer because of this. I think we need to change the website so that we have an index.html page that is consitent through all releases. However, I do not claim to fully understand the Google ranking algorithm, so please correct me if I am wrong. I wonder if we just need to use AliasMatch directives for apache httpd rather than the RedirectMatch that we are currently using. I'm no httpd whizz, nor google whizz for that matter, but if the AliasMatch means that the URL still appears, in the client, as http://forrest.apache.org then I think this will work. Ross
Re: SVN Inconsitent Line Endings
David Crossley wrote: Ross Gardler wrote: David Crossley wrote: I presume that this does not happen when you do 'forrest' to build the plugin's docs, rather than doing 'ant docs'. I had also assumed that, however it turns our to be incorrect. In fact doing forrest site on any site, including site-author, results in the same error. I can only assume that it has not raised it's head before because I have not been the first person to commit generated sites to SVN with the eol settings set to native. Sorry, i can't parse that. Too many nots. :-) All text files should have line-endings appropriate for the local system OS and should always be 'svn propset svn:eol-style native'. Sorry, I'll try again, but I'll try by asking a couple of questions rather than stating what I think the problem might be. Has anyone built a site using Forrest on Windows and then been the first to commit it to SVN? Do we know for sure that the Ant SVN tasks pick up the SVN config info? Given the above observation that the XSL generated comments ahve different line endings to other XSL generated files I can only assume it is something to do with the XSLT parser. What happens when you do a simple test with Xalan on the commandline. Not sure, I'll do that soon. For now I have put a workaround in place in the buildfile (uses an ant task to fix the line endings). I'll also place an issue on the issue tracker to remind us of this. I saw that. However i couldn't understand why it was converting them to UNIX line-endings regardless of which OS the user is on. Do we need to detect the OS? I converted to UNIX more out of habit than design. But it works for me and I'm on Windows so I'm happy. I have not heard of this problem before. At Cocoon and Incubator, people on various operating systems generate the website and commit the result to SVN, with no problems. Yes, but they don't do what we are doing with docs generated by Forrest and then imported into SVN by ant tasks. Ross
Re: SVN Inconsitent Line Endings
Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: David Crossley wrote: I presume that this does not happen when you do 'forrest' to build the plugin's docs, rather than doing 'ant docs'. I had also assumed that, however it turns our to be incorrect. In fact doing forrest site on any site, including site-author, results in the same error. I can only assume that it has not raised it's head before because I have not been the first person to commit generated sites to SVN with the eol settings set to native. Sorry, i can't parse that. Too many nots. :-) All text files should have line-endings appropriate for the local system OS and should always be 'svn propset svn:eol-style native'. Sorry, I'll try again, but I'll try by asking a couple of questions rather than stating what I think the problem might be. I am finally beginning to understand what your issues are. I thought you just had a problem with mixed line-endings, but it sounds a bigger problem and perhaps separate issues. Has anyone built a site using Forrest on Windows and then been the first to commit it to SVN? Do we know for sure that the Ant SVN tasks pick up the SVN config info? I just reviewed our SVN forrest/site/0.7/docs/plugins/ and found that there are files with *.rss and *.pod which are missing the 'svn:eol-style native'. So perhaps your ~/.subversion/config is out-of-date. http://www.apache.org/dev/version-control.html http://www.apache.org/dev/svn-eol-style.txt To test if the Ant task gets the new config, try 'svn rm' one of the plugins and re-add it. Those *.rss and *.pod are also not handled by the workaround below. However, they don't need to be, because there are no mixed line-endings in those (no xml comments either). Given the above observation that the XSL generated comments ahve different line endings to other XSL generated files I can only assume it is something to do with the XSLT parser. What happens when you do a simple test with Xalan on the commandline. Not sure, I'll do that soon. For now I have put a workaround in place in the buildfile (uses an ant task to fix the line endings). I'll also place an issue on the issue tracker to remind us of this. I saw that. However i couldn't understand why it was converting them to UNIX line-endings regardless of which OS the user is on. Do we need to detect the OS? I converted to UNIX more out of habit than design. But it works for me and I'm on Windows so I'm happy. My comment was more an SVN-based one: eol-style native means native to the user's OS. I have not heard of this problem before. At Cocoon and Incubator, people on various operating systems generate the website and commit the result to SVN, with no problems. Yes, but they don't do what we are doing with docs generated by Forrest and then imported into SVN by ant tasks. Now i understand the issue a bit more. Sorry, i must have missed something earlier in the thread. I don't know if this is related, but thanks Google and mail-archive.com: line endings xsl:comment ... http://issues.apache.org/jira/browse/XALANJ-656 xsl:copy introduces inappropriate line-end characters processing comments. --David
