Serving images for a cakePHP site from a different sub-domain - image

what is the best practice for serving images from a different sub-domain(like media.host.com) in cakePHP? Should I put the images in the img folder provided by cakephp and make this folder the document root of the sub-domain, or is there a better way of doing this?
Roland.

I don't think it matters as long as the images are in the same place. In any case you can't use $html->image() as is, or you can but it's probably wiser to modify it or roll your own helper so that you don't have to always give it the full path. While you're doing that you can just make it use whatever url root you want.

all you need to do is set IMAGES_URL constant before cake does, or even overload image() in AppHelper. if you are some how using array urls for images you would also need to overload url() in AppHelper

I personally just created a separate subdomain pointing to the Cake webroot, which would only serve static files (so deny Cake's index.php, for example). A custom webroot() method in AppHelper modifies the URL for every returned webroot path (script(), image() and css() all use this) so no further code changes are needed.
I wrote a short article about it here: http://metaphoric.nl/blog/serving-static-content-from-a-separate-subdomain-in-cakephp

Related

Caching options

As I see Smarty uses caching ‘by template’.
Can I somehow provide an URL to it, so it would cache pages by the URL given?
Can I get is_cached() to work with that given URL?
And compare last_mtime of the cached file with some of my data and then say «it’s time to update the cache»?
As default Smarty uses file based caching while storing php-like files in the $cache_dir.
You can implement a custom cache function and register it, but that depends on your desire how deep you want to dive into Smarty.
A way easier approach would be to just add a bit of the urls name to the template filename, so in your template directory for example might look like.
/your/templates/url1.index.tpl
/your/templates/url2.index.tpl
...and then use Smartys caching according to your needs.

What are the benefits of using MVC HTML helpers like ActionLink, BeginForm, TextBox, etc instead of the native HTML tags?

In a SO response to a different question, a user stated that it allowed you to avoid hard-coding route values into a html link tag, but that is not really valid since you have to put in the controller, action, area, etc as strings so you are still hard-coding the route values.
How is this:
#Html.ActionLink(linkText: "MyLink", actionName: "MyAction", controllerName: "MyController", new { id = #myId }, new { area = "SomeArea"})
better than this:
<a href='/SomeArea/MyController/MyAction/myId'>MyLink</a>
Your observation is only true if (a) you're using strictly the default routing format and (b) if your application will always be installed at the root of the site. If you don't do the former (say create a short cut route /help which goes to the Home controller and Help action, and subsequently change it by introducing a Help controller with more actions, then you'll need to update all of your hard-coded anchor tags. A better alternative is using the RouteLink helper with the route name and, optionally, other parameters.
With regard to the latter, I typically use a single server for most of my staging deployments and the application does NOT sit at the site root, but rather in a subdirectory. Production deployment is mixed, but many applications get installed at the site root. Using the helpers allows me to ignore the difference during development as the helper properly constructs the url relative to the current site in all cases. This is so helpful that I even use it for scripts, css files, images, etc. via the UrlHelper to make sure that any paths specified for those do not break between staging and production.
There seems to be little to benefit in using the helper, providing you make one change - add a tilda so that the router automatically resolves the address to the correct place.
<a href='~/SomeArea/MyController/MyAction/myId'>MyLink</a>

Is There A Downside To Calling Models From Helpers In CakePHP?

A bit of context: I need to cache the homepage of my CakePHP site - apart from one small part, which displays events local to the user based on their IP address.
You can obviously use the <cake:nocache> tag to dictate a part of the page that shouldn't be cached; but you can't surround a controller-set variable with these tags to make it dynamic. Once a page is cached, that's it for the controller action, as far as I know.
What you can usefully surround with the nocache tags are elements and helpers. As such, I've created an element inside these tags, which calls a helper function to access the model and get the appropriate data. To get at the model from the helper I'm using:
$this->Modelname =& ClassRegistry::init("Modelname");
This seems to me, however, to be a kind of iffy way of doing things, both in terms of CakePHP and general MVC principles. So my question is, is this an appropriate way of getting what I want to do done, or should it ring warning bells? Is there a much better way of achieving my objectives that I'm just missing here?
Rather than using a Helper, try to put your code in an element and use requestAction inside of the element.
see this link
http://bakery.cakephp.org/articles/gwoo/2007/04/12/creating-reusable-elements-with-requestaction
This would be a much better approach than trying to use a model in your helper.
Other than breaking all the carefully-laid principles of MVC?
In addition to putting this item into an element, why not fetch it with a trivial bit of ajax?
Put the call in its own controller action, such that the destination URL -> /controller/action (quite convenient!)
Pass the IP back to that action for use in the find call
Set the ajax update callback to target within the element with the results of the call accordingly
No need to muck around calling Models directly from Views, and no need to bog things down with requestAction. :)
HTH

Do even simple pages need routes in Rails?

I wanted to make a simple page for a footer of a site discussing the team of the project. Such a page usually just has information and nothing too fancy.
I didn't make a route for it, and just basically saved it as team.html.rb in the folder: /app/views/team.html.rb
I am not sure whether that is the right place for such a file to be saved to. Where is the best place for such a one-off file?
Also, do I still need to make a route and a controller for this, or can I just skip those for such a simple page?
Thanks!!
I'm using a controller to deliver static pages.
Here's a link to a similar question:
How to do static content in Rails?
What you can do also is put a static html file into the 'public' folder and refer to it like this:
http://localhost:3000/name-of-static-file
I don't think that will work because Rails expects all requests to go through a controller. The simplest thing would be to do something like this at the end of your routes.rb:
match "/:action" => "pages"
Then in app/views/pages you can put your team.html.erb. You also will probably need at least a blank controller in app/views/pages_controller.rb:
class PagesController < ApplicationController
end
The nice thing about this is if you happen to need some dynamic content for one of the "static" pages you can just define a controller method to load it.
If this seems like overkill for your site, you might want a lighter framework like Sinatra
routes point to controller actions, not views.
a request to /team would (iirc) point to application#team. If that action doesn't exist, you will get an error. If you DO have that action defined (with a call to render, it will look in /app/views/application for a file called team.html[.erb|.json|.etc]
As the related thread points out, thoughtbot's high_voltage gem is great for a base of serving static pages.

How to differentiate from the server side, between the first request of the browser (HTML file) and the following (images, CSS, scripts...)?

I'm programming a website with SEO friendly links, ie, put the page title or other descriptive text in the link, separated by slashes. For example: h*tp://www.domain.com/section/page-title-bla-bla-bla/.
I redirect the request to the main script with mod_rewrite, but links in script, img and link tags are not resolved correctly. For example: assuming you are visiting the above link, the tag request the file at the URL h*tp://www.domain.com/section/page-title-bla-bla-bla/js/file.js, but the file is actually http://www.domain.com/js/file.js
I do not want to use a variable or constant in all HTML file URLs.
I'm trying to redirect client requests to a directory or to another of the server. It is possible to distinguish the first request for a page, which comes after? It is possible to do with mod_rewrite for Apache, or PHP?
I hope I explained well:)
Thanks in advance.
Using rewrite rules to fix the problem of relative paths is unwise and has numberous downsides.
Firstly, it makes things more difficult to maintain because there are hundreds of different links in your system.
Secondly and more seriously, you destroy cacheability. A resource requested from here:
http://www.domain.com/section/page-title-bla-bla-bla/js/file.js
will be regarded as a different resource from
http://www.domain.com/section/some-other-page-title/js/file.js
and loaded two times, causing the number of requests to grow dozenfold.
What to do?
Fix the root cause of the problem instead: Use absolute paths
<script src="/js/file.js">
or a constant, or if all else fails the <base> tag.
This is an issue of resolving relative URIs. Judging by your description, it seems that you reference the other resources using relative URI paths: In /section/page-title-bla-bla-bla a URI reference like js/file.js or ./js/file.js would be resolved to /section/page-title-bla-bla-bla/js/file.js.
To always reference /js/file.js independet from the actual base URI path, use the absolute path /js/file.js. Another solution would be to set the base URI explicitly to / using the BASE element (but note that this will affect all relative URIs).

Resources