I would like to know where can i find or whats the official process to consider when you have to update both the modules and the core in a Drupal 7 site at same time.
I mean, what do i have to update first?
Modules then Core, Core then modules or it doesn't matter at all or it depends of each module documentation?
Also i would like to know if this process changed in Drupal 8.
I have found the process to update each one but not together.
I always do modules then core, but if you have a good reference or any article with a justification for this will be better to understand why.
Thanks in advance
Firstly I would suggest you to use drush commands to upgrade core version. It will take care of the rest. But if you want to do manually then you can continue reading below answer.
In my opinion you have to update the core first ( if there is latest core and the core required modules available ) and then you can update other modules i.e contrib modules. At the end custom modules based on compatibility.
After placing the latest code you can use drush updb or {your domain}/update.php to update your database.
Or else you can do it in the following way:
Download latest drupal code, place your custom code inside it and use the old database and then run update. This is not the correct way but sometimes it works.
Note: Before doing any of the steps above always work in local environment and keep a backup. Never try it on production.
Thanks
Related
Can I just replace the two old version realm frameworks to the new version ones? Or what should I do?
Yep! If you're not using a dependency manager like CocoaPods or Carthage, you just need to delete the old framework folders and copy the new ones into the same place. Xcode should be fine handling that the next time you attempt to build your project.
If you are using a dependency manager, then you just need to hit the update command in their command line tools, and it'll be taken care of automatically.
Please keep in mind that Realm 0.97 has completely removed all of its previously deprecated APIs, so if you were using any of those, you will get build errors, but they'll be very easy to fix.
I cam up with the same question and while looking around came up with a good solution. This is in addition to what TiM has pointed out. Also, a few things to keep in mind:
I upgraded from version 1.0 to 1.0.1: so there weren't many changes to the framework and commands I used in my app.
I didn't use any special or very specific commands. Mainly the queries and writes/updates of objects. Nothing very fancy. If you have very specific requirements of Realm than I suggest look into those and see if there are any special changes to how they are managed.
Now to the steps:
Remove the frameworks from the "Embedded Binaries" section by clicking the "-":
General Tab - Embedded Binaries
Remove the frameworks from the project itself by right-clicking on them and select "Delete"
Navigator - Framework Files
Now just go and do the steps for installing the frameworks as found in the documentation "realm.io/docs/swift/latest/#installation-swift-22".
I understand this question is rather old, but looking through the SO I dint find a definite answer to this.
Hope this helped!
Since this is a beta-1 release, Is there anything which I should especially be worried about?
I've used it for a long time and know several others that have done so without any problems. So I wouldn't be worried if I were you. But I haven't tested all the stuff like SQL queries and other db stuff you can do with drush. But it's really good for downloading modules, disabling/enabling modules, clearing cache and other stuff like that, that you tend to do a lot when developing.
Drush is awesome. It does it's job well. The only thing to be wary of are things like:
Have you modified any contrib modules
yourself?
"Stable" new releases may contain
bug(s) the maintainer did not
catch.
But Drush does provide a backup of contrib modules to /backups.
Drush is pretty safe when it comes to install/uninstall modules or themes (usually it also makes back-ups) but KEEP in mind when you update the core to back-up your entire web site. I have some web sites that I do maintenance and are not build by me that if I run:
drush up
I get weird behavior like: a theme gets deleted (that was the way it was built, I found out that moving the theme from root/themes/themename to root/sites/all/themes/custom/themename fix the problem), or the whole website just stops working (the build contains double code modules folder like: root/modules and root/modules/modules). So in general if your web site is build with best practices, drush is awesome, if not you might run into trouble.
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.
I need to define a model for newly created projects in Aptana.
Basically, I want, anytime, when I create a new project, it adds some defined directories/files (not existing files, but new ones) to this project.
I'm not even sure it's possible.
Aptana doesn't appear to support that.
Maybe you can just create a small external sript to do it for you? Not the ideal solution, but better then none.
This might be a longshot, but it is worth mentioning. Since Aptana is based on Eclipse, you might be able to see how Eclipse would handle custom project templates. It appears that the easiest way to go about this is to actually create an Eclipse plugin that has a Template Wizard. IBM has a nice guide on how to use PDE to create a Custom Template. I am not sure if you will be able use PDE from within Aptana (you might be able to), otherwise, you might need to download a stock version of Eclipse, create the Plugin, then install it in Aptana.
Aptana is based on eclipse, so you could use a combination of Maven Archetypes and the Maven eclipse plugin to achieve this really easily.
Download and install maven
Create a basic maven project using the quickstart archetype, Archetypes are project templates used to rubber stamp new project structures. The quickstart is a very basic project template
mvn archetype:generate
generate the eclipse project files using the eclipse plugin. This will create the standard
mvn eclipse:eclipse
tweak the pom until and re-run step 3 until you're satisfied with the layout etc. You'll no doubt have to add configuration the eclipse plugin to add the correct build spec and project nature. If you open an existing .project file it will contain the values you need. you can see here how to add them.
once the project is set up to your liking you can create your own archetype out of it and use this to rubber stamp new projects in the future.
mvn:archetype:create-from-project
now you can run the generate again and can select your archetype from the list. If its not there, you may need to run this first to update the list of archetypes
mvn archetype:crawl
Open Source your archetype for others to use ;)
It's very simple in Studio 3. Try the following: http://wiki.appcelerator.org/display/tis/Creating+a+new+template#Creatinganewtemplate-Creatinganewprojecttemplate
Basically you create a .zip file of the project content, and then write a few lines of Ruby code to reference it.
Aptana uses (as I'm sure you know) its own 'new rails' project that gives you a variety of options.
I don't think it's beyond Will (the RadRails maintainer) to add a simple text field to that Wizard that would allow you to enter a command-line option parameter. He's always been very responsive with my previous bug and feature requests.
If you want to give that a try, and that works, then I would HIGHLY and STRONGLY recommend that you look into one of the new Rails features 'templates' in which you could make a generic template, then call it through the new input box. We use templates at my current job and they save us about 4 hours of work on each project. They are very easy to use...def...definitely.
If you can't wait for the input box, then you could always write the template then call it from within the command line (see
http://m.onkey.org/2008/12/4/rails-templates
for info about templates)
Unless RadRails three is light-years ahead of the latest release, though, you'll be missing out on a lot of very handy advantages of using a more community-supported solution such as VIM or TextMate. (I switched to VIM from RadRails about 4 months ago and have never looked back).
Eclipse has a Plugin Development Environment. If I'm not mistaken, you can also create project templates with it. Please try: http://www.ibm.com/developerworks/library/os-eclipse-pde/
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.