I want to know how best to load my asset files with different route configuration.
Example.
With this route
$app->map(['POST', 'GET'], '/dashboard','AuthController:signIn') - my assets loads very well but on another configuration like
$app->map(['POST', 'GET'], '/editrecipe/{id}', 'AuthController:editUser'); all my css, javascript and images fail to load except if I add an extra dot.
The problem I am guessing is you need to reference your assets absolutely and not relatively.
ie all assets start with /
The following are actually very different. assets/css/app.css (Relative to your current URI) #1
and /assets/css/app.css (Absolute to your current URI) #2
With #1… if you are on page /mypage/1
The browser will attempt to load your assets at… /mypage/1/assets/css/app.css which will result in a 404.
Instead you want to prefix your assets with a / to tell the browser to look for the assets at the root of the site.
This works fine if you are running your application from your webroot. If like me, you have lots of subdirectories (one for each project) then you can use the following construct to ensure that you’re using an absolute path to reference your assets:
Thanks, I can’t still make it to work except if I am using relative path but the problem still remains when I send GET request with parameter append to url.
The I would think you’re making some soft of a trivial mistake somewhere along the line, the code I posted above has worked well for me on several projects.
To add to this. I think base_url() changes from one location to another. It’s ideal to make it this way if you are using a template layout. That way you insert it once from the main file. Otherwise, if you are inserting it on each file I am sure it will misbehave when your routes change. It may be working with /home and not with /user/{id}
But for other assets, like images. It’s ideal you go for relative path.
I have in my Slim project the directory src/images/ and I run my server at http://localhost:8080/. I’m building a React App and I’m trying display images from server in img tag <img src={ 'http://localhost/( path to image )' }. What is the relative path to my src/images/ directory of Slim project, getting through URL in browser?
(question is old but am leaving the answer for future readers )
You are asking about what’s the connecting point between the relative-path of the http-request that your fire in your browser, and the filesystem directory of your app?
Keep in mind that there’s 3 components that interpret the REQUEST_URI when you try to connect somewhere:
1st: the Web Browser
2nd: the Webserver
3nd: PHP & Slim (routing, etc.)
What is the filesystem path that your webserver uses as your www-root?
I suppose your public directory is not under src/, hence your images are not reachable publicly.
If the webserver public directory points at src/ then it’s easy: the relative path is simply images/, as your public web root corresponds to src/ on the filesystem.
You have few options to make it work:
tell your webserver about the directory src/, define a virtual-host for it, so that public HTTP requests to a REQUEST_URI /images/... can map to src/images/ (I do not recommend this; webservers should only know/access files under public/.
add a public/images/ symlink to point at src/images/, so your images are now available under public/ (at request-uri /images/)
decide whether makes sense for your app to rather keep those images and static files under the public/ (or public/static/) directory (that usually is targeted by your webserver); this might be the case if the images don’t need to be processed dynamically or if they are part of some build system (e.g. webpack or other compiles)
decide whether you prefer to handle all the routes directly via Slim, static files included. In that case you can create a middleware for handling default http requests, that didn’t match any defined Slim route; the middleware might take care of getting the request-uri (beware of XSS !) and serving the static file (by setting appropriate response headers for the filetype). This has the advantage of not requiring any change in the webserver configuration.