Bugzilla – Full Text Bug Listing
| Summary: | The Link boxes in the theme should use absolute paths | ||
|---|---|---|---|
| Product: | Community | Reporter: | Karl Matthias <karl.matthias> |
| Component: | Website | Assignee: | phoenix.ui <phoenix.ui-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | Flags: | denis.roy:
tested+
|
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 178142 | ||
| Attachments: | |||
|
Description
Karl Matthias
I assume you mean that just the code in the themes should be absolute, we use relative paths on purpose elsewhere so they can be used on test / development environments. Can you give example of where the URLs are invalid? The string http://www.eclipse.org is 22 bytes long. 18 if you use http://eclipse.org I count 11 links on a typical page, so an additional 198-242 bytes per page view. www.eclipse.org transfers about 20 million pages/month, so over 4 GB/month of throughput. I'm not opposed, but it does represent a specific cost that needs to be considered. Could the solution here be to make the PHP code smart somehow and add the extended URLS if its not running on out machine, could we just have a variable that if set to 1 then use absolute paths? We'd solve the problem / bandwidth issues all at once. (In reply to comment #3) > Could the solution here be to make the PHP code smart somehow and add the > extended URLS if its not running on out machine, could we just have a variable > that if set to 1 then use absolute paths? We'd solve the problem / bandwidth > issues all at once. > +1 Great idea Nathan. +1 (In reply to comment #2) > The string http://www.eclipse.org is 22 bytes long. 18 if you use > http://eclipse.org I already check links on the resources page to see if they're targetting eclipse.org (so that I can open a new browser for external content); I imagine that it should be pretty easy for me to trim the leading part right off. I'll look into it. Every byte counts, right? I'd suggest creating a variable in $App which contains the prefix to www.eclipse.org links (empty by default) we create a constructor for $App which initializes the prefix to the right value if the script is not running on www.eclipse.org <a href="<?= $App->getWWWPrefix() ?>/link.html"> Does this make sense? (In reply to comment #7) > I'd suggest creating a variable in $App which contains the prefix to > www.eclipse.org links (empty by default) we create a constructor for $App which > initializes the prefix to the right value if the script is not running on > www.eclipse.org > > <a href="<?= $App->getWWWPrefix() ?>/link.html"> > > Does this make sense? > +1 Makes sense to me. Created attachment 60694 [details]
patch to implement $App->getWWWPrefix()
Here's the patch for app.class.php to implement this. This patch does not include the changes that need to be done to header.php, nav.php and footer.php. if this patch is approved, I'll open a different bug for those changes.
Comment on attachment 60694 [details]
patch to implement $App->getWWWPrefix()
Change attachment type to patch
Created attachment 60699 [details]
patch to implement $App->getWWWPrefix() in the Phoenix theme
Created attachment 60700 [details]
patch to implement $App->getWWWPrefix() in the Lazarus theme
Created attachment 60701 [details]
patch to implement $App->getWWWPrefix() in the Miasma theme
+1 Comment on attachment 60694 [details] patch to implement $App->getWWWPrefix() >+ # Default constructor >+ function App() { >+ # Set value for WWW_PREFIX >+ if($_SERVER['SERVER_NAME'] != "www.eclipse.org") { >+ $this->WWW_PREFIX = "http://www.eclipse.org"; >+ } >+ } I'm wondering, what happens if this is used from a secure side (HTTPS)? Maybe the script should discover this. Otherwise the site visitors would get some warnings like "This site contains insecure content, yada yada yada". Any thoughts? (In reply to comment #16) > Any thoughts? If the www prefix is only used for rendering links (<a href...></a>) and not for including CSS or images then please ignore my early morning comment. +1 (In reply to comment #17) > If the www prefix is only used for rendering links (<a href...></a>) and not > for including CSS or images then please ignore my early morning comment. You are correct that it is only for <a href>'s for links that are always on www, as opposed to the <img> and css files which are always relative to the host for portability. You idea of https was a good catch though, and I hadn't thought of it. Voting +1 on this one, as long as the HTTPS problem is solved. (In reply to comment #19) > Voting +1 on this one, as long as the HTTPS problem is solved. > Poor wording on my part - there never was a problem, I simply meant to say that it was an interesting thought. Committed > app.class.php 1.21 This will be on phoenix.eclipse.org shortly for testing. This works as expected on phoenix.eclipse.org. All the links in the menus point to http://www.eclipse.org/whatever.php On my dev machine, the links also point to www.eclipse.org. When I set my localhost's hostname to www.eclipse.org (as it's configured on the servers), the links are relative to save bandwidth. This is ready to go live. Committed live. The live version is also identical to the version for dev.eclipse.org, so phoenix pages on dev will have correct links. Thanks, Phoenix team! Moving to Community/Website |