投稿日:

今日は春先の陽気でルンルンの散歩

朝からいつもの冷たい風がやんで春先の☀、昼過ぎの散歩で多くのワンちゃんと出会って「まる」は元気一杯、吠えたり逃げたり、住区センターに着いて一休みだ。

明後日から又、大寒波襲来で真冬の寒さに戻り１～２週間ほど居座ると言ってたけど、温暖さが激しいと堪えるね。

投稿日:

秘密のフォルダー用に新たなBasic認証を作成

WordPress のディレクトリに専用のフォルダーを置き Basic 認証でオープンして phpInfo、APC、APCu 等の php ファイルやその他の資料を置いていたけど、いつの間にフォルダーをオープンする権限が無いので直接ファイルを指定してアクセスする方法となった。
いろいろ調べてみたところ、現在重宝しているプラグインの幾つかのコードが影響？、なので、新たに Basic 認証を作成して、そのフォルダー内に index.php を置いて資料一覧から呼び出すようにした。

① 以前と同様に「ApacheのopenSSLでBasic認証を作成して秘密のフォルダーを作る。」で htaccess、htpassword を作成して認証用のフォルダーに置き換えた。

② index.php の設置（簡単な header ＆ body、footer の作成）

　<html lang="ja">
 
　<head>
　　<meta charset="UTF-8">
　　<meta name="viewport" content="width=device-width,initial-scale=1">
　　<title>Hello PHP</title>
　</head>
 
　 <body>
　<p> <?php echo "The List of Secret Files"; ?> </p>

　<?PHP
　　$dirpath = "secretR/";	//ディレクトリパス
　　$dirlist = dir($dirpath);
　　while( $filename = $dirlist->read() ){
　　　　　　　　//ファイルのみ表示
　　if( (is_dir($filename) == false) && ($filename!=".." || $filename!= "." ) 　　　　){
　　print("<a href=\"" . $dirpath . $filename . "\">".$filename."</a><br />\n"　　　　);
　　　　}
　　　}
　　$dirlist->close();
　?>

　<p> <?php echo "The End of Secret Files"; ?> </p>
　<p>    <?php include './footer.php';?> </p>
　</body>
　</html>

[footer.php]
<footer>
    © 2026 <a href="https://www.　～　"> 　～　 </a> へ
</footer>

③ サブホルダー(secretR)を作成して資料を入れ直した。

※ 次のステップは、CSS や JS を使ったウエブサイトのホームページらしいものを作成する予定。。。

投稿日:

WordPress?、Xampp？設定したMemory_Limit関係のエラー！

ウエブサイトにアクセスしたところ、画面に「Allowed memory size of 1073741824 bytes exhausted (tried to allocate 4295229440 bytes) in /xampp/htdocs/wordpress/wp-includes/theme.php on line 325」とエラーの表示、メモリー関係のエラーで php.ini の 「memory_limit」の修正 や 「Opcache.jit」 の余分に追記した部分を削除した。

opcache.jit が問題では無いと思われるけど、取り合えず修正した。それと、php.ini の Memory_Limitで　64M を 512M に増やして試したところ、ログイン画面から管理画面へ移動できず、上記と同じエラーが現れたので、再度、Memory_Limit を 1024M に修正した。

①　[opcache.jit]
　　opcache.jit=tracing
　　opcache.jit_buffer_size=128M
　　opcache.enable_cli=1
　　※上記以外を削除した。

とにかく初めての経験なので、念には念をと、wp-config.php に以下を追加し、https://　～　　/wp-admin/maint/repair.php にアクセスして「データベースの修復」を実行した。

②　define( ‘WP_MEMORY_LIMIT’, ‘512M’ );　⇐　1024M に修正　
　＊define( ‘WP_ALLOW_REPAIR’, true );
　　※修復が終わったら（＊）の行は削除。

すると、プラグイン WP＿Optimize に関するテーブルにエラー（壊れてる）が発生してるだけで、WordPress のテーブルは正常に機能しているとの結果で一安心。
投稿日:

寒い一日だと言っても。。。

冷たい北風がやんだ昼過ぎ「まる」の散歩は住区センターで一休みしてから、何時ものように某高校脇を通って約30分ほどのコース。

常にセンターでは子供達で賑わっているのだけれど、今日に限っては「まる」が中庭を独り占めと言ったところ。まぶしいお天道様☀と一緒におやつを食べて さぁ～行こう！

投稿日:

画像処理 プラグイン “EWWW Image Optimizer”

「EWWW Image Optimizer」はインストールして有効化するだけで画像圧縮機能が有効化して、Wordpress にアップロードする画像を圧縮とファイルサイズを縮小、サイトの画像ファイルが軽くなる。

　初期設定
①　フロー形式の初期設定「メタデータ削除」欄の確認
　２ページ目に「メタデータを削除 (Remove Metadata)」、ここにチェックが入っていることを確認。
＊画像に含まれる位置情報やカメラ情報が削除され、プライバシー保護とファイルサイズの軽量化が同時に行われる。
② 「コンバージョンリンクを非表示」にチェック。
＊この項目は初期設定、完了後に管理画面から設定する。
　１． [Enable Ludicrous Mode]　←「ルディロクスモードを有効化」 をクリック。
　２． [変換 (Convert)]　←「コンバージョンリンクを非表示
　３．「Hide Conversion Links」にチェックを入る。
　＊ 画面下の [変更を保存] をクリック。

※この２点を行うことで、より画像サイズの低下に繋がるとの事、とにかく削除した WP Optimize の代替えでの利用なので、複雑な設定無しのプラグインが良いと思い使用することにした。

投稿日:

キャシュ処理 プラグイン “WP Fastest Cache”

MySQLのアップグレード問題で削除した WP-Optimaze の代替えで、キャシュ処理に特化したプラグイン WP Fastest Cache を試すことにした。

キャッシュを扱ったプラグインは複数あるけど、WP Fastest Cache は、特にシンプルで効果の大きいツールと言った評価なので導入を決めた。WP Fast Cache を有効化すると、WordPress のダッシュボードに「WP Fastest Cache」のアイコンが追加される。尚、キャッシュの有効化は設定で必要な箇所をチェックする。

　有効化した項目：
　１．システムキャシュ　←　有効化
　２．ログインユーザー　←　キャッシュを表示しない
　３．新規投稿　←　投稿や固定ページ
　４．投稿更新　←　投稿や固定ページ
　５．Gzip　←　サーバーから送信されるファイルサイズを減らす。
　６．プラウザキャッシュ　←　リピート訪問者のページ読み込みのサイズを減らす。

※ 投稿や固定ページを更新したあとは、キャッシュを削除をすることで対応する。尚、今のところ問題ないが、不都合が生じる場合の対応も WordPress の .htaccess で修正できるようだ。

投稿日:

「まる」と祐天寺で初参り

昨日はサーバのバージョンアップが一段落したので、午後の散歩を「祐天寺でお参りしよう」となって出かけた。暖かい日差し☀の中を出かけ「まる」はルンルンと歩くのでいつもより快適な散歩になった。

境内はまだお祝い気分かと思いきや、お参りする人は疎らで調子抜けの気分、とにか本堂でお参りを済ませてから境内を散策して爽やかな気分で帰宅。

投稿日:

MariaDB10.4.32からMariaDB10.6.10にアップグレード

一連の作業を振り返ると只々無駄な時間を費やした感じだ、とは言っても定かではないが、ヒントと言うか原因が少なからず分かってきたので、最終的に順序だてた手順でアップグレードできたようだ。

作業を始める前の準備で、既存の WordPress の管理画面から Plugins にある WP-Optimize を削除、Apache、Mysql と XAMPP control-panelを閉じて Mysqlフォルダ内にある wp_wp_404_detector と wp_wpo_404_detector.fm と wp_wpo_404_detector.ibd をさがして削除又は backup フォルダに移動。次に、/xampp/mysql フォルダを mysql_old などにリネームしてバックアップ。PC の再起動！

アップグレードの手順
① 新しい MariaDB10.6.10 を MariaDB サイトからダウンロードして XAMPP フォルダに解凍、「Mysql」 とリネームして配置。
　Mysql_10.4 のフォルダから
　　　/backup
　　　/bin/my.ini
　　　/data
　　　/scripts
　　　Mysql_installservice.bat
　　　mysql_uninstallservice.bat
　　　resetroot.bat
　　を mysql フォルダにコピー
② xampp の MySQL を start すると、エラーになるので data 配下のファイル、フォルダを削除して、再度コピーし直す。
　　　backup/mysql
　　　backup/performance_schema
　　　backup/phpmyadmin
尚、data 内の ib_logfile0、ib_logfile1、ibdata1 を Mysql を起動させるために別フォルダーに移動。
③ 起動した後にパネル右にある「shell」をクリックして mysql を upgrade.
　　　mysql_upgrade -u root -p
④ /bin/my.iniを開いて [mysqld] 内にinnodb_force_recovery = 1 追記
innodb_force_recovery のみで起動しない場合 innodb_purge_threads を追加。
⑤ mysql を起動させてエラーチェック、すると ib_logfile0 と ibdata1 が無いと警告がでるので、移動させた ib_logfile0 と ibdata1 を data の中に入れる。

＊ 上記の手順で Mysql が起動したのでビックリ！一旦 STOP して、最後に Apache と mysql を起動後、phpMyAdmin で確認、及び WordPress の Login で確認して無事完了した。

※ MySQLのエラーを確認する中で、“Goast Table” があり、調べると WordPress のプラグイン WP-Optimize の「テーブルの最適化」とダブって MySQL の データテーブルがダブルの操作状態になり「使用中」と表示が出てエラーとなるのが原因？らしい。

投稿日:

phpMyAdmin5.2.1をphpMyAdmin5.2.3（最新）へアップグレード

ダウンロードした Zipファイルを解凍し、中身を XAMPPの phpmyadmin フォルダ（/xampp/phpmyadmin）に置き換えて、新しいフォルダには config.sample.inc.php があるので、これを config.inc.php にリネームして、中身が旧来のものと同じになるよう設定する。

① MySQL、phpoMyAdmin、XAMPP　などが稼働していたら全部停止する。
② これまで使っていた「phpMyAdmin」フォルダ名を適宜変更　→　phpMyAdmin_old
③ phpMyAdmin 公式サイトから最新版をDL（ダウンロード）し、XAMPP　ディレクトリに解凍して「phpMyAdmin」に変更。
④ 旧「phpMyAdmin」フォルダにある「config.inc.php」を新「phpMyAdmin」フォルダにコピペするか、新「phpMyAdmin」フォルダにある「config.sample.inc.php」をテキストエディタで開き、書き直した後に保存する。

/* Authentication type */
$cfg[‘Servers’][$i][‘host’] = ‘localhost’;
$cfg[‘Servers’][$i][‘compress’] = false;
$cfg[‘Servers’][$i][‘AllowNoPassword’] = false;　⇐　trueに変更
/* User used to manipulate with storage */
$cfg[‘Servers’][$i][‘auth_type’] = ‘cookie’;
$cfg[‘Servers’][$i][‘user’] = ‘root’;
$cfg[‘Servers’][$i][‘password’] = ‘password’;
$cfg[‘Servers’][$i][‘extension’] = ‘mysqli’;
$cfg[‘Servers’][$i][‘AllowNoPassword’] = true;
$cfg[‘Lang’] = ”;
/* Advanced phpMyAdmin features */
＊ 以下全てコメントアウト

※ブラウザでphpMyAdmin（例: http:/localhost/phpmyadmin ）にアクセスし、正しく動作するか、バージョンが更新されているかを確認して終了。

投稿日:

新たに非公式の PHP8.3 の Imagick を PHP に設置

WordPressでの Imagick は必ずしも必須では無いので設置するのを迷ったけど、GitHub 上に 非公式のビルド PHP 8.2 と PHP 8.3 用があり、PHP 8.3 をインストールして試すことにした。

ImageMagickの設置方法
① ダウンロードしたImagickをXAMPP の「php フォルダ」内で解凍。
　”/xampp/php/ext/php_imagick-3.7.0-8.3-ts-vs16-x64″ ⇒ imagickに修正
② 環境変数は「設定＞システム＞詳細情報＞システムの詳細設定＞環境変数」へ PHP 拡張用の DLL（php_imagick.dll）から ImageMagic 本体用の DLL を読み込めるようにするため PATH を通す。
③ imagick のパッケージの中にある PHP 拡張用の DLL（phpimagick_ts_v16.dllを php_imagick.dll に修正）を、 XAMPP の PHP の ext ディレクトリ（”/xampp/php/ext”）にコピー。
④ 次に、ext ディレクトリに追加した “php_imagick.dll” ファイルを PHP が読み込むように php.ini ファイル（例：”/xampp/php/php.ini”） に追記し、Apache を再起動。
php.ini： extension=imagickでなく extension=php_imagick.dllと正式名で追記。
＊ phpinfo() を表示し、imagick の項目が表示されていればインストール完了。

※ ImageMagic 本体用の DLL と PHP 拡張用の DLL の両方のインストールが完了していなければ表示されない。

TOP

Copyrighted Image