定期的にGoogleでcomposer gui appで検索していたのだけどこの度見つけたので紹介。
タイトルのDrupalに限らず基本的にPHPのパッケージマネージャはComposerがデファクトスタンダードです。Composerはいわゆる黒い画面から操作するので、日頃から黒い画面に触れていない人にとってはハードルが高いですよね。そこで登場するのがこのComposerをアプリから操作する、Composercat – GUI for Composer (PHP)。
[無問題]Composer でパッケージの削除は composer remove で問題ない
[無問題]Composer でパッケージの削除は composer remove で問題ない
Composer でパッケージの削除は composer remove が良いと思ったらそうでも無かった – Qiita 本当かな？と思って試してみたら問題なかったので書く。
~/dev/composer_test
❯ composer remove oreore/b
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 2 removals
- Removing oreore/b (v1.0.0)
- Removing oreore/d (v1.0.0)
Writing lock file
Generating autoload files
oreore/d も一緒に削除されている
~/dev/composer_test
❯ composer --version
Composer version 1.4.2 2017-05-17 08:17:52
まとめ
- 投稿時から時間が経っているので解決されたのかも
- 試してみるの大事
~/dev/composer_test
❯ tree
.
├── a
│ └── composer.json
├── b
│ └── composer.json
├── c
│ └── composer.json
├── composer.json
├── composer.lock
├── d
│ └── composer.json
└── vendor
├── autoload.php
├── bin
├── composer
│ ├── ClassLoader.php
│ ├── LICENSE
│ ├── autoload_classmap.php
│ ├── autoload_namespaces.php
│ ├── autoload_psr4.php
│ ├── autoload_real.php
│ ├── autoload_static.php
│ └── installed.json
└── oreore
├── a
│ └── composer.json
└── c
└── composer.json
10 directories, 17 files
DrupalのContenta CMSとReservoirについて
2017年の6月にReservoirはAcquiaから発表された時に、それ以前からあるContentaに立ち位置が近いの気になって時々状況を確認している。この文章は現時点でのスナップショット。
どちらもコンテンツをAPIで提供するというところで利用シーンが重複するものの、現時点でContentaはAPI FirstのDrupalディストリビューションでReservoirはコンテンツレポジトリというポジションに落ちこうとしている様子。具体的にはContentaは通常のDrupal APIでDrupalの守備範囲を広げ、ReservoirはAPIのみで守備範囲を限定してシンプルにしたものと理解した。現時点でどちらを使うかと考えたらContentaな気がするけど、非DrupalistでDrupalの学習コストを割きたくないならReservoirもあるかと思う。
両陣営一瞬険悪になった感じもしたけど、お互い歩み寄ってフィードバックもしてるっぽくて安心しつつ今後に期待をしている。
Contenta CMS
- Contenta CMS
- Contenta, Reservoir and the Bigger Drupal Community | Contenta CMS
- contentacms/contenta_jsonapi: Contenta makes your content happy.
- contenta-makes-your-content-happy.pdf
- contenta | Drupal Slack
Reservoir
- acquia/reservoir: A back end for your front end: a content repository. Powered by Drupal 8, JSON API and OAuth2.
- Introducing Reservoir, a Distribution for Decoupling Drupal | Acquia
- reservoir | Drupal Slack
- ReservoirはDrupalのコア（標準）モジュールを最小限利用し非Drupalユーザでも使いやすく
Enabling Memcached on Acquia Cloud work with BLT
Enabling Memcache on Acquia Cloud work with BLT
In /docroot/sites/default/settings.php add the following configuration code after requiring blt.settings.php.
require DRUPAL_ROOT . "/../vendor/acquia/blt/settings/blt.settings.php";
$settings['install_profile'] = 'lightning';
/**
* Memcache setting.
*
* Enable setting if memcache service exists.
*/
if (\Drupal::hasService('cache.backend.memcache')) {
$settings['cache']['default'] = 'cache.backend.memcache';
}
Asset PackagistでフロントエンドJSライブラリを管理
bower, npm の代わりにcomposer 経由でjsライブラリを管理する拡張。これはただのパッケージマネージャとして捉えるべきで、npm, yarn のようにビルドはスコープ外。
Drupalで言えば、モジュールレベルで必要だったjsライブラリの追加がcomposer 経由でAsset Packagist を利用することで簡単に追加できるようになった。
これを導入しない場合は、手作業でダウンロード・配置するか以下のサンプルのようにcomposer.json を書く必要がある。
{
...
"require": {
"drupal/chosen": "^2.3",
"harvesthq/chosen": "^1.7"
},
"repositories": [
{
"type": "package",
"package": {
"name": "harvesthq/chosen",
"version": "1.7.0",
"type": "drupal-library",
"dist": {
"url": "https://github.com/harvesthq/chosen/releases/download/v1.7.0/chosen_v1.7.0.zip",
"type": "zip"
}
}
}
],
"extra": {
...
"installer-paths": {
"docroot/core": ["type:drupal-core"],
...
"docroot/libraries/{$name}": ["type:drupal-library"],
},
}
}
Drupal Meetup Tokyo Vol.6で紹介したBLTのリンク
Drupal Meetup Tokyo Vol.6でツールについて話す時間をもらったのですが、全く資料などは用意して行かなかったのリンクと追加情報を少し
もともとAcuqia Cloudを利用する予定があり、ドキュメントを見ていた時に見つけたのがAcuqia Pipeline。これは2016/12/23現在プライベートベータでまだリリースされていません。そこで営業さんにメールをしたところ、まだリリースされてないからこっちはどう？的にBLTを紹介されました。
WP4.7になったら500エラーでアクセスできなくなってた。
僕はWordpressの自動アップデートを有効にしてるんですが、その自動アップデートの影響でアクセスできなくなっていたのでその解決のメモ。
エラーログから検索して、Topic: READ THIS FIRST WordPress 4.7 Master List « WordPress.org Forumsに行き着きました。
僕の場合プラグインに原因があったようで、提示されている解決策の「全てのプラグインを無効化する」で解決しました。とはいえ、管理画面にすらアクセスできないので別の方法で無効化し今度は逆にひとつづつ有効化していき原因を突き止めました。
手順
- プラグインを無効化する（無効化したいが、管理画面にアクセスできないので以下の2つの方法がある）
- DBを直接いじる
- SFTPで接続してプラグインのフォルダ(/wp-contents/plugins)を一時的にリネームする
- 無効化したら、管理画面にログインしプラグイン管理のページに移動する。ここの段階でフォルダをリネームした場合は元に戻して画面をリロード
- ひとつづつプラグインを有効化してみる
- ダメなのに当たったら、アップデートするか保留する
以上
レンタルサーバではじめるモダンなDrupal8環境
目的
Composerを使ってDrupalを管理したいし、できる環境を見つけておきたい。
けど、レンタルサーバってそれぞれ制約が違う
ソースコードで全てを管理しておけば楽なのでそうしたい。
中級者向けくらいの記事かなと思ってます。
レンタルサーバ探し
AWSとかHerokuとか使えばいいんだけど、そうじゃないケースもあったので探して見ました。最初の候補はさくらインターネットでスタンダードプランを試したけど、Drupal8が素直にインストールできなさそうだったのでやめた。サーバの制約で.htaccessとかを書き換えるとかはないかな。
次はXserver。結論から言えばここを試用中で、その詳細は以下から。
Read more レンタルサーバではじめるモダンなDrupal8環境
Mailchimpのグループとセグメントの違いあるいは使い分け
最近Mailchimpを触ってます。
いちサービス利用者としては興味のないメールが届くことほど嫌なことはないですが、役に立つマーケティングメールが届くとそのサービスの自分の中での評価が上がる派です。
配信側としては登録者に役立つ情報を必要なタイミングで届くようにしたい無駄なメールは届けたくない訳ですが、そこで役に立つのがグループやセグメント。
グループもセグメント登録者のリストを配信内容の文脈に沿うように分割して管理するための機能ですが、若干わかりにくいところがあるのでざっくりまとめました。 Read more Mailchimpのグループとセグメントの違いあるいは使い分け
議論に集中したいオンラインワークショップで初めてRealtimeBoad使うメンバーに教えたい機能
先日書いたRealtimeBoard – オンラインでもワークショップを成功させたいという記事ですが、良さそうだったので早速実践投入しました。無事ワークショップの1セッションを乗り切ることもできましたし、使ってもらったチームのメンバーからも使い勝手について良いとの評価でした。
ただ今回はその評価ではなく、初めて使うメンバーへのツール導入する際にスムーズに使い始められるように意識した点について書きます。
画面越しのワークショップはコミュニケーションコストが高い
ビデオチャットなどの画面越しの会話だと「ここ」とか「これ」とか言っても相手に正確に伝わっているかわかりにくいものです。これは、実際に同じ場所に集まってワークショップを行うのに比べてコミュニケーションコストが上がり、本来注力したい議論に注力できず良い結果が出せないリスクがあります。
RealtimeBoadではコミュニケーションコストを下げる工夫がありますが、少しわかりにくいので紹介します。すでに使ったことがある方ならわかると思いますが、RealtimeBoadのよさは写真やテキスト、GoogleDocsやMicrosoftOfficeなどドキュメントを一枚のオンラインホワイトボードに乗せ俯瞰できるところにあります。そのためホワイトボードは広くなり議論の現在地を把握するためにはコツがあります。
Read more 議論に集中したいオンラインワークショップで初めてRealtimeBoad使うメンバーに教えたい機能
