I downloaded someone's Drupal module (non core) I changed 1 function in there. I want my changes to not be over written by future module updates however still able to enjoy new updates.
How do you do this?
Thanks.
Generally if you have changed something, this means you are no longer having the version that can be maintained by the original developer (unless he applies the same change in his/her module).
But your options are:
making original module more flexible / expanding it: If you are familiar with the concept of Drupal's hooks, you can use them to build your own module and that way modify the way this module behaves. If it has no hooks in the feature you need, you can add them and ask author to merge the changes so when someone installs your module, it seamlessly integrates with his/her module.
using version control system: Alternatively you can check the updates in a different way, not from Drupal itself. You can use Git to download that module (drupal.org modules directory provides you with Git access), and use it to merge new versions to your code - then what you need is to be more familiar with Git versioning system.
Better to use hooks, but if there are no other solutions ...
Simplest solution : create a diff, apply a patch manually after module's automatic update.
http://jungels.net/articles/diff-patch-ten-minutes.html
Or You could edit try to edit Your module's info file, overriding the configuration of the version & the datestamp of Your module, to avoid automatic updates.
If your changed function fix a bug or something else, is better to create a path and propose your modification to the maintainer.
Otherwise, if you just modify the function to help your project, you should also create a patch and apply it after every update of your module.
Another solution, but less elegant, its to clone the module and create your own with the modified function (like this, your module can be out of updates).
Related
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
Usually I have to activate my available add-ons in order to make them working. But I find collective.geo.behaviour and my custom transmogrifier package seem working well without activating them. This make me wonder what is the trick behind the scenes. Will something go wrong if I keep using these addons without activating them?
Python packages that are installed for use in your Plone environment show up in your add-on list because they have Generic Setup profiles for addition to a Plone environment. Usually these profiles do things like set browser layers, add skin layers, add types or setup the catalog. They can also specify that the Generic Setup profile for some other add-on(s) should be run when this package is installed.
The two cases you mention here have different things going on:
crgis transmogrifier has a GS profile, but -- as far as I can tell based on examining its repository -- does not need one. It's GS profile does nothing. So, the install add-on choice will do nothing. Drop a note to the add-on author and tell them that.
Collective Geo Behavior's GS profile does nothing but specify that a couple of other add-on GS profiles be run. If you have already done the add-on installation for those, then this step does nothing. But, don't rely on that fact for future installations.
I think it's because these profiles don't do anything different than declare dependencies and the Code & ZCML are loaded at startup. So as long as you already have imported the dependencies listed in the profile you should be fine.
Also I think you could have packages without a profile, if you don't have a dependency or need to register something.
I'm trying to write a module that requires either module a or module b (not both, though having both is fine). It just dependent on a OR b. Is there a way to put this in the .info file or enforce this OR dependency programatically?
You can't natively in any current version of Drupal, there is a discussion here which talks about adding a enhances[] and enhancedby[] property for .info files (amongst a few other new properties), but it has not been put into core as far as I can tell.
If you're using Drupal 6 you might have a look at the Module Supports module which was created in response to that discussion.
If you're using Drupal 7 the discussion might get you half way there, and if not there are a few patches on that page that will at least show you roughly what you need to do to patch Drupal core yourself to do get it working.
The only way I've seen other modules implement this is by reporting problems after a module is installed and not including the modules as dependent. I would assume this would be similar to modules like ckeditor or jquery_ui which require non-drupal code to be put in place to operate properly.
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.