Community
Participate
Working Groups
[Request] Can you symlink Phoenix from its location on www.eclipse to a common location on build.eclipse? [Rationale] When I try to resolve $_SERVER['DOCUMENT_ROOT'], I get /opt/local/data/httpd/www.eclipse.org/html, which doesn't contain org.eclipse-common (Phoenix), and so standard Phoenix'y things all fail to load (app.class.php, nav.class.php, menu.class.php, etc.) [Hack] As a workaround, if I hack the script to force $_SERVER['DOCUMENT_ROOT'] to be equal to /opt/public/modeling, where I've checked out my own copy of Phoenix, I get this, with broken css and images (presumably due to absolute path references?): http://build.eclipse.org/modeling/mdt/?skin=Phoenix The only skin that doesn't fall apart is the PlainText one, which is functional but lacks the clean formatting of the normal skin: http://build.eclipse.org/modeling/mdt/?skin=PlainText This is workable, but it means I have to check the $_SERVER["SERVER_NAME"] to determine if I should force $_SERVER['DOCUMENT_ROOT'] = "/opt/public/modeling"; for all my scripts, in order for them to run on emft.eclipse and build.eclipse using the same code. In other words, it's a hack. ;-)
Checking over some old bugs, I realize this ties in with bug 166916, which is "sortafixed".
I'll install Phoenix on build.eclipse.org for you, as this is the right thing to do ... but I have a few global changes that need to be committed first, so can this hold off a few days? One of those changes is the relative/absolute links.
Cancel that last comment ... I'm not going to make you wait for something that can be done now. I installed Phoenix on build.eclipse.org, so everything looks fine. Of course, the links in the top and left nav are relative to www.eclipse.org, but that's fixed by bug 175875 which will be released shortly. I'll leave this bug open as a reminder to upgrade Phoenix to the latest code.
Thanks, Denis, this works great - I don't need the "only use PlainText" hack anymore. However, I do still need this hack: $_SERVER['DOCUMENT_ROOT'] = $_SERVER["SERVER_NAME"] == "build.eclipse.org" ? "/opt/public/modeling" : $_SERVER['DOCUMENT_ROOT']; Do you think this is related to bug 175875? The issue is that on build.eclipse, when $_SERVER['DOCUMENT_ROOT'] == "/opt/local/data/httpd/www.eclipse.org/html", phoenix pages won't run (and because I can't do ini_set("display_errors","1"); (presume you've locked that out in the php.ini or apache conf?) I can't actually see the error messages for debugging). If you look at the http error logs, you should see a problem recorded a little while ago for http://build.eclipse.org/modeling/mdt/eodm/build/ (I removed the hack to test if it was still required, got a blank page, and then put the hack back.)
> If you look at the http error logs, you should see a problem recorded a little > while ago for http://build.eclipse.org/modeling/mdt/eodm/build/ (I removed the > hack to test if it was still required, got a blank page, and then put the hack > back.) The problem reported is that you're trying to reference a page through a symbolic link, which is not permitted. However, unlike on www.eclipse.org where all the content resides under DOCUMENT_ROOT, you cannot do that here on build, as http://build.eclipse.org/modeling is not physically located in the same directory as DOCUMENT_ROOT. I suggest you keep your includes relative. So instead of : require_once ($_SERVER['DOCUMENT_ROOT'] . "/modeling/mdt/build/build-common.php"); I would try something like: require_once ("../mdt/build/build-common.php"); On a side note, you need to ini_set("display_errors","1"); *AND* ini_set("error_reporting", 2147483647); where 2147483647 is an integer representation of E_ALL.
The latest version of Phoenix has been installed on build.eclipse.org - this includes absolute paths for common links when the server != www.eclipse.org I don't think I have anything left to do here, but let me know if you need assistance with anything else.
(In reply to comment #6) > I don't think I have anything left to do here, but let me know if you need > assistance with anything else. I think we're good. I had a problem w/ symlink resolution inside /opt/public/modeling/public_html but I've found a workaround for that (moving files and symlinking in the reverse direction). This means that files are actually build inside public_html instead of another folder and symlinked in, as I've done w/ emf.toro and emft.eclipse.
Closing.
