Luxeritas 3.2.1 リリース

2018年6月28日

Luxeritas 3.2.1 をリリースしました。

外観カスタマイズで文字種に Web Font を選択してると AMP でエラーが出る不具合修正。

ver 3.1.2 から比較的長期に渡ってダウングレードしてた模様。ごめん。

改訂履歴

不具合修正

外観カスタマイズで文字種に Web Font を選択してると AMP でエラーが出ちゃう不具合の修正

リリース情報

Posted by るな

Luxeritas 3.2.2 リリース

Luxeritas 3.2.0.1 リリース（PWA 不具合修正）

コメント一覧

すみより:
2018年6月29日 18:40
るな様
いつもお世話になっております。
この度、マルチサイトにすべく作業をしているのですが、.htaccessの記述についてご質問があります。
（ルクセリタスに直接関わる質問ではないため、不適切な内容だった場合は申し訳ございません・・。スルーして下さい。）
■.htaccessの記述について下記を追記してくれとあるのですが、既に存在する記述をどのように扱えば良いでしょうか。
・追記する記述———————————–
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
# add a trailing slash to /wp-admin
RewriteRule ^wp-admin$ wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^(.*\.php)$ $1 [L]
RewriteRule . index.php [L]
————————————————–
・既にある記述———————————–
# BEGIN Redirect to https
RewriteEngine On
RewriteCond %{ENV:HTTPS} !on
RewriteCond %{HTTP:X-Forwarded-Proto} http
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# END Redirect to https
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
～以下ルクセリタスの追記分～
————————————————–
以上です。よろしくおねがいします。
返信
- るなより:
  2018年6月29日 18:59
  すみさん。
  本来 Luxeritas と関係ない質問は答えないんだけど、特別サービス。
  # BEGIN WordPress と # END WordPress で囲まれてる部分を消して、新しいやつに書き換える。
  WordPress に関する質問は、WordPree のフォーラムで聞いてください。
  返信
  - すみより:
    2018年6月30日 18:06
    特別サービス、ありがとうございます！
    無事解決いたしました。今後はWPフォーラムで質問いたします。失礼いたしました。
    余談ですが、「特別サービス」好きな言葉です。
    返信
よねだより:
2018年6月29日 08:44
るな様
迅速丁寧な対応ありがとうございます。
アップデートを待ちます。
それでもうまくいかないようなWordpressアドレスの変更を検討してみます。
返信
よねだより:
2018年6月28日 17:02
連日の修正、お疲れ様です。
PWAのマニフェストの修正ありがとうございます。
PWAは有効になったのですが、オフラインでの閲覧がうまくいきません。
Lighthouseでチェックしてみたところ
ステータスコード200がオフライン時に返ってきてないようです。
当方、キャッシュ系プラグインを使っていません。
お手数ですが確認していただくことは出来ませんか？
返信
- るなより:
  2018年6月28日 17:35
  よねださん。
  Service Workers は登録されて、Service Workers 本体はキャッシュされてるけどページの方がキャッシュされてないっすねぇ。
  Service Workers が動いてるので速度は向上してるけどね。
  現状「WordPress アドレス」と「サイトアドレス」が異なってる場合「WordPress アドレス」の直下に Service Workers を置かざるを得ない状況だけど、「サイトアドレス」の直下じゃないとダメなのかな？
  だとしたら、結構、難しいｗ
  当方のテストサイトに「WordPress アドレス」と「サイトアドレス」が異なる環境ってのが無いので、検証するためには、まずこの環境を作らないといけない。
  なので、検証するのに、ちょっと時間かかる。
  とりあえず、オフラインができないってだけなので、とりあえずそのまま運用してください。
  返信
  - るなより:
    2018年6月28日 17:43
    あ、
    マニフェストに scope を定義すれば、Service Workers が WordPress アドレス」の直下でもイケるかも？
    どっちにしても検証環境作ってからじゃないと確認できないけど。
    返信
    - るなより:
      2018年6月28日 21:20
      よねださん。
      Service Workers の仕様書によると、Service Workers のスコープの最大範囲はマニフェストファイルの位置から下らしい。
      なので、「WordPress アドレス」と「サイトアドレス」が異なってる状態で「WordPress アドレス」が「サイトアドレス」のスコープ範囲外にあると無理ｗ
      一応、がんばってマニフェストを「サイトアドレス」直下に作っちゃうようにしてみた。
      よほど特殊なリダイレクト環境とかシンボリックリンクとかじゃなければイケる。
      「サイトアドレス」直下にファイルが作れないようなら、管理画面で「無理でーす」っていうメッセージ出すようにした。
      明後日くらいにリリースする。
      返信

コメントする