PHP7.3のアップデート完了!

古いPHPを削除して新規に入れ直しました。ここまでも結構大変でしたが、それでもなんとか目的は達成。しかし、本当に大変だったのはこの後でした・・・orz... [続きを読む]

+1

remi-php73のアップデート

とりあえずシステムがらみのアップデートはyumで完了したものの、PHPのアップデートはPHP7.3のyumで行われていなかったため、改めてremi-php73リポジトリを有効にしてPHPのアップデートを行うことにしました。... [続きを読む]

0

Counterize iiアクセスカウンタ表示変更

とりあえずトップページにアクセスカウンタを表示できるようにしましたが、カウンタが左揃えで表示されているなど、「それってどうなの?」という部分に気がついてしまったので、ちょっと変更してみました。 ちなみに変更前は、sidebar-extra.phpに下記タグを追加。

<li><h2>アクセスカウント</h2> <ul>今日 : <?php echo counterize_gethitstoday();?></ul> <ul>合計 : <?php echo counterize_getamount(); ?></ul> </li>... [続きを読む]

0

Leopressでアクセスカウンタを表示する

Macっぽくてお気に入りのLeopressですが、いくつか残念な事も。 というか、これまでのテーマと表示される内容が違くて戸惑っていることが。 例えば、更新カレンダーが表示されない、とか、最近のコメントが表示されない、とか。 もちろん更新カレンダーが表示されなくてもポストされた日付をみればそれはわかりますし、コメントだってログインしたときに出る上部ツールバー(?)にコメントアイコンがあって、コメントがあればそれで分かるようになっているのですから困ることはありません。 なのでこれらについてはまたおいおい考えるとして、ちょっと困った・・・というか残念な感じがするのは、トップページにアクセスカウンタがないこと。 今までのテーマでは、ウィジェットを配置することでCounterize iiのアクセスカウンタを表示できていたのですが、Leopressではそのウィジェットが表示されません。 アクセス数だってダッシュボードにログインすれば確認できるのですが、やっぱりBLOGトップに数字が出れば、「今日はこれくらいアクセスがあったのか~」とか色々思えるじゃないですか。 というわけで、やっぱりアクセス数は表示したい! ので、調べてみました。 するとどうやら、表示したい場所に次のPHPを書き込むことでできるらしいことがわかりました。

<li><h2>アクセスカウント</h2> <ul>今日 : <?php echo counterize_gethitstoday();?></ul> <ul>合計 : <?php echo counterize_getamount(); ?></ul> </li>... [続きを読む]

0

XML sitemap generatorの時刻をいじる(失敗!)

以前、counterize iiの時刻がずれてしまうという投稿をしたときに、その対処法としてwp-settings.php内の「date_default_timezone_set( ‘UTC′ );」を「date_default_timezone_set( ‘UTC+9′ );」に書き換える(タイムゾーンの設定をUTC+9にする)という方法を取りました。 この方法でWordPress本体の投稿もcounterize iiのログ時刻もきちんとJSTに揃うようになったのですが、前回投稿したように、この状態だと(なぜか)Sitemap Generatorの時刻が+9時間ずれてしまうことが判明。 で、どうしたものかと思案しつつ、結局google先生に尋ねてみることに。 すると・・・。 どうやら上記「date_default_timezone_set( ‘UTC′ );」の該当行に+9の設定をするのではなく、この行それ自体をコメントアウトすることで対応できるっぽいことがわかりました。 そこでさっそくやってみることに。 SSHでサーバにログインし、設定ファイルをいじれるユーザになってから、wp-settings.phpのあるディレクトリまで移動します。

# vi wp-settings.php... [続きを読む]

0

WordPress画像アップロード時、HTTPエラー!?

さて、アップロードできるファイルのサイズを大きくできたので、iphone5sで撮影した旧山古志村の牛の角突きをアップしようと思い、写真を一括でアップロードしてみたところ・・・。 httperror_01・・・orz なんだ、このHTTPエラーって・・・。 (※その後、メディアライブラリを見たらちゃんとアップロードできているっぽいんですけどね・・・) というわけで現況確認。 前回の投稿でも大量の画像をアップしましたが、その時はこんなエラーは吐かれていませんでした。 ということはファイルサイズが原因かも(アップロード処理が追いついていないのかも)? というわけで調べてみると、どうもapacheがらみでエラーが発生している可能性があるようです。 この参照先では「mod_fcgid: HTTP request length 133926 (so far) exceeds MaxRequestLen (131072)」というエラーがapacheのログに吐かれている、とありましたが、ウチで確認して見たところ、ウチのapacheではこのエラーは吐かれていませんでした。 かわりに「PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /var/www/html/blog/wp-includes/class-wp-image-editor-gd.php on line 167, referer: http://boota.mydns.jp/blog/wp-admin/post-new.php」というログが吐かれてました。 PHP Fatal errorって・・・何がそんな致命的なエラーになっているんだ? でもって当然これも調べてみました。 どうやらウチで行えそうな対処は参照先で上げられている方法のうち2つのようです。 一つ目はPHP.iniの編集。二つ目はhttpd.confの編集です。 どちらか一つでいいようなので、吐かれているエラーがPHPのFatal errorということから、まずはPHP.iniに手を加えることにしました。 PHP.iniの中に「max_execution_time =」という部分があるそうなので、ここに有効な値を設定すればいいみたいです(0にすると無限となるようですが、これをすると処理が終わらない限り延々と処理を試みるゾンビになってしまうこともあるそうです)。 PHP.iniは/etc以下にあることは既に学習済みですので、該当個所を探してみます。

# vi /etc/php.ini (中略) ;;;;;;;;;;;;;;;;;;; ; Resource Limits ; ;;;;;;;;;;;;;;;;;;; ; Maximum execution time of each script, in seconds ; http://www.php.net/manual/en/info.configuration.php#ini.max-execution-time max_execution_time = 30 (略)... [続きを読む]

0

WordPressでアップロードできるファイルサイズの上限を上げる(成功!)

というわけでもういっちょう。 さて、例のWordPressのネットワーク管理者の管理画面とかいう画面が一体どこにあるのか、まずそれを探さなければなりません。 っていうか、結論から言うと、「ありません」。少なくとも、デフォルトの状態では。 でもそれは言い換えれば、ある設定をすることでその画面を出すことができる、ということでもあります。 そのあることとは、

WordPress内にある「wp-comfig.php」ファイルの「/* 編集が必要なのはここまでです!WordPressでブログをお楽しみ下さい。*/」と書かれている項目の上にdefine(‘WP_ALLOW_MULTISITE’, true);と追加してサーバーにアップロードします。... [続きを読む]

0

BackWPupでエラー? 続きっ!

前回(といっても直前だけど・・・笑)の投稿後、早速httpdを再起動。 こうやってコンポーネント単位で再起動ができるのって、ホント便利ですよね。 これ、Windowsだったらきっとマシンごとオールリセットですぜ・・・。 それはさておき。 WordPressのダッシュボードからBackWPupにアクセスし、自動バックアップで登録してあるJOBを手動で実行させてみてエラー(警告)が出ないかどうかを確認しました。 結論から言うと・・・。 ばっちりOKが返ってきてます!(^-^) これで一つ問題が解決した〜〜♪ うれしいなっ。... [続きを読む]

0

BackWPupでエラー?

コンテンツを自動バックアップしてzipやTarでまとめてくれる便利プラグインBackWPup。 その後ずっと走らせ続け、週に一度のペースでバックアップを取得させているのですが、先日BackWPupのダッシュボードを見ていて少しおかしな事に気がつきました。 それが、これ。 3月2日のバックアップまでは全く問題ないのですが、ナゼかその一週間後の10日以降はすべて4つの警告が発されています。 しばらくは理由が分からなかったのですが、ふとバックアップ時刻に目がとまりました。 うまくいっていた3月2日は、15時のバックアップに対して、警告が表示されているバックアップはすべて9時台になっています。これ、記憶の糸をたぐってその原因を探っていくと・・・思い出しました。 前に、WordPressのダッシュボードで、タイムゾーンの設定をいじったんです。それまではUTCに対して±○時間で時差を指定していたのを、タイムゾーンとして東京(ASIA)を指定したんです。 そして、多分そこからこの警告が発生しているんでしょう。ちなみに、UTCを基準にして(つまりUTCで0時ならば)+9時間なら9時に、ー9時間なら15時になりますね(笑) 私、なにか勘違いして±を設定していたのかも?? ま、それはさておき、原因の目処がついたところで今度はその対処を探さなくてはなりません。 せっかく警告が発せられているのですから、その警告を見てみることに。すると・・・。 黄色いところが直接的な警告です。テキストで抜き取ってみると、全文はこんなカンジ。

WARNING: date_create(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘Asia/Tokyo’ for ‘JST/9.0/no DST’ instead... [続きを読む]

0