I am trying to keep a couple of Drupal sites updated and I tired of the whole process. I recently find out about Drush and I was wondering if there is a module or a CRON command I can setup to keep the sites updated for me.
Thank you.
I can see why you would want to automatically update your site, but doing so with or without drush is not advisable.
Not all module updates are backwards compatible (eg. ctools) and not all combinations of modules work together - drush does not take this into account - it just updates regardless. Add to this the possibility that the developer of a module accidentally adds another error as he or she fixed an exiting one.
Therefore you really need to test your site everytime you update a module to verify that everything works as intended. The convenience of autoupdates via cron doesn't really outweigh the troubles if clients call you up because the site crashed.
Add this to your crontab to get Drush to update your Drupal copy everyday at 12:01 PM:
1 12 * * * drush -y up
Related
I have decided to update my development PC to use PhpStorm-2017.1, but before I update, I do not want to end up wasting 1-2 days re-configuring, if there are any potential issues that can hinder my work.
Will my current license work on the new version?
Will my project settings integrate with the update? (Symfony)
Will my plugins settings be kept? (Symfony)
Any other thing I need to figure out?
Answers to your questions:
1) Yes, the new installed version will automatically pick up your current license.
2) When you update, only the software is updated. The configuration files are not touched and settings are brought across as they were on the previous version.
3) Same answer as answer # 2
4) Not really. Just download the latest version from their website and install it as you would normally.
upgrading to phpstorm 2017.1 was smooth for me, (once they released some later fixes for things like the REST tool etc)
As for your plugins, it'll depend on what plugins they are, and whether there would be BC breaks. Look up the plugin documentation and check to see if there's a version for 2017.1.
For what its worth, the symfony plugin works fine.
You can try official control panel of JetBrains https://www.jetbrains.com/toolbox/app/
Manage product updates with ease
The pace of technologies and software updates is ever-accelerating. Stay up-to-date without compromising your productivity with the Toolbox App: easily maintain several versions of the same tool, install updates, and roll them back instantly if needed.
Could be useful to patch instead of complete update:
Faster updates
When updating, Toolbox App downloads and applies a patch (or even a set of patches) instead of the full package download, thus saving you time & bandwidth.
Official response form JetBrains:
It's hard to tell whether your plugins will work with 2017.1 since there are always some changes in API that may affect some of your plugins. So it's easier just to install 2017.1 and see how it goes. Installation won't broke your existing PhpStorm 2016.2 and its settings.
I believe there have been no changes in license server so if you have right on 2017.1 there shouldn't be any problems.
P.s. Thank you every one for your responses. I will be going with the official answer.
After the fall of the server with the site entrance to the admin page redirects to install the module "Magnolia Scheduler Module". When I try to install it get the error:
Error while installing or updating scheduler module. Task 'Bootstrap' failed. (ItemExistsException: a node with uuid 54b56ea3-a89c-4736-b234-b62b63b6e602 already exists!)"
Maybe someone knows how it repaired?
On top of my head right now, this may happen when one has scheduler module jar one than once? Also I assume that, you are trying to upgrade Magnolia, It is also important to know the versions of this upgrade.
One possibility to solve it to change importUUIDBehavior in SchedulerModuleVersionHandler. Therefore, one may change the conflict strategy as they wish and hence, not hit to those exceptions anymore. However, It is also important to be careful while doing these changes.
Meanwhile, you may want/need to use https://documentation.magnolia-cms.com/display/DOCS/Groovy+module#Groovymodule-RescueApp for undetstanding what actually had happened.
Hope this helps,
Cheers
I've been floating around the Google and everything's getting more confusing now. What i want to know is how to install Memcache or Memcached. Even which one to install, i'm still not sure. It is super confusing.
I'm on Redhat RHEL. Actually i have installed Memcached (with 'd`) on my Web Server. Then according to the articles, i enabled Php Extension, etc. Then what is supposed to happen? Totally no improvement in performance.
Then i feel thats not enough and i googled again. Some say to install on MySQL Server. So what about PHP Extension and Drupal Module which are supposed to be configured, if i install it on MySQL Server? I'm really not getting it.
So i have Drupal 7 and please let me know in simple way for which is the right one to follow :(
Memcache or Memcached ? (Why this two so confusing?)
Where to put at?
Does it really need Drupal Module to work?
Please simply give me a straight dummy guide :(
"Memcache vs Memcached" - first one is a module (extension), second one is the daemon. See "Memcache Vs. Memcached" for full explanation
"Where to put at?" - you said you had it already installed on your server, it should be installed easily with some package manager e.g.:
pecl install memcache
"Does it really need Drupal Module to work?" - Yes, Drupal needs to know that you want to use memcache. The Drupal module will move cache, sessions and lock tables into memory (see https://drupal.org/project/memcache).
To make memcache module work, you need to put the following into settings.php (change you module path respectively):
# Memcache
$conf['cache_backends'][] = 'sites/all/modules/contrib/memcache/memcache.inc';
$conf['cache_default_class'] = 'MemCacheDrupal';
To see whether it works, go to "admin/config/system/memcache" (this is Drupal 7 path) and turn on "Show memcache statistics at the bottom of each page" - if everything works well, you should see something similar at the bottom of the page:
OPERATION BIN KEY HIT
get cache_bootstrap cache_bootstrap-variables 1
I'm developing a custom module for Drupal on my local machine.
When I edit my code, the changes are never applied right away. So, I go to Administer Modules, and uninstall, and then reinstall my module. This is cycle of uninstall-install-develop-repeat is slow and tedious.
Is there a better way to do it?
My module makes extensive use of Drupal framework so I'm not sure developing it exclusively in PHP first is an option.
I would highly recommend installing the Devel module. It is very useful while developing for Drupal. Once installed, you can enable the Devel block which is extremely useful. It has a list of links to perform somewhat tedious tasks faster, such as emptying the cache, reinstalling modules, rebuilding the menus, etc.
Many of the changes to your module should not require visiting the modules page. You mostly see the need to do this when you are changing the menu with hook_menu() in your module, as the menus are only rebuilt when visiting that page (or using Devel block "Rebuild Menus" link ;) )
When uninstall/install, the only things that is executed is what is in .install file.
If you don't change this file, you don't have to uninstall/install the module.
Maybe your problem is just a cache issue. Drupal strongly cache a lot a things. And when you enable a module, the cache is cleared. You can clear you cache manually.
On an other hand, I recommand to look on Drush that allow you to do those things faster. (clear cache, enable/disable a module/...)
The Drupal admin menu (http://drupal.org/project/admin_menu) along with devel comes in very handy if you have to flush caches.
Just drop cache on each time when you edit your code
Administer->Site perfomance
How can re-install module using Drush commands ?
Run command
drush dre cars_api
For details visit
https://drushcommands.com/drush-9x/devel/devel:reinstall/
======================== Drush For Drupal ========================
What is Drush ?
Ans : Drush is a command line shell and scripting interface for Drupal, and it is work like
Laravel-Artisan, and Angular CLi etc.
It is very Help-full for fast development on Drupal.
Official Website -> http://www.drush.org/
Official composer repository -> https://packagist.org/packages/drush/drush#dev-master
Official Drupal Repository -> https://www.drupal.org/project/drush
What is the Installation Process ?
Ans : There is following steps.
1.Step
Install new and latest version of composer
2. Step
Run in vscode Terminal
composer global require drush/drush:9.x-dev
check the installation in terminal via following command
drush version
For more details visit
https://packagist.org/packages/drush/drush#dev-master
And also helpful
http://docs.drush.org/en/master/
3. Step
Visite following link and see Drush All conads details and documentation
https://drushcommands.com/drush-9x/
https://www.drupal.org/docs/user_guide/en/prevent-cache-clear.html
How can resolve Drush Errors ?
Run command in vscode terminal
Composer require drush/drush
How can see drush commands list in terminal ?
Just type in vscode terminal in project dir
Drush
and enter
So all commands will be listed with summary
Uninstallation process for Drush ?
Just change in command ‘require’ to ‘remove’
composer global remove drush/drush:9.x-dev
Last week I had released a version of a WordPress plugin that works if the user was doing a fresh install, however if they already had the plugin and upgraded it using the WordPress upgrade automatically feature, problems occurred and some of the database elements were erased. So I had to revert back immediately.
I was wondering if there was a way to test the plugin through the upgrade automatically functionality before hand instead of having to release it and hoping you get it right the first time.
I would set up a dev/local site running the previous version of your plugin. Then, copy over the latest changes (overwriting all of the files) and test things out.
In essence, that is the same thing that happens during an automated upgrade.