jetpack

WordPress更新時に出る Allowed memory size エラーの解消法

WordPressへの更新時

Fatal error: Allowed memory size of  ~

のエラーが発生した場合、各サーバーで設定しているphpのメモリ上限(memory_limit )を超えてメモリを使おうとしている為にエラーが発生します。
場合によってはサイト全体がエラーとなり管理画面にも入れないようになってしまいます。

この症状解決方法は2つ

memory_limitを上げる

各サーバーによってPHPの設定を変更するにはphp.iniや.htaccessまたwp-config.phpなどを編集することによってmemory_limitの設定を行うことができます。

Fatal error: Allowed memory size of  許可されているメモリリミット bytes exhausted (tried to allocate 上限以上に使おうとしたメモリの量)

の様にエラーが出ますので上記の「上限以上に使おうとしたメモリの量」以上にmemory_limitを設定できれば解決します。

WordPressのブラグインを止めてみる。

ただmemory_limit既にサーバーの上限に達している場合は使用しているメモリを減らすしか方法がありません。
WordPressのプラグインにはプラグインごとの負荷を表示できるものがありますので、負荷が大きいもの(≒メモリ消費の大きいもの)を止めると改善できます。(Advanced Metricsタブを使用すればWordPressが使用しているメモリの使用量<Memory Usage>等も確認できます)

P3 - Plugin Performance Profiler の画面
プラグインの負荷が確認できる「P3」( Plugin Performance Profiler)プラグイン。 jetpackの負荷が高いことが確認できる

メジャーなプラグインではjetpackがダントツの負荷率なのでもしエラーで管理画面に入れない場合は試しにFTPで「/wp-content/plugins」の中の「jetpack」ディレクトリをリネームまたは削除するとエラーが解消されるかと思います。

今回はkagoyaの共用サーバ(memory_limit 80M )でWordpress 4.8–jaの更新時でこのエラーに遭遇。

Yahoo!ショッピングでFTPのアプロードが反映されない(2017年5月9日以降)

Yahoo!ショッピングでオプションサービスの「トリプル」を契約しFTPでページ更新を行っている場合、2017年5月9日からYahoo!ストア側のAOSSL(常時SSL)に関連して、htmlページやjsファイル内にAタグやimgタグなどにSSL通信ではない「http://」を含んだアドレスがある場合はストアエディタ上部にメッセージが表示され、リンクされているPDFファイルに記載されている箇所を修正する必要があります。

常時SSL(AOSSL)対応 修正対象一覧ダウンロード

もしこのメッセージが表示されている場合は該当するURLを含んだHTMLファイルなどをFTPでアップしても更新内容が反映されませんのでご注意ください。

出典 [AOSSL対応]トリプル入力制限実施のお知らせ

ECCUBE2.x(2.12.0~2.13.1)で「のし対応」プラグインが他のプラグインに干渉してしまうのラグインに干渉してしまう

ECCUBE2.x(2.12.0~2.13.1)で「のし対応」プラグインが他のプラグインに干渉してしまう

ECCUBE2での人気プラグインに「のし対応」プラグインhttp://www.ec-cube.net/products/detail.php?product_id=278)がありますが、商品購入の際のテンプレートを結構な感じで書き換えてしまうため他のプラグインが動かなくなったりします。
あとスマホ用のテンプレートもうまく動かなり、結局以下のような感じで対応しました。

  1. インストール済みの「のし対応プラグイン」のファイルをバックアップ:同プラグインを入れると以下のようにディレクトリ出来ます。
    dataフォルダ/downloads/plugin/GiftPaper

    ECCUBEの「data」フォルダ(※インストールのやり方でディレクトリ名やサーバー上のパスが変わります)以下にある「downloads」ディレクトリの中にプラグイン用のサブディレクトリが出来ており、今回は「のし対応プラグイン」の「GiftPaper」ディレクトリをFTPなどでローカルに落とします。

  2. GiftPaper.phpを書き換える:同プラグインの本体は「GiftPaper」ディレクトリ内の「GiftPaper.php」になります。
    こちらの414行あたりから

    function prefilterTransform(&$source, LC_Page_Ex $objPage, $filename) {
      $objTransform = new SC_Helper_Transform($source);
                                   以後省略

    の様にECCUBEデフォルトのテンプレートを書き換える処理が入ります。
    今回はスマホの表示がおかしい(のしの選択肢が出ない、選んでも確認画面に進めないなど)がありましたので、スマホのテンプレを書き換えている部分を修正しました。
    (ECCUBEでプラグインからデフォルトのテンプレを書き換える際には「SC_Helper_Transform(トランスフォーム)」)という機能を使って処理を行います。
    基本的にはJQueryで要素を書き換えたり追加する処理と同じです。詳細に関してはプラグイン作成のリファレンス(http://downloads.ec-cube.net/src/manual/12.0_plugin/plugin.pdf)の11ページあたりを参照してください。)
    以下のソースでは「//リプレイスでの対応」とあるようにテンプレートのある部分を「replaceElement」を使ってごっそり置き換える処理を行っています。(461行目)

     // 458行目辺り。お支払方法・お届け時間等の指定画面
     if(strpos($filename, "shopping/payment.tpl") !== false) {
     //リプレイスでの対応
     $objTransform->select('section#undercolumn')->replaceElement(file_get_contents($template_dir . 'shopping/plg_GiftPaper_payment_section_replace.tpl'));
     //$objTransform->select("section#undercolumn section.point_area", 0)->insertAfter(file_get_contents($template_dir . "shopping/plg_GiftPaper_payment_section.tpl"));
     }

    この「replaceElement」で置き換えているのが「GiftPaper」ディレクトリ内の「shopping/plg_GiftPaper_payment_section_replace.tpl」ファイルになりますが、他のプラグインが書き換えようとする際に必要な要素やセレクタ(idやclass)が含まれておらずテンプレートが書き換えられない為干渉が起こってしまう模様。
    なのでその下にコメントアウトしてある用意してある462行目

    $objTransform->select("section#undercolumn section.point_area", 0)->insertAfter(file_get_contents($template_dir . "shopping/plg_GiftPaper_payment_section.tpl"));

    のほうをコメントを取ってアクティブにします。(逆に461行目の部分はコメントアウトするか消します。)
    この部分ではデフォルトのテンプレートの「section#undercolumnのsection.point_area」の後に「GiftPaper」ディレクトリ内の「shopping/plg_GiftPaper_payment_section.tpl」を挿入するという処理ですので他のプラグインで干渉する心配がなくなります。

    うまく動かない場合はsection#undercolumn section.point_area のセレクタの部分が適切かどうか見直し、「GiftPaper」ディレクトリ内の「shopping/plg_GiftPaper_payment_section.tpl」も見直してもらうと大丈夫かと思います。

MODX Revolution (MODX 2.x) のアップデート手順

MODX Revolution (MODX 2.x) のアップデート手順は至ってシンプルです。

  1. バックアップ:phpmyadmin等を使ってDBのバックアップとFTPなどを使ってサーバ上のファイル類丸ごとバックアップします。
  2. 新しいバージョンのファイルで上書き:FTPなどを使って予めダウンロードしていた新しいバージョンのmodx 2.x のファイルを展開しFTPで上書きします。
    そののちブラウザでsetupページ

    http://ドメイン/setup

    にアクセスし、アップグレード作業を進めます。(この時すでにmodxがインストール済みの場合は自動的にアップデート関連のチェックが入って「次へ」のボタンを押すだけでアップデートが完了します。)
    その際注意が必要なのは2.2.x のバージョンから2.3.x、2.4.x、2.5.xなどそれ以上のバージョンにアップデートする際、2.2.0以降ででDBのフィールドが6つほど追加になっており、2.3.0、2.4.0、2.5.0のように各バージョンの最後が「.0」で終わるものでDBのフィールドが変更になっていることがほとんどの為

    2.2.x2.3.02.4.02.5.0

    のように段階的にバージョンアップする様にします。

  3. 念のため「キャッシュをクリア」のメニューでキャッシュをクリアし、各所動作確認を行います。
    この際Modx自体がフロントにAjaxを多用しているためブラウザ側のキャッシュもクリアしないとpackagemanager(パッケージマネージャー)が動かなくなったりします。

    もしキャッシュをクリアしてもうまく動かない場合は「エラーログ」メニューからエラーログを確認し、エラーがある場合は適時修正を行います。

以上バックアップ以外は基本的にFTPでファイルを上書きするだけなので問題が起こらなければ3~5分程度で完了する工程です。

 

grocerycrud.でデートピッカーがエラー

Grocery CRUDのDatepickerでエラーが出る

Codeigniter のCRUDを簡単に生成する「Grocery CRUD」を使ってましたら、いつも間にか datetime型を扱う際に自動で設定されるDatepickerがjqueryのエラーで動かない。
でもよくよく見てみると直接Datepickerがエラーを起こしてるんじゃなくて、同じフォーム内にbooleanを扱うようなラジオボタンがあると連鎖的にエラーを起こすみたい。

grocerycrud.でデートピッカーがエラー

jquery.uniform.min.js:1 Uncaught TypeError: Cannot read property ‘msie’ of undefined(anonymous function)
jquery.uniform.config.js:2 Uncaught TypeError: $(…).uniform is not a function

と言ったもので、Codeigniter のassets以下のgrocery_crudのファイル群の中

grocery_crud\js\jquery_plugins\jquery.uniform.min.js

grocery_crud\js\jquery_plugins\config\jquery.uniform.config.js

がその原因みたい。
Cannot read property ‘msie’  とあるのでユーザエージェントの取得がかなり古いバージョンのjqueryの書き方なのでこれで躓いているみたい
なのでjquery.uniform.min.jsの最新バージョンと差し替える為以下のページからアーカイブ(Uniform v2.1.2)を落とすなりしてgrocery_crudディレクトリ内のjquery.uniform.min.js(Uniform v2.0.0)と差し替える
https://github.com/pixelmatrix/uniform

これにて動作するようになりました。