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.
Related
After doing the first Maven install on my new Vaadin 8.1 project created from the vaadin-archetype-widget Maven archetype, and first running my app, I noticed a single new file appeared:
myproject-demo/src/main/webapp/VAADIN/themes/demo/styles.scss.cache
➠ Does it make sense to include or ignore this file from my version control?
By ignore, I mean add that filename to my list of file/folders to big ignored by my version control system. (.hgignore file)
If I intend to share this project as open-source, should I include this file to save a step during build? Or does it get rebuilt frequently, so it would be annoying with frequent changes and needlessly flag an irrelevant change, so I should ignore it?
Using Mercurial for version control.
You can ignore styles.scss.cache. It is generated by the Vaadin servlet after it compiles your style for the first time. Cache entry is controlled by VaadinServlet on row 1107 and it will be good to let the server to create and invalidate this file when necessary.
On the fly compilation of SCSS works fine but if that turns out to be "too slow" you can compile your theme to flat styles.css file with maven. For example, Vaadin is compiling Valo theme into vaadin-themes library and you could do similar artefact from your theme. See Vaadin theme documentation for more details.
Probably a silly question, but I cannot find any good advice on the internet so far, so hopefully you guys have some good advice. I would like to use GIT for version control and use it to deploy changes to my websites to the server(s). It's easy when I use NodeJS, but a bit more complicated when using a CMS system, to my opinion.
When I use NodeJS
When I use NodeJS it's quite easy to have a node_modules folder which contains all the external libraries which I will install on deployment. The rest(my own files) will be saved on Github and deployed to my server if changed. Obviously I will not store the node_modules folder on my Github account or send it to my server (node modules will be installed on the server, on deployment). So it's pretty easy to keep those two (third-party an my own files) seperated.
When I use Wordpress, Magento or something similar
Now it gets complicated. Mostly because CMS systems like Wordpress have a folder structure like wp_content/themes/theme_name/, so your own theme files are more or less entangled with the core structure, instead of separated like NodeJS. And it doesn't seem right to commit all my core files to my Github account as well or send all those core files to my server on every deploy (I would prefer to install them using composer or something, serverside), because I'll never touch the core files, obviously.
So is there any advice? Is there a better whey to handle this? Maybe change a configuration file with the path to my theme folder or something?
The best way to do this is to move your wp-content folder outside of your standard installation. I tend to have a folder called "wp" with the basic WordPress installation in it and a folder called "wp-content" at the same level for my content files. You can then tell WordPress that your content folder is elsewhere with the following:
define('WP_CONTENT_DIR', dirname(__FILE__) . '/content');
That goes into wp-content.php which you can also take out of the main WordPress install (and thus add to git) and place at the same level as your folders.
To make things even better consider looking at composer https://getcomposer.org/ and using that to bring in WordPress core and plugins https://wpackagist.org/ is your friend here. This guide got me started on using composer with WordPress and its a good start https://roots.io/using-composer-with-wordpress/ you can pull in your theme from git as well via composer which is great for when you deploy etc... Capistrano for example can run composer on a server :)
For instance, the yet-to-be-released Twenty Twelve theme is available on GitHub, but it's a Forge build.
And in order to retrieve the actual theme with the normal directory structure, I'd have to install Ruby, RubyGems, Forge and some configuration to go with it.
I am no developer and I just want to use the theme. Is there a way to manually pull out the theme files from the build?
This is what I am thinking:
All the required template, JS and CSS files are in the build directory.
Add html5.js to the javascripts directory inside build directory. Then rename javascripts directory to js (<= compared its directory structure to that on WordPress.com SVN)
Now rename build directory to twentytwelve—the theme is ready.
Is that all, or am I missing the whole point?
PS: I am sure that some of you'd suggest me to download the theme directly from the WP.com SVN repo., but the reason why I don't want to is that on GitHub I can easily track the changes to the theme.
If you really want to just get the latest, ready-to-go version of the theme, use SVN. They push updates over when it's in a stable form, so you don't need to worry so much about whether or not there's broken functions in the version you're grabbing - or any number of weird issues when using an alpha build of the theme.
While that will kind of work, you should really either:
Use the GitHub repository the way it was meant to (clone it, and use Forge to build the theme).
Wait for the theme to actually be released.
While you might be able to extract the theme as-is from the /build directory, there's no real way for you "track the changes to the theme" since the changes will be made in the /source directory. There's no guarantee the committers will build the theme before pushing (which is how the /build directory is currently kept in sync.
Update
If you've been following active development, Twenty Twelve was just rolled into WordPress trunk for the upcoming (late 2012) release of version 3.5:
Changeset 21261
Timestamp: 07/12/12 04:20:46 (14 hours ago)
Author: nacin
Message: The Twenty Twelve for WordPress.
props drewstrojny, lancewillett.
also props corvannoorloos, jeffsebring, kobenland, iandstewart, mfields,
mtdesign, op12no2, philiparthurmoore, sixhours, mamaduka.
So rather than playing around with extracting the theme via GitHub, just use Subversion to check out WordPress trunk and look at the /wp-content/themes/twentytwelve directory.
There's nothing 'easy' about the way you're suggesting going about it. Certainly not easier than installing SVN, pointing it to the repo, and tracking changes there (you know, when they're actually done). It's still version controlled, still easy to see the diff, and still the latest version. Also, note that in github, the theme files do point to /javascripts, so if you're renaming the directory you'll have to manually catch it in the files themselves as well.
If you really want to just get the latest, ready-to-go version of the theme, use SVN. They push updates over when it's in a stable form, so you don't need to worry so much about whether or not there's broken functions in the version you're grabbing - or any number of weird issues when using an alpha build of the theme.
I faced problem that I should do modules disable/uninstall, and only then go and remove modules from repo. I'm curios if that's possible to do with feature module?
I had a task to do some clean-up, remove few node types, uninstall few modules.
Let me describe: I have two environments, test and prod. they are synced by git. if I'd disable/uninstall and then delete modules on my local env, and then push it to prod env, actually I delete only modules here, but their tables, etc still in DB - since there was no uninstall action done. Is it possible to do such things with using features? let's say I uninstall modules on local, then create feature, upload it to prod,and modules will be uninstalled as well?
Regardless of using features, you cannot properly deïnstall a module if you have removed its files.
The routines and actions to take when deïnstalling, are all in the .install file. If that one is not found by Drupal, it cannot run the deïnstallation actions inside it.
Once you have placed back the files you can simply have your features migration call drupal_uninstall_module(). That will uninstall the modules you pass along to it.
I'm trying to access a MySql database from a Qt application but I get the following error:
QSqlDatabase: QMYSQL driver not loaded
QSqlDatabase: available drivers: QSQLITE QSQLITE2
I find this very strange cause I have libqsqlmysql.so on my Qt folder. I have even tried to compile the MySql driver as a static plugin and add it to my .pro file as:
QTPLUGIN += qsqlmysql
But this also generates the same runtime error (it must've found the plugin cause there's no error compiling the application)
What am I missing? I would like to avoid having to compile Qt from source cause this will have to work seamlessly on the deploy machines as well.
BTW: Even though I'm developing and testing on Linux I will need to support Windows. Will I experience this same issue on Windows? How can I compile and link the MySql driver in both Linux and Windows?
The solution:
After following #Sergey's recommendations I did an strace of the application redirecting the output to grep so I could search for 'mysql' and for my surprise the application wasn't looking for the plugin at QTDIR/plugins/sqldrivers where I had libqsqlmysql.so, it was looking at QTDIR/lib. After copying the plugin to the lib folder the MySql connection worked.
Try opening the shared library with dlopen() and see if it loads and if not, what dlerror() tells you. I always run into similar problems on Windows. LoadLibrary()/GetLastError() saved me numerous times (last time it was because of a wrong version of some libiconv/libintl DLL). Running ldd on the plugin may also help.
If dlopen() works fine, try to load the plugin with QPluginLoader. If it doesn't load, then check the buildkey of the plugin. I usually do it the dirty way by running strings on the plugin and then looking for strings like "buildkey" or "QT_PLUGIN_VERIFICATION_DATA". Just looking at the build key and around it may give you an idea. For example, you may realize that you have compiled your plugin in the release mode while your application is compiled in the debug mode. In such case the build key won't match and the plugin won't load. Everything in the build key must match your configuration. Note that the version and the build key are checked differently: the build key must match exactly (or match some black magic called QT_BUILD_KEY_COMPAT), but in the version only the major version must match exactly, the minor version must be the version of Qt the plugin was compiled with or later and the patch level is ignored. So if your plugin was compiled with Qt 4.x.y then it will work with Qt versions 4.z.* where z>=x. This actually makes sense.
If the build key looks okay (which is unlikely if you got to this point), you may wish to look at QLibraryPrivate::isPlugin() source code to figure out what's wrong, but that doesn't look like an easy task to me (although running this in a debugger may help).
If QPluginLoader does load the plugin, check if it is in the right directory and has correct permissions. If you still didn't solve the problem by this point, it's time to look at the SQL module source code that actually loads these plugins. But it is extremely unlikely. I ran into this problem many, many times and it was always either the library not loading or the build key not matching.
Another way to go after QPluginLoader loads the plugin successfully is to use strace to figure out whether the program at least tries to open the plugin file. Searching for something like "sqldrivers" or "plugins" in the strace output should also give away the directory where Qt is searching for its plugins and specifically SQL drivers.
Update
Is it possible to compile the driver as a static plugin and don't worry about anything? Let's try:
d:\Qt4\src\plugins\sqldrivers\psql>qmake CONFIG+=static LIBS+=-Ld:/programs/Post
greSQL/lib INCLUDEPATH+=d:/programs/PostgreSQL/include
d:\Qt4\src\plugins\sqldrivers\psql>make
It compiles fine and now I got libqsqlpsql.a (release) and libqsqlpsqld.a (debug) in QTDIR/plugins/sqldrivers (it is the right place on Windows). I am using PostgreSQL driver here, but I don't think it will be any different for MySQL which I just don't have installed. Ok, let's compile some real program with it:
d:\alqualos\pr\archserv>qmake QTPLUGIN+=qsqlpsql PREFIX=d:/alqualos LIBS+=-Ld:/g
nu/lib INCLUDEPATH+=d:/gnu/include LIBS+=-Ld:/programs/PostgreSQL/lib LIBS+=-lpq
Note that I had to manually link to libpq, otherwise the linker would complain about undefined references. The funny thing is, qmake knows that qsqlpsql is located in QTDIR/plugins/sqldrivers and sets compiler and linker options accordingly. So it still needs to be in the right place to work, only you don't have to worry about your users running into the same problem as it is only used during compilation. An alternative would be to just use LIBS+=-Lpath/to/plugin LIBS+=-lqsqlpsql instead of QTPLUGIN+=qsqlpsql, at least the docs say that it should work, but I haven't tested it.
In order for the application to actually use the plugin I had to put the following in my main unit (CPP file):
#include <QtPlugin>
Q_IMPORT_PLUGIN(qsqlpsql)
It works! Also, from what I've been able to figure out from the sources, the build key and the version are checked only when a plugin is dynamically loaded (all the relevant stuff is in the QLibrary's private class, not even QPluginLoader's). So the resulting executable may (or may not, depending on the binary compatibility) work even with different versions and builds of Qt, although using it with older versions may trigger some bugs that were fixed later.
It is also worth noting that the order for loading SQL drivers is this: use the driver statically linked into Qt if available, then look for a driver registered manually with QSqlDatabase::registerSqlDriver(), then look for a driver statically imported into the application (the way described above), and finally try to load a shared plugin. So when you link statically, your users won't be able to use dynamically linked drivers they may already have, but will be able to use drivers linked statically into Qt (like in Ubuntu).
I compiled QT first and then realised that I need mysql as well. So I compiled mysql plugin by
executing following command in QT-DIR\src\plugins\sqldrivers\mysql folder.
Mysql plugin compile command
qmake "INCLUDEPATH+=$$quote(C:\Program Files\MySQL\MySQL Server 5.5\include)" "LIBS+=$$quote(C:\Program Files\MySQL\MySQL Server 5.5\lib\libmysql.lib)" mysql.pro
Plugings are then created in created in folder QT-DIR\plugins\sqldrivers.
However, when I tried to use it in my code. It failed with following error.
Error msg
QSqlDatabase: QMYSQLDriver driver not loaded
Solution
After some googling and checking Path variable I realised that the Mysql server lib
( C:\Program Files\MySQL\MySQL Server 5.5\lib) directory was not in my Path variable. I expect that the dll in this folder are used by the plugin at runtime. After including Mysql server lib in Path variable everything worked smoothly. Hope this information saves some hair on other programmers scalp, as I uprooted quite a few. :D
Last time I looked at this you needed to rebuild Qt from source and include the appropriate MySQL source.
Building Qt from the sources is not hard, it just takes a while. You are likely to have the required tools already.
A possible workaround may be to access the back-end over ODBC instead.
In order for your app to pick up the plugin at runtime, the shared library implementing the MySQL plugin needs to be placed in the correct directory. The best way of determining that directory is to check the output of QCoreApplication::libraryPaths. You can also force specific paths by using a qt.conf file.
Please note that plugins must be placed in subdirectories within the plugin path, and the final part of the path name (i.e., the parent directory of the shared libraries) cannot be changed. SQL drivers need to go in a directory named sqldrivers, i.e. <pluginpath>/sqldrivers. For more details on plugin directories, see How to Create Qt Plugins.
I was experiencing this same issue as well. I've been installing and experimenting with a lot of different Python tools and UIs. I then uninstalled everything python related. I did a fresh install of Python 3.2, PyQT 3.2, and Eric5. No more errors with the QMySQL driver.
well i have had this issue, and after a lot of time, and different tools, i found that QT ( on windows, have not been able to test on Linux.) loads the "QSQLMYSQL.." when requested, but before runtime the lib ("QSQLMYSQL..") file must reside on one of the searched paths (QApp.libraryPaths()) inside a folder called "sqldrivers".. otherwise QT will just ignore the file, even if it is at some other point inside the searched path.
what i did was to monitor the dependency of a sample app, and when i removed the "QSQLMYSQL.." dll from "plugins\sqldrivers\" it failed, but when i maded a folder inside the app folder, called "sqldrivers" and placed the "QSQLMYSQL..." inside there, it loaded.
what i have is mysql 5.5, qt 4.7.4.
hope anyone can use this, and if anyone knows more about it, i would like to know where to find it(http://doc.qt.nokia.com/stable/sql-driver.html, is the closest you can get to the information about the folder structur). :P
This may also happen if your QMYSQL plugin is linked against the "wrong" mysql_client.a or it isn't in the LD_LIBRARY_PATH. I had this problem on OSX because mysql was installed via ports, and I fixed it with:
install_name_tool -change libmysqlclient.18.dylib /usr/local/mysql/lib/libmysqlclient_r.18.dylib libqsqlmysql.dylib