I am having only the sites folder(except Default Directory) and DB of a website with that how can i find my version.
ACtually in my DB they had fixed the prefix 'd6_' with that i can find it as Drupal6. But i can't find the correct Version of Drupal6.
In the info column of your system table in drupal database you can find the serialize text something like ""package";s:4:"Core";s:7:"version";s:4:"7.43";s:4:"core";s:3:"7.x";" of any core modules like aggrigator or block.
when you un-serialize the string you can find the version of drupal
e.g
[version] => 7.43
[core] => 7.x
This is the drupal version 7.43
Thanks
I don't think that version is stored somewhere in database, but in files you obviously don't have.
My suggestion is to check versions of all your modules (dir /sites/modules). Every module have version and possible date stored in it's info file. So make a list of release dates of all modules and then find out what was the drupal 6 version at the time your latest module was released and use that version of drupal.
Related
I just started to use OpenRefine and I wonder if there is any SQLite addon I could use.
I found a bunch of addons on main download site but SQLite is not between them.
On the other hand there is a pull on github, that claims OpenRefine to support also SQLite. I tried to load data both from "This Computer" and "Database" option and I was not able to load SQLite in neither way.
And finally I found that there is a SQLite directory with JAVA files in the github extensions folder, that might be that above mentioned support. Is this meant to be installed the easy way (just create sqlite directory inside extensions and put all the *.java files there) or do I need some other trick to achieve support on SQLite within OpenRefine?
For future reference: The SQLite importer has been added to OpenRefine in version 3.4 (https://github.com/OpenRefine/OpenRefine/wiki/Changes-for-3.4) (as Ettore Rizza already mentioned)
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
I accidentally installed a drupal update (6.26) into sites/all/modules (yes, I put there the whole drupal root directory, so I have sites/all/modules/modules, sites/all/modules/sites/all/modules, etc).
Then, unknowingly ran update.php, and everything went ok as Drupal intelligently registered the new core modules in sites/all/modules/modules/* as core modules.
This worked fine until the next update. I placed the core drupal files into the root dir, and the core was correctly replaced with 6.27. But in sites/all/modules were the 6.26 files from the last update and drupal accepts OLDER files in sites/all/modules that override the core /modules files.
So drupal now complained that it was still at 6.26, even when the real core was at 6.27 - those files were never actually called, because overridden by /sites/all/modules/modules/*.
So:
I managed to remove all the unneeded modules from there and with a few errors, I got it working again. the best method was:
changing the sites/all/modules/modules/<module>/<module>.info file and tweaking the version number from 6.27 to something older, like 6.25. THEN run update.php - so Drupal recognizes that there is an OLDER version in sites/all/modules than in core. now remove the directory and run update.php again. Now everything is clean for this module.
But this does not work for the system module. Each time I try to remove the sites/all/modules/modules/system/ directory, the update.php URL is not callable any more (HTTP Error 500).
Any hints how to recover from an accidentally overridden system module?
I finally found the answer (Thanks to Max), and want to share it in case of other people suffer from the same problem.
This solution should work if you accidentally installed a drupal update into a subdirectory like /sites/all/modules.
After running update.php, the system db table gets updated to the new paths, so all modules that are not in /modules have priority over the ones in /modules. You can deinstall all optional modules, so that they get purged from the system table as well with no problem.
In case of the system module, this is not simply possible, as you cannot deinstall the system module, when a wrong one is installed.
So what you have to do is:
Open the system table with e.g. phpMyAdmin, and search for the system module: SELECT * FROM system WHERE name = "system".
change the filename field from "sites/all/modules/modules/system/system.module" (or whatever there is) into "modules/system/system.module"
Now (and this is important before you run update.php!) delete the wrong system module folder.
Run update.php
Now Drupal should find the original (built in) system module - everything should be ok.
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).
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.