When a database dump is not a complete dump ...
Fri, 10 Aug 2018 18:18:01 +0200
Serious? Are you fucking kidding me? #SQLite3 #Drupal #WTF
With a bit python it was possible to transform a Druapl 8's sqlite3 dump into a sql file that I could import into MariaDB 10.3. Surprisingly the whole multi domain and multi language website seemed to work quite fine in frontend and backend on a first and second look. Just the dblog is filling with unserialize errors from the key value store.
Looks like there are entries which do not get out of sqlite3 correctly. Neither through dump, nor cli.
How to get a complete dump from the sqlite3 database?
Where has my beloved TYPO3 gone?
With a bit python it was possible to transform a Druapl 8's sqlite3 dump into a sql file that I could import into MariaDB 10.3. Surprisingly the whole multi domain and multi language website seemed to work quite fine in frontend and backend on a first and second look. Just the dblog is filling with unserialize errors from the key value store.
Looks like there are entries which do not get out of sqlite3 correctly. Neither through dump, nor cli.
A sqlite3 database dump
$ sqlite3 sites/default/files/.ht.sqlite .dump | grep user.entity_type
INSERT INTO "key_value" VALUES('entity.definitions.installed','user.entity_type','O:36:"Drupal\Core\Entity\ContentEntityType":37:{s:15:"');
Query the database directly with the sqlite3 cli
$ sqlite3 sites/default/files/.ht.sqlite "SELECT * FROM key_value WHERE name = 'user.entity_type'"
entity.definitions.installed|user.entity_type|O:36:"Drupal\Core\Entity\ContentEntityType":37:{s:15:"
Actually this is the same like the sqlite3 cli
$ ../bin/drush sql-query "SELECT * FROM key_value WHERE name = 'user.entity_type'"
entity.definitions.installed|user.entity_type|O:36:"Drupal\Core\Entity\ContentEntityType":37:{s:15:"
Is this Drupal 8 Magic? :-!
$ ../bin/drush php-eval "\$r=db_query('SELECT * FROM key_value WHERE name = \"user.entity_type\"')->fetchAll(); print_r(\$r[0]->value);"
O:36:"Drupal\Core\Entity\ContentEntityType":37:{s:15:"*static_cache";b:1;s:15:"*render_cache";b:1;s:19:"*persistent_cache";b:1;s:14:"*entity_keys";a:6:{s:2:"id";s:3:"uid";s:8:"langcode";s:8:"langcode";s:4:"uuid";s:4:"uuid";s:8:"revision";s:0:"";s:6:"bundle";s:0:"";s:16:"default_langcode";s:16:"default_langcode";}s:5:"*id";s:4:"user";s:16:"*originalClass";s:23:"Drupal\user\Entity\User";s:11:"*handlers";a:9:{s:7:"storage";s:23:"Drupal\user\UserStorage";s:14:"storage_schema";s:29:"Drupal\user\UserStorageSchema";s:6:"access";s:36:"Drupal\user\UserAccessControlHandler";s:12:"list_builder";s:27:"Drupal\user\UserListBuilder";s:10:"views_data";s:25:"Drupal\user\UserViewsData";s:14:"route_provider";a:1:{s:4:"html";s:36:"Drupal\user\Entity\UserRouteProvider";}s:4:"form";a:3:{s:7:"default";s:23:"Drupal\user\ProfileForm";s:6:"cancel";s:31:"Drupal\user\Form\UserCancelForm";s:8:"register";s:24:"Drupal\user\RegisterForm";}s:11:"translation";s:37:"Drupal\user\ProfileTranslationHandler";s:12:"view_builder";s:36:"Drupal\Core\Entity\EntityViewBuilder";}s:19:"*admin_permission";s:16:"administer users";s:25:"*permission_granularity";s:11:"entity_type";s:8:"*links";a:4:{s:9:"canonical";s:12:"/user/{user}";s:9:"edit-form";s:17:"/user/{user}/edit";s:11:"cancel-form";s:19:"/user/{user}/cancel";s:10:"collection";s:13:"/admin/people";}s:17:"*label_callback";s:16:"user_format_name";s:21:"*bundle_entity_type";N;s:12:"*bundle_of";N;s:15:"*bundle_label";N;s:13:"*base_table";s:5:"users";s:22:"*revision_data_table";N;s:17:"*revision_table";N;s:13:"*data_table";s:16:"users_field_data";s:15:"*translatable";b:1;s:19:"*show_revision_ui";b:0;s:8:"*label";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:4:"User";s:12:"*arguments";a:0:{}s:10:"*options";a:0:{}}s:19:"*label_collection";s:0:"";s:17:"*label_singular";s:0:"";s:15:"*label_plural";s:0:"";s:14:"*label_count";a:0:{}s:15:"*uri_callback";N;s:8:"*group";s:7:"content";s:14:"*group_label";O:48:"Drupal\Core\StringTranslation\TranslatableMarkup":3:{s:9:"*string";s:7:"Content";s:12:"*arguments";a:0:{}s:10:"*options";a:1:{s:7:"context";s:17:"Entity type group";}}s:22:"*field_ui_base_route";s:22:"entity.user.admin_form";s:26:"*common_reference_target";b:1;s:22:"*list_cache_contexts";a:0:{}s:18:"*list_cache_tags";a:1:{i:0;s:9:"user_list";}s:14:"*constraints";a:1:{s:13:"EntityChanged";N;}s:13:"*additional";a:0:{}s:8:"*class";s:23:"Drupal\user\Entity\User";s:11:"*provider";s:4:"user";s:20:"*stringTranslation";N;}
How to get a complete dump from the sqlite3 database?
Where has my beloved TYPO3 gone?
Drupal webform mail template override
Wed, 18 Apr 2018 13:32:49 +0200
The default #Drupal swiftmailer mail template override works something like this:
I was struggling how to configure a module which actually needed more than just module--key identifiers. For example when you have several Drupal webforms or even several handlers for one webform. It was not directly obvious how to access each handler, but actually it is quite simple:
#CMS
swiftmailer--[mymodule]--[mykey].html.twig
I was struggling how to configure a module which actually needed more than just module--key identifiers. For example when you have several Drupal webforms or even several handlers for one webform. It was not directly obvious how to access each handler, but actually it is quite simple:
swiftmailer--webform--[webform-node-id].html.twig
swiftmailer--webform--[webform-node-id]-[handler-id].html.twig
#CMS
Dockerized
Fri, 09 Dec 2016 19:02:47 +0100
Nearly all web projects are moved to #Docker containers now. The old infrastructure was mostly based on CentOS6/7 and the main reason for this step was the annoyance of legacy #PHP projects and their PHP version requirement conflicts. I don't need a cluster or swarm, so I have a single instance with #CentOS based #Project Atomic only. The dockerized projects include:
static pages with nginx
#TYPO3 7.6
#Drupal 8.2
#Piwik 2.17
#Revive Adserver 4.x
#OXID eShop 4.[9|10]
...
Here are some completely subjective "best practices":
Should also get my private projects into containers next.
static pages with nginx
#TYPO3 7.6
#Drupal 8.2
#Piwik 2.17
#Revive Adserver 4.x
#OXID eShop 4.[9|10]
...
Here are some completely subjective "best practices":
- I was a bit disappointed about most available images in Docker's Hub. But make use of the official mariadb, php, drupal, nginx images!
- Use your Dockerfile and no massive entrypoint scripts.
- Don't try to build a base images for all your projects, the projects have all too different requirements. Found it much easier to build custom images from the official PHP images directly with only what was really needed for the projects.
- Think about mail delivery requirements. Does your application requires mail(), or can you configure a SMTP server. Use sSMTP if you need a local MTA.
- Get your persistent volumes right and use the correct #SELinux labels.
- A local repository makes deployment much easier.
- Use #Jenkins to build and deploy new images.
- Don't use --link, use Docker networks instead!
- jwilder/nginx-proxy still has some bugs, especially with custom nginx configurations, but a wonderful tool.
- jrcs/letsencrypt-nginx-proxy-companion and it was never easier to get certificates.
- Think about reboots. How you want your containers to be managed? Services for systemctl work quite well so far.
- Redirect your application logs to the right output. Log management I should take a look at again.
Should also get my private projects into containers next.
This website is tracked using the Piwik analytics tool. If you do not want that your visits are logged this way you can set a cookie to prevent Piwik from tracking further visits of the site (opt-out).