It is possible to access a MySQL or MariaDB database in Docker Compose, even without knowing a password.
Warning! Do this only for development purposes! It is completely insecure to keep a passwordless root in a database.
In my case I needed to create a dump from the data. I only had the /var/lib/mysql folder copied from production server. The folder was mounted in the docker container.
So I’ve added the --skip-grant-tablesoption to my docker-compose.yml:
services:db:image:mariadb:10.4command:"--skip-grant-tables"# allow to connect with any credentialsrestart:alwaysports:-"3306:3306"volumes:-type:"bind"source:"./db"target:"/var/lib/mysql"
I was able to login with any (or none) credentials.
Sometimes your Magento 1 website starts slow down or even crashing for no reason if load becomes higher than average.
Once we had exactly this situation with our Magento installation. When load became higher, website started to slow down periodically, or even crash. MySQL was crashing. We also had MySQL deadlocks as a bonus.
We started to debug it. First, we had a script running by cron. Crash usually happened after this script starts. Script was using MySQL and was making select queries to many Magento tables.
At first we thought that this script was responsible for crashes. We even optimized its queries and made it run about ten times faster. But all in vain, MySQL was still crashing time to time.
We started to check all queries that were running near crash time. And then we saw strange queries:
and
So we started checking where it came from. And then things became more clear.
In Magento, product stock status is updated every every time someone makes an order. And this causing reindex of a stock statuses. And reindex in turn causes disabling indexes on tables to make index process faster. It happens in abstract indexer parent class Mage_Index_Model_Indexer_Abstract::disableKeys and Mage_Index_Model_Indexer_Abstract::enableKeys.
But! MySQL’s DISABLE KEYS and ENABLE KEYSworks only for MyISAM tables. cataloginventory_stock_status table is not one of them, it has “InnoDB” engine, like most tables in Magento. So those queries has no positive effect. Maybe they are just oblivious since time when tables were or were planned to be MyISAM.
We checked that those queries were reason of crashing by running them when our heavy cron script just started:
After running it MySQL crashed instantly.
So we commented out those queries and after that MySQL stopped crashing.
Since I am not an expert in MySQL internals, I still do not know what exactly caused this MySQL behavior. And why it happened only when load was above our usual load. Any explanations appreciated.
Magento version we were using was 1.9.1.0, but latest 1.9 version has the same code at the moment of writing.
Let’s assume we want to rewrite some core model (or resource model, or block, or helper). In order to do that we need to make changes in config.xml file of our module. In our case this is Mage_Catalog_Model_Resource_Product_Flat_Indexer:
But it could be frustrating to figure out product_flat_indexer node name.
So we’ll use PHPStorm and Magicento plugin for it (plugin is paid, but it worth it to install if you work with Magento). With both of that installed we’ll just type Mage::getResourceModel(''); and use autocomplete feature:
As you can see, the part after catalog/ is what we are looking for.
Sometimes you need to redefine Magento’s base layout entries. But since you should never edit Magento core files, there must be other way to do this.
Solution is simple: you need to create local.xml file in your theme’s layout folder (e.g. app/design/frontend/yourpackage/yourtheme/layout/local.xml) and override required entries there.
Real example: we want to override template that is defined in base layout in app/design/frontend/base/default/layout/persistent.xml:
There is an service called Bronto, a marketing platform for e-commerce websites. It has it’s own extension for Magento. This extension has an “auto login” or “silent login” feature: when user clicks on link in abandoned cart email, he gets redirected to his cart and logs in automatically.
You may wonder, where is exactly “auto login” happens. For Magento 1.9 with Bronto 2.4 it is located in Bronto_Reminder_LoadController::indexAction. Actual url where Bronto redirects looks like this: http://site.com/reminder/load/index/message_id/0baa06eb00000000000000000000001b5fa3/id/eDRedi5YZGVbUEk9/?{some_more_params}
It wasn’t obvious for me at first so I decided to share this knowledge here. Hope it helps.
When I was starting a blog, I wanted to use some free license for it’s contents. That was hard to choose a proper licence, because their texts was so hard to understand (also English is not my native language). So I didn’t spend much time on it and choosed one with a boring long name “Creative Commons Attribution 4.0 International License” and forgot about it.
Today I was browsing Ansible Galaxy to fing a role that will install pip in Vagrant box and in one of these roles I saw a license that called “WTFPL”. I went to their site and immidiately felt that this licence is totally fit my needs. It is simple and allowing to do everything with content. “WTFPL” stands for “Do What The Fuck You Want To Public License”. I even decided to switch blog to it.
This usually happens when you use models from one app in another, as ForeignKey or ManyToMany etc. Django cannot add dependencies in migrations to other apps automatically, so you should manually adjust your migration file and add a dependency to other app’s migration, as described in Django docs:
classMigration(migrations.Migration):dependencies=[('app1','0001_initial'),# added dependency to enable using models from app2 in move_m1
('app2','0004_foobar'),]operations=[migrations.RunPython(move_m1),]
I faced a problem when setting up uWSGI server. I wanted to run it in Emperor mode. I repeated steps from official docs, but vassal processes wasn’t able to start. It seemed that uWSGI Emperor didn’t see vassal config files.
Spend a whole bunch of hours, digging into that problem. Then I realized my vassal config haven’t had any extension. I added .ini extension to config file and it worked. After restarting main uWSGI proccess, vassal proccess started immidiately.
Although ini files is default choice, uWSGI also supportsjson, xml and yaml formats.