How to rename drupal's admin directory as I already have a directory named "admin"?
As Bleadedu pointed out, Drupal has no "directories" in its URL.
The urls you see are all so called "clean urls", achieved with a nifty trick in Apache (the webserver)
configuration. You could disable clean urls that will fix your problem, but may not be an option, if you rely on this feature for some reason.
Another option is to use path module to circumvent this issue. This has downsides too, most notably, the fact you need to manually change each url with admin in it.
The last option is to change the rewrite rules in Apache. This is hard to achieve and requires some knowledge of mod_rewrite.
you can't. simply because admin directory doesn't exist. it's just a url path (defined in all modules that have got a reference of it in hook_menu)
The only solution I have right now is to implements hook_menu_alter and redirect all menus that starts with admin/ somewhere else, but I can't say that it will work 100%.
Instead of changing the path of /admin, you should beef up security elsewhere.
First, finding out your site uses Drupal is a piece of cake.
Huge companies use Drupal, and don't change their /admin path.
Don't use User 1. Most of the time, there is no need for anyone to be using User 1. Even the highest of admins should be given a role, and certain permissions. User 1 should have a complicated long password, changed every (x) number of days or hours, but never actually used. I think there is also a module for this, but I can't remember off the top of my head because I just do this programmatically.
logintoboggan.module
The Login Toboggan module will display the login form for Access denied pages
login_security.module
protect_critical_users.module
userprotect.module
session_limit.module
nodeaccess.module
Don't let direct access to update.php and cron.php. Create a cronjob to run via shell.
-have them direct to forbidden/or a 404 with a search page
Use the tools in cpanel/whm or similar. Knock out bad login attempts and such.
There are a ton of other ways to beef up security in drupal.
I somehow forgot that you said "as I already have a directory named "admin". opps.
I think you would be wise to either alter that other directly instead, put it inside of another directory, or simply don't use it.
It is just going to be very messy. You would have to look into every single module to see if it needs adjusting.
Off the top of my head, the user.module will need to be altered, and also take a look at http://api.drupal.org/api/search/6/url_rewrite.
custom_url_rewrite_outbound and custom_url_rewrite_inbound will work, BUT you will still be able to access /admin by typing it in manually. You will get a forbidden if you stick a "admin" folder in your root.
All in all, I think it would be a messy venture, and you might get a lot of broken updates. Until something like this is offered in core, I wouldn't do it. Even if there was a module that could, I wouldn't use it.
*You will have to "Hack Core," and I don't think this justifies hacking the core.
Related
I'm setting up access to a Drupal 7 site. The site sits alone on a box that answers to a number of domains and that number is likely to grow. What I'd like to do is to tell Drupal to load the site regardless of which actual domain brought us to the box (the rest of the URL will always be the same, of course). Currently most of those domains send me to the install page.
The problem is the lack of a directory (symlink) in the sites/ directory.
I can probably rewrite requests coming through alternate domains in Nginx, but I'm wondering whether there's an application level answer. As it stands right now, accessing the box/site by any domain other than the canonical domain sends me to the install page.
Is there anything I can do?
It looks to me that you didn't configure your Drupal site as the "default" one.
The file "sites/default/settings.php" is loaded if no better (more specific to the current request) settings file can be found in the sites/folder... This is in fact a "wildcard" config, so the best solution would be to move the site files to the default folder. See the multi-site documentation for more details.
If you can't do that, then you can use sites.php for the rewriting, but you will need to update it to add any new URL you want to match. There's a little shortcut though: you can add a bunch of rewrites such as
$sites['com'] = 'default';
$sites['net'] = 'default';
$sites['org'] = 'default';
...
which will act as catch-all rewrites for sites ending in .com, .net, .org and so on, saving you a lot of (but not all) the manual rewrites.
Altering the conf_path() function should really be your last solution, since it will make updating Drupal a slower process (and if you forget to re-apply the changes after an update, your setup won't work any more).
I usually place an app_offline.htm in my root directory when I am releasing a website to a production environment. However sometimes if there has been a few big changes to the site, I would like to click around first to make sure it's stable without allowing access to anyone other than me.
As far as I am aware this isn't possible, but I'm hoping someone has a neat solution...
The solution has to include if someone has a deeplink into the site, so using a default.htm/asp page in the root won't do the trick unfortunately.
I agree with the staging environment answer above, but otherwise here's one possible approach: Temporarily block all IP addresses besides your own. This can be achieved through IIS Directory Security configuration, or programmatically in any number of ways
You can redirect all the non-authorized users to an Under Construction page of some sort. Meanwhile, you can happily browse the site from your IP. When the site is vetted, you remove that IP restriction and the site becomes available to the world at large.
It's a difficult thing to achieve. That's why you should have a staging environment where everything should be validated before shipping into production. Then during the deployment process (if it takes long, but it shouldn't) you could use an App_Offline file. This staging environment should be as close as possible to your production environment (in terms of software, patches and configurations installed, not in terms of hardware power of course).
Another quick suggestion that would allow you to control things from the web.config might include a custom module that redirected all requests to a static page except those defined by a filter (i.e. hostname, url sniffing) that could be configured via the web.config.
The situation is the following: I created a site with Plone, developed, used, but behind a test URL. Now it has to be published, but the test URL is not appropriate and I don't want to move the site. I think, if I use a redirect, it won't be appear in the URL-bar, only in the case of site start page. Am I wrong? (The test URL should not be used, because it will be a "semi-official" site.) What do you suggest to do?
As far as I can see Plone uses absolute URLs everywhere. I can add relative URLs, but if I create a new page, a new event, etc., then they have absolute URLs on other automatically generated inner pages. Is there any way to convert these URLs to relative paths? Is there any setting possibilty where only a checkbox changes this default setting?
Plone does not store your URLs in the database. It uses the inbound host header (and any virtual hosting configuration set up with rewrite rules in Apache or Nginx) to calculate the correct absolute URL when rendering the page.
In other words - as soon as you actually point the relevant domain name to the server with your Plone instance, it'll just work.
P.S.
You should put a bit more effort into asking your question. This is just a copy and paste of a half-finished email chain where you tried to get the answer from me in private. It's not very easy to understand what you're asking.
I think what you are looking for is url rewriting to handle virtual hosting. ie to get your site to appear as if it's the root url of a domain.
This is normally done via the webserver that normally sits in front of plone. For apache, here is a howto
http://plone.org/documentation/kb/plone-apache/virtualhost
for other servers
http://plone.org/documentation/manual/plone-community-developer-documentation/hosting
You can also achieve this directly in zope (via ZMI) using something called the Virtual Host
Monster. see http://docs.zope.org/zope2/zope2book/VirtualHosting.html
PS. I don't think your question is badly worded. Plone does serve pages with a "base" tag and what appears to be absolute urls. They aren't baked into the database but it's also not obvious that the solution to getting the url you want is the VHM url syntax and a proxying frontend webserver. There is a reason why it doesn't use relative urls... which I can't remember it was so long ago.
I have a site that will be "down" for a few hours while a third party (CC processor) performs maintenance (in other words, the machine will still be online/running). I have already created a maintenance.aspx page. At first, I was going to simply add the new page as the default document in IIS (Server 2003, IIS 6.0), but this still leaves the possibility of someone directly navigating to the real login page.
Is there someway to do a redirect of all pages in a given site to the new maintenance page. Also, the site will be down from 2am-4am, so for extra bonus points, is there a way to automatically do this using the system clock (and prevent me from having to be around for this)?
I am planning on giving an error during login to prevent any access, but I'd rather the users not even be able to make it that far.
Suggestions?
Use App_Offline.htm
Sounds like you want to use an App_Offline.htm file. Details over here:
http://weblogs.asp.net/scottgu/archive/2005/10/06/426755.aspx
To automate, you would just create a Windows Scheduled Task to move this file in and out of your application's root directory at the desired times.
Use a rewriting filter, like IIRF. Configure it to rewrite ALL pages to your maintenance page.
problem solved.
app_offline.htm is the way to go indeed. To automatically restore your site, you can simply use a scheduled task.
For some reason I can no longer post a comment as an Anonymous user in my Drupal installation. I haven't tried in a while, so I'm not quite sure when this functionality was broken.
I have Services installed, and I can post anonymous comments using comment.save. I have altered the Input Formats if that could break something.
I have enabled both post comments and access comments on the anonymous user. The comments does not show up in the database. In fact, the native Drupal function comment_save isn't called when I try to comment as Anonymous (I check this by adding print_r($edit);die(); at the top of the comment_save function in comment.module. Also I read something that not having a User with the UID 0 would break the Anonymous commenting, this user exists (obviously, since commenting through Services works)
I have tried out the AntiSpam module, and posted a comment as Anonymous that would get caught(and did) in the spamfilter, but this module is now disabled.
I'm really running out of ideas here, does anyone have any other suggestions on what to do? In the meanwhile I'm going to attempt to backtrack the code to figure out why comment_save() isn't being called.
Edit: Anonymous users also don't have to submit email and such to post, if that matters in any way.
By what you say, I suspect the problem is with some contributed code hooking on the comment form and modifying it in a way that makes it fail submission. This can be caused by a number of causes: a jQuery that adds fields to the form without regenerating the form-id on the server, an added or cusomised field that changes the callback to submit the form, etc...
I cannot know it for sure, but here's what I would do if I were you, in order to check what's up with your installation:
Make sure you disinstalled (and not only disabled) the modules you tried and don't use anymore. Modules should never touch core tables, but who knows... It does not cost anything and it actually frees some of your DB.
Try disabling all contrib modules and see if you can comment that way. If this is the case, activate the contrib modules one at a time until you find out which one is the culprit. Chances are you will already find a patch/workaround in the issue queue for that module on http://drupal.org. If you don't find a fix, I would investigate (xdebug or manual tracking) the code, and I would pay special attention to all implementations of hook_form_alter() and hook_form_FORM_ID_alter().
If even disabling all contrib modules doesn't help (which I would be very astonished of), try updating the core with a fresh installation if you consider as a possibility that your cat walked on the keyboard while you had a core file opened, or you live with Gordon Brown's family.
Failing that, the only alternatives coming to my mind are much more esoteric, such DB failure, a greasemonkey script on your browser interfering with commenting and similar unlikely possibilities.
HTH!
I solved this once by resetting the permissions table (http://drupal.org/node/64114), but I would do a proper backup and keep the permissions page open in a tab, just in case.