As a newbie with phpBB forum (3.1), I understand that modes may change data in forum database and files.
Therefore, I would like to backup the site before mode installation, so that the previous state could be easily restores in case it is necessary.
What are the exact instructions to install and de-install modes safely?
I'm guessing you mean 'Mods' instead of 'modes'?
phpBB v3.1.x does not use Mods like the old 3.0.x branch where core code needed to be changed. Instead it uses extensions which are uploaded to your server and simply activated in your ACP.
As a precaution it is always advised to back up your database before making any changes to your site.
Full instructions are on the phpBB sie here - https://www.phpbb.com/extensions/installing/
Related
I had downloaded cygwin from one mirror site, and after a few months when I try to update now I get the message that the "current ini file is from a newer version of setup-x86_64.exe"
If I download a new ini file, does it also mean that the entire cygwin installation will have to be downloaded again? That will take a huge time and I would like to avoid it.
Also, what is a stable mirror site for cygwin? On some update occassions, I have got the message that the site is no more a "recommended" site, and I should select another mirror site.
The answer to your main question is NO. That message appears because the setup-x86_64.exe file has been updated. You need to download a recent version at http://www.cygwin.com/setup-x86_64.exe.
Mirror sites are updated on a schedule, so the updates at mirrors are always behind the main Cygwin site by a certain amount. Some sites update more frequently than others. From the Cygwin mirror admin site:
Given the granularity of checking, it is possible that your site will
be polled after a package update on cygwin.com but before your site
has pulled the update. So, it is expected that from, time-to-time,
your site may fall off the mirror list temporarily. If your mirror
site has not been listed for a day or so that means that some cygwin
packages on your site are not current. Check the cygwin-announce
archives for announcements about recent package updates and ensure
that your site has those packages. Once your site has the recent
packages it will be re-added automatically.
and
So, if your site was dropped from the list it means that a program has
determined that the files on your site are not up-to-date. Unless your
site has been out of date for (currently) 100 runs of the program, it
will be re-added automatically when it becomes current. So, if you see
that your site has been dropped from the mirrors list do not panic.
I’ve generally found that unless you repeatedly get the message about it not being a recommended site, there's nothing to worry about, just try again in a few hours or the next day. Picking the site closest to you is generally a good bet.
You just need to download a newer version of the setup.exe file and perform the update with that.
During the setup you'll be presented with a list of recommended mirror sites, choose one near to you and you're good to go.
No worries. :-)
What are the best steps to take to prevent bugs and/or data loss in moving servers?
EDIT: Solved, but I should specify I mean in the typical shared hosting environment e.g. DreamHost or GoDaddy.
Bootstrap config is the smartest method (Newism has a free bootstrap config module). I think it works best on fresh installs myself, but ymmv.
If you've been given an existing EE system and need to move it, there are a few simple tools that can help:
REElocate: all the EE 2.x path and config options, in one place. Swap one URL for another in setup, check what's being set and push the button.
Greenery: Again, one module to rule them all. I've not used this but it's got a good rating.
So install, set permissions, move files and and DB, and then use either free module. If you find that not all the images or CSS instantly comes back online, check your template base paths (in template prefs) and permissions.
I'm also presuming you have access to the old DB. If not, and you can't add something simple like PHPMyAdmin to back it up, try:
Backup Pro(ish): A free backup module for files and db. Easy enough that you should introduce it to the site users (most never consider backups). All done through the EE CP. The zipped output can easily be moved to the new server.
The EE User Guide offers a reasonably extensive guide to Moving ExpressionEngine to Another Server and if you follow all of these steps then you will have everything you need to try again if any bugs or data loss occur.
Verify Server Compatibility
Synchronize Templates
Back-up Database and Files
Prepare the New Database
Copy Files and Folders
Verify File Permissions
Update database.php
Verify index.php and admin.php
Log In and Update Paths
Clear Caches
As suggested by Bitmanic, a dynamic config.php file helps with moving environments tremendously. Check out Leevi Graham's Config Bootstrap for a quick and simple solution. This is helpful for dev/staging/prod environments too!
I'd say the answer is the same as any other system -- export your entire database, and download all of your files (both system and anything uploaded by users - images, etc). Then, mirror this process by importing/uploading to the new server.
Before I run my export, I like to use the Deeploy Helper module to change all of my file paths in EE to the new server's settings.
Preventing data loss primarily revolves around the database and upload directories.
Does your website allow users to interact with the database? If so at some point you'll need to turn off EE to prevent DB changes. If not that you don't have too much to worry about as you can track and changes on the database end between the old and new servers.
Both Philip and Derek offer good advice for migrating EE. I've also found that having a bootstrap config file helps tremendously - especially since you can configure your file upload directories directly via config values now (as of EE2.4, I think).
For related information, please check out the answers to this similar Stack Overflow question.
During Minor Upgrade in InstallShield 2011, how to delete/remove some files which was installed from base installer and for next upgrade if we want to retrieve back the removed files how can we get back?
Overall Suggestion: Use one file per component. This avoids all kinds of component referencing problems and you can resurrect
files on major upgrades if you need to bring them back after removing them.
Note that you generally cannot switch directly to using major upgrades if you have prior releases without wiping the slate clean and installing to a different location overall. Changing the installation directory and using new component GUIDs for all files wipes the slate clean and you are decoupled from old component referencing sins.
Minor Upgrade Limitations: Minor upgrades are very restrictive with regards to what they allow you to do in an upgrade scenario. I have written a summary of this before, and I will send you there for a quick read on the topic.
Quick Tips: I almost never use minor upgrades (for reasons that are clear after you read the above linked answer), but here are some extracts from Stefan Kruger's check list (MSI and deployment expert - MVP):
You can modify the contents of a component (add, remove or modify files, registry keys and shortcuts), but only if that component is not shared across features.
If you remove a file or registry key from a component, you must populate the RemoveFile or RemoveRegistry table respectively to delete the orphaned resource.
Though aging content, I believe the above is correct.
Major Upgrade: I would strongly recommend that you go for major upgrades in the future. If you are very strict with the component rules and don't break any referencing rules, you can reliably install major upgrades with Late REP - as we call it - meaning that the new version installs as a patch on top of existing files and then only removes obsolete files (as opposed to Early REP which fully uninstalls the old version and then installs the new version). A little bit more on Early / Late REP here.
Links:
Configuring Minor Upgrades to Remove Installed Data
http://www.installsite.org/pages/en/msi/updates.htm
Identifying When to Use Major and Minor Upgrades
Is there any possible way to perform upgrade when Product codes for old and new versions are same? (same as above, but original title)
Easily adding/removing files within a Minor update
Restarting windows service during WIX upgrade
I'm putting a Drupal project on an open source hosting site. What files do I have to not put up there so I don't compromise my site's security?
Various settings.php comes to mind. And obviously the database itself won't be in a repository. Anything else dangerous?
I'm running Drupal 6.
Also, it'd be nice to get the database itself under version control in some way. Any idea how to do that?
UPDATE: What if I were to dump the db data, encrypt it, and version that?
Make sure not to submit User Uploaded Files. I wouldn't upload your db dump, even if it is encrypted. I would also be careful of .htaccess files.
Committing settings.php would be the worst thing you could do, you could try doing a find in files for your mysql user/password to make sure it isn't duplicated.
If Drupal is under version control you could Diff it with Drupal's repo to see what files have changed. Something like TortiseSVN makes that process pretty easy.
I'd also be careful of Cache files, but as far as I know Drupal only has a sql based cache.
For SQL Version control it is most common to use a mysqldump. Another approch is using an scripted versioning strategy, with a PHP Implementation. It is unsafe to dump any of the cache_* tables, the Variable table and of course the user table.
Plugins would be the only thing I would hide. The reason is that plugins have their own security holes, and announcing to the world what version you are using could get you hacked. Drupal itself is pretty secure though
I'd like to download the Trac database so I can view its tickets offline. Is there anyway to achieve this? I.e. if I need to leave the office and bring my laptop with me, how can I bring the tickets with me without having to connect to the company network?
I know that Mylyn can download and sync tickets via it's trac connector but I'd like some stand-alone viewer.
See Simple Defects (SD).
I particularly like the "One-tweet install" idea.
I’m installing #SD (http://syncwith.us)
after reading about it on #StackOverflow
curl fsck.com/sd|perl;
export $PATH=~/sd/bin:$PATH; sd
Note that you can clone Trac (and other bugtrackers) in SD:
sd clone --from trac:https://trac.parrot.org/parrot
Seeing as you don't want to install a server, how about using RSS? IIRC, Trac let lets you get RSS feeds for each person, so you can have a feed of things assigned to you.
All you need do then is get a nice client that will download these tickets. You should be able to access a plaintext version without internet connection.
If that's not flexible enough, you could write a script on the server to publish a feed using the database directly.
And if RSS isn't for you (and your email is available offline), you could mail reports home. Trac also has this built in.
The default Trac installation uses a combination of SQLite to matintain all of the data. Attachements are stored on the file system.
In the folder containing the trac site, find \db\trac.db
This file can be viewed using the SQLite manager Firefox Addon
Happy hunting.
And if RSS or email isn't your notification of choice, there's a trac plugin that will let you receive task notifications on your Remember The Milk todo list.
See: http://1.www.rememberthemilk.com/forums/ideas/3580/?forum=ideas&hl=bs&topic=3580
If your objective is simply to view the tickets offline, how about
Run a report with all the tickets (or all those you're interested in).
Select either the comma-delimited or tab-delimited download link at the bottom of the page.
Import the downloaded file into Excel.
you could install it on a local machine
You can host the trac locally and set up the connectionstring point to your dowloaded database.
Sure. Install a web server locally, install trac, get it set up the same (or similar) way to the way it is on the live version and then script the server to publish db backups and write a local script to download those and restore them over your database.
It's not simple (installing Trac is a battle on its own from my experience of it) but every element is highly googleable =)
The trac client FatBug (http://fat-bug.com/) listed in
https://trac.edgewall.org/wiki/Clients
seems to do the exact what was described by the OP. I bumped into it after I just checked SD. SD seems trival on Linux, but heavy on Windows, it depends on Perl & CPAN.