[Concrete5] フルサイトマップでページ属性を変更したときに即時公開されてしまうのを承認待ち状態にする設定

デフォルトの状態のConcrete5のフルサイトマップでページ属性を変更すると即時公開される仕様なのですが、
ページの歯車から属性を変更すると承認待ちになるという仕様なのを今まで知りませんでした。

フルサイトマップのメニュー

ページの設定

知らなかったというか、基本的に納品までの制作を請け負うことはあっても、納品後の運用はクライアントが行うので納品後にページから属性を変更する作業をしたことがなかった、というのが正しいのかもしれません。

設定を教えていただいたので、備忘録的に残しておきます。

/concrete/config/concrete.php の430行目あたりに ‘sitemap_approve_immediately’ => true, とあるので、これをfalseにして /application/config/concrete.php に記述してオーバーライドします。

/application/config/concrete.php

<?php

return [
    'misc'              => [
        'sitemap_approve_immediately' => false,
    ],
];

これでフルサイトマップで属性を変更しても承認待ちになります。

[Concrete5] オプションリスト属性で複数の値を設定したときのタグ付け[メモ]

属性の値はページテンプレートでそのまま取得しようとすると以下のような書き方になるのですが、

// ページテンプレートの場合
<?php echo $c->getAttribute('option_list');?>

オプションリストで複数の値が設定されている場合、すべて生のテキストが出力されてしまってデザインが実現できません。

オプション1 オプション2 オプション3

foreachで回せばタグ付けできます。

<ul class="option-list">
<?php 
$option = $c->getAttribute('option_list');
foreach($option as $op) {?>
  <li><?php echo $op;?></li>
<?php } ?>
</ul>

<ul class="option-list">
  <li>オプション1</li>
  <li>オプション2</li>
  <li>オプション3</li>
<ul>

[Concrete5] サイト属性の取得 [メモ]

Concrete5のバージョン8からサイトに属性がつけられるようになったので、使ってみました。

[参照元]
サイト属性値を取得する concrete5 Japan 日本語公式サイト

/dashboard/system/basics/attributes で属性を作って、
/dashboard/system/basics/name に属性値を入力して、
テーマに

<?= Core::make('site')->getSite()->getAttribute('属性のキー'); ?>

を書くだけ!簡単!すごい!!

なぜか「<?=」が、「<?php 」だと動かなかったのですが、その辺は詳しくないのでよくわからないです。

[Concrete5 v8]上級権限モードで権限を設定する時につまづく私のための備忘録[メモ]

Concrete5で、上級権限モードにすると承認フローや、アカウント別の管理画面へのアクセス処理など、非常に細かく設定ができます。
が、制作上権限の設定を忘れて、ファイルマネージャーへ管理者アカウント以外でアクセスできなくなってしまったり、新規ページコンポーザーでアクセス拒否のエラーが出たりして、あれ、どこで設定するんだっけ?的なことがちらほらあります。
上級権限モードにした時に設定を忘れないように、備忘録をつけておきます。

上級権限モードとは

上級権限モードにすると

  • ページの閲覧・編集・編集の承認(公開)・管理(移動やコピー)・削除
  • ページの公開日時と公開終了日時の指定
  • エリアの閲覧・編集・編集の承認(公開)・管理(移動やコピー)・削除
  • エリアに追加出来るブロックの制限
  • ブロックの閲覧・編集・削除
  • 作成できる子ベージのページタイプの限定
  • グループへの期間限定加入

をユーザーやグループ毎に行えるようになります。
Concrete5日本語公式サイトより

権限の設定箇所が結構とっ散らかっている印象があって、ついうっかり設定を忘れてしまうことが多いです。

設定する箇所について

権限グループを作って、ユーザーごとに権限グループを割り当てる方法をとっています。
デフォルトでは、スーパーユーザー(インストール時のアカウント)はグループに属していないため、制作中はスーパーユーザーを使っていると、承認フロー周りの確認などでつまづくことがあります。
実際ありました。

僕が設定するグループは大体三つで、

  • 管理者:最上位権限
  • 編集者:編集・ページ追加のみ
  • 制作者:最上位権限

になります。
管理者と制作者は基本同じ権限に設定しているのですが、運用時に承認フローで承認メールを飛ばしたりする際に制作側に承認を求められても困るので、
管理者グループのみに承認メールを飛ばすようにするための区分けです。
スーパーユーザーがあるのに制作者グループを作っているのは、チームで制作する際のアカウントのためです。

原則的に、編集者が編集を行ってワークフローに送信してもらって、管理者が承認を行って公開、というイメージです。
そのほかにも編集者にはページを削除する権限を外したり、テンプレートの変更を行えないようにして作業範囲を限定的にすることで意図しないサイトの崩壊を防ぐ目的で制作しています。

なお、僕がいつも設定している箇所は以下の通りです。

ページ権限

場所:/index.php/dashboard/sitemap/full
基本的に、ページの権限は、フルサイトマップでトップページに設定をして、下階層はトップページを継承するようにしています。

また、もっと細かく設定したい場合、例えば、
「NEWS」ページだけを追加編集できる権限グループには、トップページから権限継承せずにNEWSページ以下のみにページ追加の権限を与えるとか、
ページ追加はできないけど、編集だけできる権限グループを作ったりとか、応用するとかなり細かく設定できます。

一般公開したくないページを作る場合は、権限を継承せずに手動で「表示」のゲストを登録ユーザーなどに変更すればいいかと思います。

ページタイプ権限

場所:/index.php/dashboard/pages/types
追加できるページタイプごとに権限を設定できます。
ここの設定をすることで、「ページの追加とサイトの案内」ボタンクリック時の「新しいページ」にページタイプが表示されます。
ここの設定を完全に忘れていて、下位権限グループで「新しいページ」の項目が表示されなくて小一時間悩みました。

スクリーンショット 2018-03-15 17.10.07

Screen Shot 2018-03-15 at 17.18.10-fullpage

スクリーンショット 2018-03-15 17.37.16

ファイルマネージャー権限

場所:/index.php/dashboard/system/files/permissions
ファイルマネージャーにアクセスする権限や、ファイルの操作に関する権限を設定できます
スクリーンショット 2018-03-15 17.22.05

タスク権限

場所:/index.php/dashboard/system/permissions/tasks
各種設定や、操作などの権限を設定できます。
なぜかフルサイトマップのアクセスもここにあったりして、ややこしいです。
僕はフルサイトマップを使用してページの更新をするのが効率がいいと考えているので、編集者グループにもフルサイトマップへのアクセスを許可すべきかと思っています。
スクリーンショット 2018-03-15 17.24.17

ユーザー権限

場所:/index.php/dashboard/system/permissions/tasks
ユーザーの追加や、削除などへのアクセスの権限です。
編集者にユーザーの追加や削除の権限は与えない方針です。
スクリーンショット 2018-03-15 17.26.59

以上です。

[concrete5 サイト制作] 社会福祉法人 恩賜財団 東京都同胞援護会

社会福祉法人 恩賜財団 東京都同胞援護会のサイトを10年ぶりにリニューアルしました
https://doen.jp/

昔MTで作ったせいで更新がすごく大変だったものをconcrete5にしてクライアントの更新作業が楽になるように設計。
もうずっとリニューアルしたかったんですよ

Screen Shot 2017-04-03 at 16.15.24-fullpage

Screen Shot 2017-04-03 at 16.15.39-fullpage

Screen Shot 2017-04-03 at 16.16.09-fullpage

Screen Shot 2017-04-03 at 16.16.03-fullpage

やったこと

  • デザイン
  • HTML/CSS/JSコーディング
  • レスポンシブ
  • concrete5組み込み
  • フォーム作成(concrete5外)
  • 承認フロー
  • 運用マニュアル作成

つらかったこと

  • 同じフォーマットにひたすら住所やら電話番号やら座標やらを入力していく作業
    →xmlかcsvでインポーター使えばよかったと反省。あるいはデータ投稿だけしてもらうバイトを雇えばよかった。
  • 承認フローがなかなかうまく機能してくれなくてどハマり
    →参考文献がなかったのと、フォーラムに質問するということを考えなかったので反省。次からはググってもわからない問題はフォーラムに質問しよう。
  • さくらサーバーで通知メールが飛ばない問題
    →もうどうしようもなくてフォーラムに相談して解決してもらった。

更新性が高い設計にするために汎用性をもたせつつ、デザインを両立させるという作業に対して、非常にモチベーションが高く保てたかな、と。
今回制作ページは160ページほどで、concrete5で作らなかったらおそらく3倍くらいの作業時間が必要だったのではないかなーと思います。

リリースしたおかげで今月は暇になったからゆっくり療養します。もう体がバキバキ。

[concrete5] Ver8.0.3 さくらのレンタルサーバーだとメール通知が送れない問題[解決]

表題の通り、さくらのレンタルサーバーでメール通知が送れない問題が発生して、ログを見てもわからないし、さくらの管理画面にエラーログは出力されないしで、全く原因がわからず1日半くらい費やしてしまってからフォーラムに相談してやっと解決できたのでご紹介します。
フォーラムで教えてくださった方に感謝。

concrete5 JAPAN フォーラム コメント欄のメール通知が送られない

おそらくさくらのレンタルサーバーでのセキュリティで、送信元ドメインが不正だとphp関数からメールが送れない、というのが原因だったのかと思います。

環境は以下

  • さくらレンタルサーバー ビジネス
  • PHP 5.6.30
  • mySQL 5.5
  • concrete5 8.0.3

確認した送れない通知メールは以下

  • コメント欄ブロックの通知
  • メール送信テスト
  • パスワード再発行のメール

なお以下の通知メールは送れていました。

  • ワークフローの通知
  • フォームブロックからの投稿通知

application/config/generated_overrides/concrete.phpに以下を追記して対処しました。

<?php

/**
 * -----------------------------------------------------------------------------
 * Generated 2017-02-27T15:34:58+09:00
 *
 * DO NOT EDIT THIS FILE DIRECTLY
 *
 * @item      cache.full_page_lifetime_value
 * @group     concrete
 * @namespace null
 * -----------------------------------------------------------------------------
 */
return [
    'locale' => 'ja_JP',
    'version_installed' => '8.0.3',
    'version_db_installed' => '20161216000000',
    'misc' => [
        'login_redirect' => 'DESKTOP',
        'access_entity_updated' => 1488174725,
    ],
    'cache' => [
        'blocks' => false,
        'assets' => false,
        'theme_css' => false,
        'overrides' => false,
        'pages' => '0',
        'full_page_lifetime' => 'default',
        'full_page_lifetime_value' => null,
    ],
    'theme' => [
        'compress_preprocessor_output' => false,
        'generate_less_sourcemap' => false,
    ],
    
    
    // さくらレンタルサーバー用メール通知 ここから
    'email' => array(
        'enabled' => true,
        'default' => array(
            'address' => 'concrete5-noreply@' . (isset($_SERVER['SERVER_NAME']) ? $_SERVER['SERVER_NAME'] : 'localhost'),
        )
    ),
    // さくらレンタルサーバー用メール通知 ここまで    
    
];

[concrete5]ページリストからページのエリアを表示する

ページリストで、ページ属性の取得は$page->getAttribute(‘handle’);で簡単にできたのですが、ページ内のエリアの取得ができなくてハマってしまってかなり時間を費やしてしまったのでメモ。

acliss19xxさんに教えていただきました。

カスタムテンプレート内に、下記を書くと表示できます。

$a = new Area('Main');
$a->display($page); 

[Concrete5]Block Designer Proを使う時のちょっとした罠

Concrete5.6まではDesigner Contentが無料で使えたので非常に良かったのですが、5.7以降はDesigner Contentのアップデートがなく、5.7以降では有料のBlock Designerを利用するようになりました。

今回繰り返しのブロックを作る必要があって、$65もするBlock Designer Proが必要になってしまったので購入してインストールしようとしたところ、version8 compatibleって書いてあるのにどうしても「RamonLeenders\BlockDesigner\FieldType\FieldType not found」と出て、インストールができなかったのでちゃーんとアドオンのページを確認したら、「(so Block Designer is required first)」って書いてありました。

単純すぎてアホらしいけど、Block Designer自体がないとBlock Designer Proはインストールできないのでした。

つまり、$65で購入したBlock Designer Proはそれだけでは意味がなく、$30のBlock Designer本体が必要と。
トータルで$95もかかりました。

[concrete5]concrete5.6はphp5.6のサーバだと動かなかった

スクリーンショット 2016-01-04 4.33.46

もともとphp5.3の環境で動いていたconcrete5.6を、php5.6が動いているサーバーに移行したところ、
こんなエラーが出て使えなくなってしまったので、エラー文の部分をコメントアウトしたら直った。

/concrete/libraries/3rdparty/Zend/Cache/Core.php on line 361

 if ($this->_options['automatic_serialization']) {
            // we need to serialize datas before storing them
            $data = serialize($data); 
        } 


 if ($this->_options['automatic_serialization']) {
            // we need to serialize datas before storing them
            // $data = serialize($data); 
        } 

原因は調査中。

あんまりコアファイルをいじりたくないけど、もう5.6をこれ以上アップデートすることもないし、サイトリニューアルの時にはconcrete5.7でやりましょうと提案すれば問題はなさそう。

余談。5.6がゲシュタルト崩壊しそう

[Concrete5]上級権限モードとは別に、テーマ側でユーザ判別したい時。

昨日Concrete5部で上級権限モードの話をしていたので、僕も何か書こうと思います。

上級権限モードは、ページの編集権限から、個別のエリアの編集や追加権限など、非常に事細かに設定ができるすぐれものなのですが、設定が非常に大変です。権限の設定だけでひと財産築けるんじゃないかなって思うくらい大変です。ジョークです。

そして、今回は上級権限モードとは関係の無い話でした。

一体なにがしたいのか

下記のコードを実際に使っているのですが、一体何をしようとしているのか。
「編集モードだったら+ユーザーがadminだったら、エリアを表示する」
という書き方をしています。

理由は以下の通り

  • スマホ版のテーマが別にある(レスポンシブではない)。
  • スマホ版の編集もPCで行う。
  • PCとスマホで表示する内容が異なる。
  • このエリアが編集できるのは、「admin」さんだけ。

つまり、レスポンシブではなく、モバイル用のテンプレートを別で用意していて、それぞれに別の情報を表示したい、でもエリアを表示できるのはadminさんだけに限定したい、というとてもニッチな状況で下記のコードで対処しました。

PC側のテンプレート

/themes/pc/elements/header.php
<?php
if ($c->isEditMode() && $u->getUserName() == 'admin') {
global $c;
$a = new GlobalArea('sp area');
$a->display($c);
} else {
} ?>

スマホ側のテンプレート

/themes/sp/elements/header.php
<?php
$a = new GlobalArea('sp area');
$a->display($c);
?>

それで、できたあとに気づいたのですが、ブロックテンプレートにmobile_detectを使うとか、そもそもadminさんしか編集できないならテーマにハードコーディングしてしまえばよかったなと思いました。

追記

ツイッターでacliss19xxさんから教えてもらいました!

「admin」さんだけだったら、スーパーユーザーだけって書いた方がいいですね。

PC側のテンプレート

/themes/pc/elements/header.php
<?php
if ($c->isEditMode() && $u->isSuperUser()) {//←ここ
global $c;
$a = new GlobalArea('sp area');
$a->display($c);
} else {
} ?>