When you deploy a Zend Framework website to a shared host, you usually cannot change the DocumentRoot to point at the public/ folder of the website. As a result the URL to the website is now http://www.example.com/public/. This doesn't look very professional, so I'd like to remove it. Up to now I have used ZF1 and Rob Allen kindly provides a method for doing this on his blog http://akrabat.com/zend-framework/zend-framework-on-a-shared-host/ . I have tried to modify this for ZF2. He proposes placing an index.php file in the root with the line:
include 'public/index.php';
After doing this, http://www.example.com opens the index page OK but the CSS links are broken. Rob adds a controller plugin to reset the baseUrl to /public to deal with public facing CSS and image files etc. To do this in ZF2 I found an item from Matthew Weier O' Phinney http://zend-framework-community.634137.n4.nabble.com/Setting-the-base-url-in-ZF2-MVC-td3946284.html where he describes how to set the baseUrl. Based on his code I added this to modules/Application/Module.php
class Module {
public function onBootstrap(MvcEvent $e) {
$config = $e->getApplication()->getServiceManager()->get('config');
$router = $e->getApplication()->getServiceManager()->get('router');
$router->setBaseUrl($config['base_url']);
}
}
The base_url key is set in modules/Application/configs/module.config.php:
'base_url' => '/public'
I was able to dump the router object and confirm that the base_url was being set correctly at this stage. Unfortunately, now http://www.example.com no longer opens the index page and gives a 404 routing error.
Is anyone able to tell me what I am doing wrong or point me in the right direction for running a ZF2 site in a shared hosted environment?
Are you using the skeleton app?
that seems a little over the top, surely it's lot simpler than that.
move everything from public to the root
change index.php
<?php
/**
* This makes our life easier when dealing with paths. Everything is relative
* to the application root now.
*/
//chdir(dirname(__DIR__));
chdir(__DIR__);
// Setup autoloading
require 'init_autoloader.php';
// Run the application!
Zend\Mvc\Application::init(require 'config/application.config.php')->run();
Simples.
If you are running an application like this you may want to block direct access to some of the Zend Framework folders using htaccess etc
Related
I am developing a Clojure/ClojureScript SPA based on http-kit, compojure and tiny bits of hiccup on backend and mainly reagent on frontend. Project is done with leiningen, based on hand-wrecked chestnut template.
When I tried to make more complex URLs than just "/" the following setup created a mess for me:
When producing the initial hiccup to serve HTML and adding includes for CSS and JS files I followed the examples and added them as relative urls like
(include-css "css/style.css")
;and
(include-js "js/compiled/out/goog/base.js")
(include-js "js/compiled/myproject.js")
(note absence of slash in the beginning)
In the chestnut template I got default :asset-path option for cljsbuild set to "js/compiled/out"
Of course, when I tried to add a route to the same page with the http://my-domain/something URL in addition to root http://my-domain/ and load it, the thing failed to get any of my assets (trying to fetch them under e.g. /something/js/compiled/myproject.js).
I was able to fix this issue for explicitly included assets by making those urls relative to root (prepending a slash to each of them). It left me with the same problem with the script tag with src="js/compiled/out/cljs_deps.js" injected by cljsbuild, but this one I fixed by making :asset-path relative to root as well.
It all seems to work properly now, but the fact that I had to make some head-scratching and a surprisingly large amount of googling to finally resolve this makes me feel this is not the default approach. Hence the questions:
Did I do the right thing by converting all asset urls to relative-to-root ones? (Keeping in mind that I'm working on an SPA)
If yes, why isn't this a default approach and why I keep seeing relative-to-current location URLs everywhere (including all the examples on the web as well as lein templates)?
Update:
The relevant part of my app's compojure routes looks like this:
(defroutes home-routes
(resources "/")
(GET "/" _
(friend/authenticated
(html-response
(app-page))))
(GET "/something*" _
(friend/authenticated
(html-response
(app-page)))))
Recently I encountered this problem and have searched a lot but no solution by now.
Does somebody know how I can get the root directory or the page folder of FitNesse in FitSharp fixture codes?
One of the troubles is that we have a lot of existing pages arranged in different suites and I want to add some new features to all these pages requiring an absolute path of FitNesse folder. Using a fixture together with the environmental parameter in pages could require a lot of effort. I was even trying to use hard configuration in app.config for example!
Big thanks in advance! Looking forward to your kind answer.
The root path is available as a FitNesse predefined variable. Pass that into a fixture that can expose it as a property. This could go in a setup page.
|rootpath|
|load|${FITNESSE_ROOTPATH}|
public class RootPath {
public static string Path;
public void Load(string value) { Path = value;}
}
How can I rewrite my url changing my default prefix .html or .php in / ?
For example look here: http://www.anderssonwise.com/studio/vision/
I've found this tut but nothing happen:
http://www.spencerdrager.com/2010/02/07/hide-php-extension-in-url-using-htaccess/
You have to use URL Rewrites, which is why Krister asked you if you have mod_rewrite enabled. It's not the simplest thing in the world to do but here's a pretty good tutorial:
http://www.addedbytes.com/articles/for-beginners/url-rewriting-for-beginners/
You create a folder, in this example, /page/ and within that folder create index.html and then you'll be able to access the page like: http://domain.com/page/
Im trying to deploy symfony on virtual host.
mod_rewrite converts /web URLs to domain root URLs (domain.com/image.gif is turning internaly into domain.com/web/image.gif).
But thanks to web is executed internaly from /web dir, Symfony is still thinking it has document root there and prefixes any url_for() URLs with /web.
So when i have route:
show_books:
url: /books
..and iam asking for:
url_for('#route_name')
Symfony is generating:
/web/books
I cant change hosting behaviour, i need to have web request pointed into symfony root path and internaly redirected into /web dir and i want to symfony ignore the point it is executed from |hostname-document-root|/web
I found the insert of this code into top of my front controller (/web/index.php) as good solution:
$_SERVER['PHP_SELF'] = $_SERVER['SCRIPT_NAME'] = '/index.php';
I am trying to develop a grails application that has "root" content (www.mydomain.com/about for example) but will also support "projects" based upon the subdomain of the request; for example myproject.mydomain.com > www.mydomain.com/myproject. As a first pass, i have the URL configuration below:
"/$controller/$action?/$id?" {
...
}
"/$project/$controller/$action?/$id?" {
constraints {
}
}
The main drawback so far is that the $project variable must be injected manually into every link (tedious and not DRY):
<g:link controller="foo" action="bar" params="${[project: params.project]}">link</g:link>
Is there a way to automatically inject the $project parameter into all links if it is present, or is there a better way to approach this problem?
Basically you can create a grails plugin that will inject into the controller a new project param with a value based on a custom TagLib <g:project bean="myproject"/> (for instance)
It will force you to define this tagLib on each gsp page of your project but it is still DRYer than each link.
Hope it helps,
Fabien.
I can think of a couple of things.
a) You can place a proxy (Apache or something else) in front of your app-server and do some url-rewriting. Bonus: This would also allow you to do some caching of static resources.
b) This solution is a little more technically interesting. You can look up the project based on the http host header (the subdomain part). This will save you from rewriting all urls, all Grails conventions will still apply so you shouldn't run into any problems with third party plugins and so on.