適当なところで、masterにsp1タグうつほうがいいかも
了解です、3.8リリースと同時くらいで整理します
PHP5.3は国内では2020年11月頃まで続きそうな気配がありますが、開発版のほうはどんどん上げてしまってもよさそうな気がします。古いサーバで仕方なく使われ続けるのもプロダクトとしては寂しいですし、、
ブランチを分けてPHP5.3のサポートを続けていくのはアリかな?と思います。
オフライン
確認しました。ありがとうございます。
よろしくお願いします。
オフライン
PHP5.3は国内では2020年11月頃まで続きそうな気配がありますが、開発版のほうはどんどん上げてしまってもよさそうな気がします。古いサーバで仕方なく使われ続けるのもプロダクトとしては寂しいですし、、
ブランチを分けてPHP5.3のサポートを続けていくのはアリかな?と思います。
cent os6でしょうか。化石みたいなサーバーがあるのですね
面倒なのでv3.8は 現状維持にしましょ。
v3.8dev [3.80(-3.89)]
・最低バージョン: PHP 5.0.5 (現状維持)
・最低バージョン: mysql 5.0 (現状維持)
・3.80リリース後の機能の追加などは、なるべく避け、Fixと簡単な変更にとどめる。
v3.9dev [3.90(-3.99)]
・v3.80リリース後に v3.9dev ブランチを作成
・最低バージョン: 様子を見ながら検討する (予定 PHP5.3 or 5.4)
(PHP5.0.5-5.2で使う場合は、v3.8 をつかってもらい、v3.9ではサポートしない)
オフライン
v3.8devからv3.80リリースへのアップグレード
v3.8devを(間違って、もしくはリスク承知で)運用していた場合は、
データベース番号だけダウングレードし、アップグレードスクリプトを呼び出す
(これをやってエラーがでる場合は他の原因)
(1) データベース番号のダウングレード
UPDATE nucleus_config SET value='371' WHERE name='DatabaseVersion' AND value='380';
(2) アップグレード
/_upgrades/
オフライン
v3.80devの
設定などの編集後の遷移ページを日本語版に合わせました。
BATCH, NAVLIST, SKINEXPORT, SKINIMPORT クラスは、
・クラスファイルがどこにあるかわからない
・autoloadできない
の理由から
同梱してあったファイルから取り出しました。
オフライン
RC4です。アップグレード用のパッケージのほうは、アップグレード処理を整理しました。
分かりやすくなっていると思うので、プログラミングができる人は見ていただければと思います。
これまでリリースされたパッケージのアップグレード処理自体の不具合のため、
アップグレードがうまくいってないケースがよくあるみたいです。
最終的にそのへんの処理をもう少し工夫して正式リリースしたいと思います。
オフライン
本家版のリポジトリに Nucleus-3-70 のタグがないようです
たぶんこのあたりではないかと思います。
commit 280d634c1e43fd7ad839b9b3e73d515e4ce42024
Date: 2014-09-21 20:45:05 +0900Update - history.html
オフライン
ありがとうございます、あとで作っておきます
オフライン
/libsのNuclues、Nuclues-jpとの差分は
query関係の差分しか残っていないような感じで機能的にはほぼ同じです。
SKIN.PHPに<%BenchMark%>入っていないようです。どこかにあるのかもしれませんが、わかりません
動作に影響が出そうなもので取り込み忘れは他にはなさそうです。
テンプレートの違いがあるのは無視するとして
使用感はさほど変わらないと思います。
編集者 ピヨピヨbird (2018-05-20 18:37:20)
オフライン
いろいろありがとうございます、おかげさまでNucleus-3-70のタグを作成できました。
3.8をそろそろ正式リリースしてよさそうですが、パッケージに同梱されているフランス語・ドイツ語の
言語ファイルの文字化けがいくつかあるため transifex.com で修正中です。
オフライン
UTF-8ファイルは特殊文字をエスケープする必要性はないので
翻訳するのでしたらhtml特殊文字をデコードして解除したほうがいいと思います
<?php
ini_set('default_charset', 'UTF-8');
$files = array(
'french-utf8.php',
'german-utf8.php'
);
foreach($files as $file) {
if (!is_file($file) || !($s = file_get_contents($file)))
continue;
$s2 = preg_replace_callback('/&([a-z]{2,});/im',
function ($m) {
if (in_array(strtolower($m[1]), array(
'quot','amp','lt','gt',
'nbsp','ensp','emsp','ndash','mdash')))
return $m[0];
return html_entity_decode($m[0], ENT_NOQUOTES, 'UTF-8');
}
, $s);
if ($s2 && (strcmp($s,$s2)!=0))
file_put_contents($file, $s2);
}
オフライン
実用的なコードをありがとうございます。いずれ使えそうなのでストックさせていただきます。
現在はすでにエンコードが壊れた状態になっているため、古いバージョンの言語ファイルから
エントリーを戻しています。今週また時間ができますので、一気に戻しますね。
オランダも熱心なユーザがいるので、できれば同梱したいなと思います。
オフライン
・インストール作業中の防御
Wordpressではインストール作業中の
無セキュリティの
すきを狙ってDBをすり替えてサイト乗っ取りをする攻撃が存在するそうです。
・ファイルだけ転送済ませて、インストール作業をせずにしばらく放置した場合に被害にあうそうです。
Nucleusもこの攻撃には無防備なので
簡易防御には installフォルダに対して
・Basic認証 or Digest認証
・リモートIP 一致
・リモートホスト名 部分一致
などが有効かなと思います
いちいち設定するのも面倒なので
デフォルトで
サーバーホスト名が .jpで終わる場合は
リモートホストは、 (\.jp|\.bbtec\.net)$で終わらないと一律インストールできないようにするのもありかもしれないです
# install/.htaccess , Apache 2.4以降
<If "%{SERVER_NAME} =~ /\.jp$/ || %{SERVER_ADMIN} =~ /\.jp$/">
order deny,allow
deny from all
allow from \.jp
# SoftBank
allow from \.bbtec\.net
</If>
オフライン
かなり時間が経過したため、PHP動作環境が変更になりました。
現時点では以下のようになっています
【動作環境】
NucleusCMS-ja/v3.8dev-ja
PHP 5.3 ~
NucleusCMS/v3.8dev
PHP 5.5 ~
オフライン
> ファイルだけ転送済ませて、インストール作業をせずにしばらく放置した場合に被害にあう
install/index.php のタイムスタンプを見て、一定時間を過ぎていたら
「インストール有効期限を経過しました。installディレクトリをアップロードし直してください」
とかはどうでしょう?完璧ではないですが、ほぼ防御できると思います。
(追記)
かなり昔の投稿ですね、失礼しました・・
オフライン
> install/index.php のタイムスタンプを見て、一定時間を過ぎていたら
「インストール有効期限を経過しました。installディレクトリをアップロードし直してください」
とかはどうでしょう?完璧ではないですが、ほぼ防御できると思います。
(追記)
かなり昔の投稿ですね、失礼しました・・
v3.80devに インストールの有効期限を 追加しました。
v3.80dev-jaには、次の修正をする際に入れておこうと思います。
v3.80dev
落ち着いたので、今回のインストールの有効期限のコミットで修正最後になります。
コード整形
PHP_CodeSniffer(phpcbf)でコード整形すると遅くて失敗するものがあるので ADMIN.phpなど
php-cs-fixer に変更しました。
v3.80devに設定ファイルいれています。他のdevにも必要に応じて入れます。
・SQLite
最近の他のCMSにはSQLite対応品があるため
Nucleusで新規でわざわざSQLiteを選ぶメリットがないので
SQLiteは、標準のインストールでは表示されないように変更しました。
・CONFクラス
コードを書くたびにglobal $CONFだのissetやらtrimとか考えるのが面倒なので
エディタの補完機能で考えないでいいように追加しました。
v3.80dev にお試しで追加したのですが、
v3.80dev-ja は下限が PHP5.3のため適用できないので利用できません。
編集者 ピヨピヨbird (2022-08-28 16:26:02)
オフライン
いろいろありがとうございます。v3.8の正式リリースがずっと延び延びになってますが、
そろそろいいのかなと思ってます。タイミングよさそうな時があれば教えていただければ。
リリースノート、全部は書ききれないかもですね、、
オフライン
いろいろありがとうございます。v3.8の正式リリースがずっと延び延びになってますが、
そろそろいいのかなと思ってます。タイミングよさそうな時があれば教えていただければ。
リリースノート、全部は書ききれないかもですね、、
いえいえ。
お疲れ様です。
リリースについて
期限をもうけて他の方の意見をもらって
何もなければリリースでいいのではないでしょうか?
懸念事項として リリースすると セキュリティ魔がやってきて
アイテム記事内で jsが動くやら、クロスサイトスクリプティングだの騒ぎだすので
リリース形態はとらずに
最新版はブランチからどうぞで ひっそりやるのもありだと思います。
オフライン
9/1のコミットで
ブログ表示の際にイベント発生前に標準アイテム内のスクリプトとhtmlタグを制限するため BLOG.phpに変更を加えましたので
RCで 不具合がでないか様子を見てください。
同じ修正を加えたmasterの枝と一度結合しましたので
リリースブランチを masterにマージする際は、競合は発生しないと思います。
v3.80で既存のコンテンツ(body,more)で以前と同じ動作(スクリプト、on~イベント)が必要な場合は、
config.php 内で DISABLED_BLOG_CLEANITEMS 定数を true になるような値で定義してください
オフライン
数日前の状態でローカル環境で試しにmasterにマージしてみたらコンフリクトしまして・・
修正するには難しい量だったので、深く考えず、今のmasterを削除してリリースブランチを
新しいmasterにしようかな?と考えてました。後ほど、既存のプルリクをひととおり
反映した上でマージを試してみますね。
あまり大きなニュースにしない感じで、いったんリリースしたいな~と思います。
オフライン
数日前の状態でローカル環境で試しにmasterにマージしてみたらコンフリクトしまして・・
修正するには難しい量だったので、深く考えず、今のmasterを削除してリリースブランチを
新しいmasterにしようかな?と考えてました。
masterへのマージ手順
(1) コマンド : masterで行われた修正はいらないので v3.8dev を優先します
git merge --no-commit --no-ff -X theirs v3.8dev
(2) TortoiseGit 競合を解決 : 移動などで削除されていないファイルを削除を選択します
(3) TortoiseGit リビジョングラフ,refブラウザ :v3.8dev : 右クリック [作業ツリーと比較]
で同じか確認します。 変更が残っていればクリックして 変更部分を確認し、取り消しなどして 保存します。
(4) コミットします
(5) 確認: v3.8devと比較して完了です
編集者 ピヨピヨbird (2022-09-03 19:31:40)
オフライン
手作業で解決を試みようと思ってましたが、こういう方法があるんですね、、
いちおうドキュメント開いて理解してから試してみます!
オフライン
ソースコードを見た感じ、get_where_phrase()メソッドや変数名$resと$rsの混同とか、
SEARCH.phpがバグっぽい感じです。連休中に時間があれば見てみますが、
もし余裕があれば確認いただけると助かります~
オフライン
TortoiseGit の解説追記ありがとうございます。すでにコンフリクトは解消しているようですが、
また機会があればこれを参考にしてみますね
オフライン