If I'm deploying a site across multiple servers (to be load balanced), it seems that on one of the servers, the minified assets aren't in assets/cache. It's there in the other ones, but not this one. Is that a database thing that PyroCMS uses to check which asset file to use?
PyroCMS will not check the database for cached assets, that would be weird. It just caches them whenever they are requested. Maybe traffic isn't getting to your other machine?
Related
We currently have a site running cold fusion 11. In an effort to improve some aspects of security we would like to store all files uploaded by our users on a server separate from our codebase and DB servers.
I'm pretty much starting from scratch here as I wasn't able to find much in my searches so far. What's the best practice for doing this and what cold fusion functions would work for storing and retrieving files from an external source?
I could use some more information to be more helpful. But let's say you have a separate server that stores all your user files on a Windows network. I would use CFContent to serve those files with the file being retrieved over a UNC path.
I'd recommend reading this blog entry of mine on Securely Serving Files via CFContent. Wil, also from CF Webtools, posts one here: Serving File Downloads with ColdFusion
We had a similar issue when we migrated to a Unix platform. Our solution was to mount a file server to the webserver. It's accessed programmatically by ColdFusion as if it's on the same server, but it's inaccessible from the web root (browser). It's worked very smoothly for us.
I have an account on some VPS(friend's apache server with cPanel) and there I have one public_html directory.
We have in there about 5-6 websites:
/home/myusername/public_html/domain-1.name/index.php
/home/myusername/public_html/domain-2.name/index.php
but I don't like this way, I'd like to orginise it better and be able to separate and isolate some stuff for each website.
So what if I create like that:
/home/myusername/websites/domain-1.name/public_html/index.php
/home/myusername/websites/domain-2.name/public_html/index.php and so on
Would it be a correct way of structurising web directories?
And would apache work like that?
Perhaps there are out there some other conventions or common workarounds?
Thanks
This is perfectly fine. In fact I'd highly recommend against using the domain folder as the document root as typical web application will also contain data that is not publically accessable (e.g. configuration files, management scripts, version control files, etc.)
Personally I prefer the name htdocs and I keep my sites under /srv/http
For example:
/srv/http/user1/domain1/htdocs/
/srv/http/user1/domain2/htdocs/
/srv/http/user1/domain3/htdocs/
/srv/http/user2/domain4/htdocs/
/srv/http/user3/domain5/htdocs/
That way you can set the DocumentRoot to the htdocs directory and put other stuff that is not meant to be delivered by the web server in a different sub directory of the domain directory.
Ok, I want just to conclude and to outline the way I went with.
Thanks to #bikeshedder for ideas!
So having a single account(none-root) /home/myusername/ under linux VPS server, I didn't want to abstract completely from existent directory structure, but at the same time I wanted to create proper environment to isolate and separate clients and their spaces.
Main goals were:
* The new directory structure should help to keep all files and folders in a nice and clear order.
* Easy to navigate and browse.
* Each developer or client would have access only to their space.
The structure:
/home/myusername/http/client-1/domain-1/public_html/index.php
/home/myusername/http/client-1/domain-1/resources/
/home/myusername/http/client-1/domain-1/configuration.php
/home/myusername/http/client-1/domain-2/public_html/index.php
/home/myusername/http/client-1/client's_resource_dir/
/home/myusername/http/client-2/domain-3/public_html/index.php
/home/myusername/http/client-2/domain-3/subdomain/public_html/index.php
As result:
* We have isolated client's space and isolated domain space. That makes enough room for any type of web projects.
* Files and dirs are not mixed up with other projects, domains and clients anymore.
* For subdomain paths it can be
- as subdirectories /domain-3.name/subdomain/public_html/
- or additional subdomain directory /subdomain.domain-3.name/public_html/depending on requirements or size of subdomain website.
* Public_html is going to be a DocumentRoot for each website.
I did not go for srv/ and var/www dirs, cuz to me it sounds like server in the server and also I don't feel variable data var/ in current setup falls under web stuff.
Though it may make sense for our coming soon local web/file sharing server
But here now I have another question:
How would I specify new path to be a default one for cPanel? and only for my user?
Cuz now there is going to be multiple DocumentRoot directories in one user space.
Is that possible by Apache design?
I better create new question :) And then will edit my question with answer
Any suggestion welcome!
Normally go with this once hosting from 5-30++ sites, depending on complexity of content, traffic, perceived future migration strategies to more dedicated virtual or bare metal servers/instances.
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/index.<html|php|jsp|aspx|what-not>
/<node-serial-or-hostname-or-domain>/<#|subdomain|www|others>/assets/...
I have a wordpress mu-site. I need to set up a test-version of it so that the client can run test on the changes we make, test the plugins with new updates etc.
Anybody who has worked with wordpress know it's a bit off a hassle to move between servers and/or domain-names, due to the absolute paths used. Does anybody have a good solution how to create a stage-enviorment of wordpress?
Here's how I do it + some adjustments I want to make:
Two WP installs on identical environments - dev & production
They each have their own FQDN
Version control (SVN in this case) to handle merges from dev to production
When merging, I don't ever merge database changes. I only merge code, and modify any of the domain specific things during the merge (which really should only be in the DB.)
Recreate any DB changes needed during deployment
There are other ways to do it, but they often require changing the hosts file or access to internal systems. So if you want to be able to show an external client a site, then those methods aren't likely to work.
I also sometimes copy the DB back from production to dev, and just do a find & replace for the FQDN.
You can also dev locally and use the above listed method for staging only.
I have several custom routes in my rails 3.0 app, the simplest one of which is.
match "*user", "profile#index", :via => :get
Because of that route physical locations on the server are killed. As an example.
/images/rails.png
tries to route to the images user.
I also have to be able to setup where people access
/<username>/archive.zip
So
/buddy/archive.zip
Where the archive.zip is a physical file on the server that has been generated and put there. How can I achieve this in my routing.
For the later I have an actual folder structure in a root folder for /<username>/archive.zip so I was thinking somem sort of symlink would be easy, but without being able to hit physical locations on the server. I am kind of stuck/confused.
Any help is appreciated.
You probably want to have any static assets get handled by your web server before hitting your rails stack. This is generally done by setting the document root in your webserver to the public/ directory within your rails app to serve your static images/css/js.
This is greatly preferred over allowing Rails to serve static assets because web servers are much faster at handling these sorts of requests, and your not tying up your rails processes for these requests, which are often limited to less than a handful.
A website I work on is currently running three different instances of Wordpress blogs, all with their own set of users & permissions, plugins and themes.
Unforauntely, I don't think Wordpress Network is a viable option due to the restrictions around where sub-blogs can be in terms of urls.
Here are the url structures of each blog:
sub.domain.com/blog-1 (lives in web_root/blog)
sub.domain.com/folder/blog-2 (lives web_root/blog-2, being aliased to folder via Apache)
sub.domain.com/blog-2 (lives in web_root/blog-2)
sub.domain.com is a Zend Framework website to complicate matters where all requests for files that don't physically exists are being rewritten to sub.domain.com/index.php
Any thoughts on how I can consolidate these instances into one Wordpress install? Thanks.
I am a huge fan of wordpress MU. There is no problem having separate user stores, and using separate plugins.
It will make updating Wordpress software 3 times easier.
Export all of the blogs and then import them into one Wordpress instance. The only strange one is sub.domain.com/folder/blog-2 but you can use the same apache mod_rewrite trick to redirect it to the lower folder.