alias:
admin/a/b
source:
sites/all/modules/somemodule/somefile
I tried in menu, pathauto, they both report such source path does not exist or I don't have permission. How can this be achieved in most easy way?
Url alias doesn't work with files, only paths that are known by Drupal (defined in the code/database).
Update:
Path aliases work by rewriting the url into something that Drupal understands. So if you wanted to make an alias to a file, you would need to serve the file yourself, since Drupal doesn't serve the files.
If you really wanted to, you could make a redirect to the file from, but that's not pretty.
Try setting the Download Method to private, under admin/settings/file-system. If you do, Drupal will serve your files and the redirects might work (I didn't test it myself... :-).
Naturally, this has a price in terms of performance. Your links will look different.
If you want to keep the public download method, your need to redirect in the HTTP server level, because file requests are not going through Drupal in that case.
Related
I am looking for any reference material for me to read up on, relating to what enables the following scenario where a website has a unique identifer appended to their domain name.
When you go to Facebook and view your profile, the URL in the address bar is something lile;
https://www.facebook.com/your_user_name.number
There is no obvious file extension, nor is the 'your_user_name.number' being passed as querystring value. I do know that I could create a folder on the web directory which is this name, and then you can direct to that folder and it will autoload the default or index files based on your web server settings. But i am not sure this is happening in this case, as then Facebook would have to create 2 billion + folders?
Browsing to your Photos on Facebook, it the url then looks like;
https://www.facebook.com/your_user_name.number/photos
I am keen to understand what this type of technical configuration is called. Happy to read up on it myself and learn about it, but I don't even know what it's called to search and read up on.
Any pointers?
What you are looking for is URL rewrite.
https://learn.microsoft.com/en-us/iis/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module
You can basically do whatever you want! No need for extensions or folders at all if you don’t want them anywhere.
I have a plugin on a Wordpress site called WP Security, most of the stuff it does is easy to use and understandable, the changes it suggests like not have default 'WP_' prefix for databases etc.
One of the things it highlights is: The index.php file was not found in the uploads directory! You should create one in order to prevent directory listings.
So can anyone tell why preventing directory listings is good and do I need to put anything in the index file, and if so what code do I need to put in? Finally what is the importance of the index file in website I don't really get this part of web design? I have read it has to be there to make site visible to browsers but why is this, why can't browsers just use the URL with no index page?
Thanks for suggestions
Andrew
Yes, blocking directory index is a good idea in web apps. The index.* file is interpreted by web server instead of providing standard directory listing. Creating an empty index.* file is ony one (although the easiest and compatible with all(?) http servers) way of blocking users from viewing the contents of the directory. Another way is to configure webserver to not serve the directory index. In Apache this can be done in the .conf file with
Options -Indexes
in the <Directory> clause. Or you might tell apache to:
AllowOverride All
And create a .htaccess in the directory containing:
Options -Indexes
line.
Yes creating index.* file is really necessary to protect your asset as absence of index files shows whole directory structure and listed assets.
Easiest way to create an index.php file with simple coding.
If I'm hosting a website, say at http://www.example.com, how can I find files that are in the same folder as index.html if I DON'T know the filenames?
So for example, if there are these files in there:
http://www.example.com/test.txt
http://www.example.com/test1.txt
Can anyone see this list of files? If so, how can I hide them, but make each one accessible to someone who knows the names? I don't want to use a password system, if possible.
If you put index.html in that directory, so no files will be listed. If you allow to upload to that directory, so i can upload some php script to list all files in directory. IF you don't know file name, you can try to guess it :)
You can use bruteforce tools such as dirbuster, or you can look at the "/robots.txt" file for some clues on what's on the website.
By the way, you should keep in mind that most of web servers nowadays have rights management implemented, so even if there is such file on the server it may not allow you access to it without authentication.
Some hosting providers provide an option to specify whether directory listings are allowed. If enabled, and a client requests a URL for a folder that does not contain a default HTML file (index.html, default.html, default.aspx, etc), then the web server will serve up an HTML file containing a listing of the files in that folder. It is rare that this option is ever enabled, though.
but you should be accurate while inserting names of files in URL or else you can use pen-test tool which will list out some of the names for free.for attempts ot full listing of files you'll need to be a paid member i guess
I'm working locally on a WordPress site for a client. The client keeps their install of wordpress in the server root, but because I have more than one client, I like to install everything in a client folder, like localhost/client. Normally it's a simple matter to add a rewrite rule to .htaccess, setting the rewrite base to be /client/. But today it's not working at all. Even if I put nonsense in the rewrite rule, the site works (which it should not, if the rewrite rules are in effect). The images references are still looking for root at localhost/, instead of localhost/client/, which means they are broken.
I looked into WordPress's documentation and found it has something called WP_rewrite, and there is a place to set parameters for it in wp-includes/rewrite.php). I set the root parameter to client/ but that doesn't seem to have any effect either.
One last thing: there is an .htaccess file in localhost/client/, and another one in localhost/client/wp/. I have them both set to RewriteBase = /client/, but I've tried just about every other sensible combination--no change.
So my question is: does WordPress do something else that would make the rewrite rules I set in .htaccess not work?
I'd recommend a small change to your local environment for a more flexible solution. Use virtual hosts. If you're running WAMP/MAMP, this tool is readily available to you. It allows you run a directory within your localhost as its own site, which you can access using a local-only URL of your choosing. I have my sites set up as sitename.local, for instance, so they all live in their own happy little ecosystem. Highly recommended.
Yes it does, you have to make some steps that will change entries in db before you move it to subfolder.
Here are detailed info:
http://codex.wordpress.org/Moving_WordPress#Moving_WordPress_Within_Your_Site
What you need to do:
copy everything as it is setup on your clients server i.e. in root folder
do the steps in above url, important are 4. & 5.; step 10. actually just go to permalink settings and click on "Save" button (or "Update" I do not remember how it says)
Now you can work :)
Are you modifying only theme or what?
I'm using multisite to host my client sites.
During development stage, I use subdomain to host the staging site, e.g. client1.mydomain.com.
And here's how it look under the SITES folder:
/sites/client1.mydomain.com
When the site is completed and ready to go live, I created another folder for the actual domain, e.g. client1.com.
Hence:
/sites/client1.com
Next, I created symlinks under client1.com for FILES and SETTINGS.PHP that points to the subdomain
i.e.
/sites/client1.com/settings.php --> /sites/client1.mydomain.com/settings.php
/sites/client1.com/files --> /sites/client1.mydomain.com/files
Finally, to prevent Google from indexing both the subdomain and actual domain, I created the rule in .htaccess to rewrite client1.mydomain.com to client1.com, therefore, should anyone try to access the subdomain, he will be redirected to the actual domain.
This above arrangement works perfectly fine. But I somehow feel there is a better way to achieve the above in much simplified manner. Please feel free to share your views and all advice is much appreciated.
Since it seems you want to reuse the files/ directory and settings.php from your development domain, I'd suggest using the default/ directory + symlinks to achieve your goals.
ie, during development
sites/default/settings.php
sites/default/files/
sites/client1.domain.com -> sites/default (symbolic link)
once you're ready to switch over to their domain:
sites/client1.com -> sites/default
You can then remove client1.domain.com from your virtual host (or continue with your rewrite, etc...).
It will accomplish the same as your method, but you get the added "protection" of all requests going to default in case you add an additional domain at a later date as an alias (for example).
If you're simply sharing core and module files between the sites, you can use a different symlink layout.
In my setup I have all of the shared files in a common, non-web-accessible directory:
/var/www/drupal
/var/www/drupal/sites/all/modules
then for each deployment, common files and folders are symlinked to those files.
/var/www/client1/public_html/index.php -> /var/www/drupal/index.php
/var/www/client1/public_html/includes -> /var/www/drupal/includes
...
/var/www/client1/public_html/sites/all -> /var/www/drupal/sites/all
Then you can place the site's settings.php and any modules or themes for only that site in the default sites directory
/var/www/client1/public_html/sites/default
This layout also offers you the flexibility to override any common files as necessary, such as .htaccess.
To move from staging to production, you will just have to modify your virtual-host configuration from the staging to production domain name.
If you don't like a ton of symlinks, another option is using the Aliased Multi-Site Support patch:
http://drupal.org/node/231298#comment-1420180
This will allow you to specify in configuration that any requests for client1.domain.com should actually use /sites/client1.com/ instead of /sites/client1.domain.com/.
Then when you move to production, you can just remove the configuration setting (though it doesn't hurt anything if you don't).
This feature is part of Drupal 7, but as a new feature won't be added to Drupal 6. More good news is that you won't even need to use it in D7 just for file paths, since instead of storing the full path to files in the database, they use a schema such as public:// or private:// which Drupal then maps to the correct file system path, allowing multiple storage types/locations with much better portability.