I am a student, I have a project for a client, www.wac-stl.org
they are running Drupal 6. I need to upgrade it to Drupal 7 to I can install CiviCRM.
What is the best way to do this? If you can take a look at the website, I think it is a very basic website, so do you imagine I would have any trouble upgrading?
Also, I only have FTP access to the website files, I do not have database access. Will this be a problem for me?
Thank you!
Option A: Upgrade
Definition: Replace D6 code with D7 code;
run upgrade scripts on D7
database Good only for really basic sites Most like your old site
Option B: Migrate
Definition: Install new D7 site from scratch with new database;
import content,
Views, users, etc.
Clean Codebase
Old content can be left out
Retweak IA
Tweak Data Model
Con: Content Cleanup takes time
There migration tools that can be used
Features - Allows you to export content-types, users and structures
(e.g. Taxonomy, Image-styles, etc.) into a module-like package An
excellent guide is available here:http://drupal.org/node/580026
Feeds - Feeds is a contributed module that allows one to import and
export content from a csv, xml, or rss format. Visit the feeds
project page for more information.
For "node-content" export/import use the "Node Export" module.
Useful links :
Upgrade process
Migrating D6 Content Construction Kit (CCK) to D7 Fields
Upgrading a drupal site from a major version to the next one is a challenging task, no matter how "basic" is the site involved. You should definitely do that on a copy of your website in a development environment and deploy the upgraded version only after you have it fully tested.
To do that you most certainly need to have a copy of the site's database: if you can't access the db server directly you can try one of a number of modules that can help you to do that (e.g. http://drupal.org/project/dumper).
You need to read the upgrade guide thoroughly (http://drupal.org/documentation/upgrade/6/7 and follow all the links).
And, as CivicCRM actually has a Drupal 6 version, you might want to consider to stick with D6...
Related
I am looking to integrate version control into my Wordpress development workflow. I have experience with Git in rails application development, so that seemed like a good option. However, I haven't found any holistic information that pertains to my needs and is in my knowledge level.
I would like to be able to accomplish the following:
develop site locally(I would only be touching the theme files for the most part, so I would want to look to the production environment for the rest of the files to avoid redundancy)
have Wordpress look for theme information in my repository (most likely will be on Bitbucket, but am open to server hosting solutions)
I hope that I am describing this clear enough for someone to have insight. If not I am glad to go into more depth of my goals.
You can refer to "WordPress + Composer + GIT"
It uses (in addition of Git) Composer (a dependencies managing tool for PHP), and WordPress Packagist (a repositories site that automatically packages the plugins and themes available in WordPress site in the format required for working with composer)
That way, you keep a declarative approach where you declare ion a composer.json what you need: this is easier to version in a Git repo.
I want create once module multi languages in drupal 7.x with i18n installed already.
Please help me step by step create that,
Thanks advance,
The home for all Drupal localization is now http://localize.drupal.org/. This is a good place to start reading about internationalization and translation.
As a developer, you should also look at the Drupal 7 i18n articles by kristen: http://www.kristen.org/drupal7-i18n-articles,
Also read this about .po files: http://drupal.org/node/1814954
The very short version of what you need to know as a developer :-) is that you should wrap the strings you want to translatable in the translate (t()) function, as shown here: http://hojtsy.hu/blog/2011-jan-25/drupal-7039s-new-multilingual-systems-part-3-localization-and-language-apis, and then translate the strings into the languages you're interested in by one of the means described below:
If you're translatable strings are part of an official Drupal project, translations contributed to http://localize.drupal.org/ will show up on your site next time translations are updated (there seems to be some delay of max 24 hours from a translation is accepted at http://localize.drupal.org/ to when updating has an effect). Updating can be configured to happen automatically with localization update: http://drupal.org/project/l10n_update
For custom modules, you can upload your own translations through the administrative interface of the same module (localization update).
I developed a website in wordpress and used several plugins. One of the plugin was http://wordpress.org/extend/plugins/background-manager/
Every thing was working fine on my machine. But as i get uploaded it to client server. the whole site stuck due to lower version of PHP. This plugin requires PHP 5.3 and on server we have PHP 5.2. Since its a shared server, we can't upgrade its PHP.
Then i look into the code of this plugin it was using PHP 5.3 feature namespaces. Is there any way to downgrade this plugin that it will work with PHP 5.2?
This is a really tricky problem, and of course, it's really, really bad practice to use old code for plugins as they may have fixed security vulnerabilities or other serious problems. It would be better for you to move the site to a server with more up to date PHP.
Having given that important warning, you can, however, browse to the tags directory in the plugin repository and extract the files you want for the previous version. Plugin history is public and always maintained.
For instance, for the plugin you mentioned, you can visit the SVN part of the plugin repository at:
http://plugins.svn.wordpress.org/background-manager/
You'll find the previous versions there under the "tags" folder, named after their versions.
When I was upgrding my webite from drupal 4.7 to 5.2, I am facing an issue -
Fatal error: Call to undefined function node_get_base() in ../question.module.
Can any one help me to solve it...
Thanks in advance
The root of your problem is that you have some code in the file question.module calling a deprecated function (node_get_base()). Drupal 5.2 does not implement anymore that function so you get the error...
I assume that the question.module you are using is this one, which does exist for Drupal 5 series. If I am right, then I suspect you have missed to follow the upgrade instructions for updating your site which state:
5) Disable all custom and contributed modules.
[..]
11) Ensure that the versions of all custom and contributed modules match the new Drupal version to which you have updated. For a major update, such as from 5.x to 6.x, modules from previous versions will not be compatible and updated versions will be required.
12) Re-enable custom and contributed modules and re-run update.php to update custom and contributed database tables.
These instructions are in the UPGRADE.txt file in the Drupal root folder.
Hope this helps!
When upgrading Drupal to a new release, you more or less in some respects have to build the site over again. The thing is, that because the Drupal API changes to much in the new releases, each module will need to be replaced with a new one. In most cases this is just a matter of downloading a new version of the module and running update.php.
You should, however, go through each of your modules and find out what's needed to make the upgrade. Sometimes the upgrade path can be a bit tricky and you need a few attempts to get it right without corrupting any data in the process.
Another thing is, that when upgrading, going for the drupal 5 version of the same module might not always be the best choice. Especially when talking about Drupal 5, there are a lot of more or less unmaintained modules. So the best choice might be to find a different module that can do what you want, or even fulfill more of your needs.
It's always a hard decision and your theme will also need to be upgraded to Drupal 5. In short there is a lot of work evolved when doing a major upgrade. Most of it, is making some good choices about, which modules to use and how to migrate your data.
All that aside, following the upgrade guide in UPGRADE.txt like mac suggests is a very good place to start, and doing all of this leg work, would probably have avoided all this.
When I create a new Drupal site I usually end up with at least one custom module and several community contributed modules. To get the site working as it should, many configuration values need to be set on the various modules. This makes deployment onto a fresh Drupal instance painstaking and error-prone.
I would like to give my custom module the ability to configure all the other modules. Either on install or on the click of a button on my custom module's administration page, all the necessary configuration values on the other modules would be programmatically set.
How would I best go about doing this?
AFAIK, there's no way to achieve what you mean easily. I tend to put as much as I can in hook_update_N() implementations and do frequent DB synchronisations as described in my answer to this question. However that does not work when you already have a live server with which you will have to merge data.
To that purpose, I use various tools according to the need. No one is perfect, but here's however a small collection of my favorite ones:
Features. This is a new concept and a new module. The idea is pretty awesome: it allows you to define a set of configuration/modules/settings and to export them as a feature. This feature will then be installed as if it were a module on the target site. This module does not export every possible setting, but it does however do a good job with the modules that need the hardest configuration, as CCK, Views, ImageCache and others... You can see a screencast demo (~10 mins) here.
Backup and migrate. This is a more radical approach: it simply dump and rebuild the entire database on a target system. It is good only if you need to overwrite the target system completely.
Node export. This allows to export (and import) nodes from a drupal installation to another one. It supports bulk operations but - unluckily - it does not support the migration of attached files and images.
Deploy. Because of the limitations of node export I once looked into using this module (still in development). I finally did not, and preferred to do a merge of the production and staging databases, but the concept seems very valid, as it allows to import/export complex data type via SOAP.
Taxonomy import/export. I suppose the name is self-explanatory. It uses files to achieve the tasks (XML or CSV).
Installation profiles (suggested by ctford) are useful when configuring new sites. They allow you to specify modules to enable, theme to default to etc on installation. They can be quite convenient because there is a command-line tool called Drush that automates the building of installation profiles. The downside is that the profiles are designed to be used on installation - not deployment of an individual module. It might be possible however to take the configuration code generated by Drush and call it when your module is enabled.
Finally, you can find a collection of tools for importing/exporting data here.
HTH!
have you looked at the "features" module? it is a new paradigm introduced as part of the open atrium distribution but also available as a stand-alone module. from their description:
"The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.
Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK fields, etc.) in its .info file so that it can be checked, updated, or reverted programmatically."
http://drupal.org/project/features
Installation profiles are useful when configuring new sites. They allow you to specify modules to enable, theme to default to etc on installation. They can be quite convenient because there is a command-line tool called Drush that automates the building of installation profiles.
The downside is that the profiles are designed to be used on installation - not deployment of an individual module. It might be possible however to take the configuration code generated by Drush and call it when your module is enabled.
I know what you mean, it's a pain to set all modules up.
I'm sure you can investigate all 3rd party modules to see how configuration takes place and mimic that in your custom module, but I'd advise you against that...
The problem is that modules may change the way they store their settings from one revision to another, so whenever you update to a new version of any module you should do some reverse-engineering to see if your 'ultimate-one-click-configuration module' still works ok - which, if you ask me, is even more painful than manually configuring all modules for each project.
Just relax, take it easy, and enjoy Drupal :)
As the initialization is only required when Drupal is installed, I would think that a installation profile is the better solution; to keep a module that is not anymore used once that the installation is configured seems a little excessive, IMO.
Changing the installation profile used from a site, and make the new installation profile run its installation code isn't something that Drupal allows out-of-the-box. I would create a custom installation profile before creating the sites I need, and only for the features I know all the sites will share. For the other features, I would create separate custom modules I can later install, and eventually uninstall when the features they implement aren't anymore necessary.