私からもタブプラグインの導入を強く希望します。 例えばこちらのようなプラグインを導入して頂くことは可能でしょうか。
iOS15は以下の理由で切り捨てても良いと思います。
ご対応よろしくお願いします。
認証のない書き込みは制限をカットしてほしい
失礼いたしました。開発中だった機能が誤って反映されてしまったため、修正いたしました。上記の機能はございません。「管理者コンタクト」の内容の入力は「コントロールパネル」でのみ行え、表示は「お手紙アイコン」でのみ確認できます。事情によりプレーンテキスト形式を採用しております。混乱させてしまい申し訳ございません。
参考までに、現在同様の役割を担っているページと同じ内容を記載した際のスクリーンショットを添付します。
対応ありがとうございます 画像が表示されるようになりました
画像の表示が変になり、添付 のページを開き画像ファイルを開くとデータが壊れていますと表示される 自分の管理しているwikiも初めて開いたwikiも同じ現象でした
簡体中国語においても日本語のフォントと中国語のフォントが混ざって崩れてしまっているので、同様にzh-CNで正常に表示できると思います。恐らくアルファベットに近い文字の言語でも同様にことが起きているんじゃないかと思います。
すみません一時的な不具合だったようです直りました。
こちらの事と同じ症状で 今日作成したページに画像を複数アップロードしましたが画像が表示されません。 https://wikiwiki.jp/torays/-s/ab2e33f0
こちら解決したため、原因や対処法の事後報告を追記した上でクローズします。
確認遅くなりました。回答ありがとうございます。
指摘を受け、Windowsにインストールされているフォントを見直した所、なぜか「ヒラギノ角ゴ ProN」の「W6」のみがインストールされ、「W3」が無い状態でした。それによって、W6（太字）で固定になっていた可能性が高いです。 Adobe Creative Cloudから確認し、「W3」をインストールした所、画像の通りW3とW6が使い分けられている事を確認しました。
個別環境の問題についてご指摘頂きありがとうございました。
少し前までは正常に収納されていました。
>> 1 ありがとうございました。
管理メニューからタグの再構築というのがあるので、それを試してみたらいいと思います。 ページ名に変な記号が入ってるので上手く消せないのでしょう。 類似の話題
とりあえず確認することとして
フォトンのインストール状態の確認
ヒラギノ角ゴシックProNは自分の環境には無いので確認できませんが、 Adobe Creative Cloudで検索すると以下がインストールされるようです。 ヒラギノ角ゴ ProN W3 ヒラギノ角ゴ ProN W6 W3が通常でW6が太字のようです。 ここを見ると W3がWeihgt:300でW6が600。wikiwikiの標準が400で太字が700のようなので、このへんのアンマッチが関係ありそうな気もしますが そもそも従来からMacはそれで表示できているのだろうし、 font-weightの代替え規則みると辻褄は合わせてくれそうだし、 個別の問題のような気も。
#tablescroll(){{}}の内容にテーブル書式以外が含まれるとErrorになるようです。 普通にテーブル書式の部分だけ囲めば使えます。 Include呼び出しで展開するまえにチェックが入るのでしょう。 以前がどうだったか覚えてませんが。
Includeの参照元のページで元からtablescrollで囲っておけば、それは機能します。 ただ、includeを使ってページによってtablescrollのオプションを変更したり、 そもそも元ページではtablescrollを使いたくないなど、自由度が下がりますね。
現状では以下のようにOGPが設定されています。
<meta property="og:title" content="崩壊3rd Wiki*"> <meta property="og:description" content="このWikiでは、miHoYoが開発しHoYoverseにより運営・配信されている基本無料オンラインゲームである『崩壊3rd』の攻略や情報を扱っています。"> <meta property="og:site_name" content="崩壊3rd Wiki*"> <meta property="og:image" content="https://icon.wikiwiki.jp/symbolicon/houkai/ogCustomImage/5da270c435d5.png"> <title>隕星-グアイマス - 崩壊3rd Wiki*</title>
og:site_nameですでにサイト名は記載されているので、og:titleについてはtitleと同じように「ページ名 - サイト名」を挿入するようにして欲しいです。 og:descriptionやog:imageについては、現状では対応が難しいと思います。ただ、新たにプラグインを追加してそれでできるように対応を検討して欲しいです。例えば、#ogdescriptionというのを作り、#ogdescription(説明)という形でページ内に明記することが考えられます。og:imageについても添付ファイルを参照する形にすれば可能だと思えます。 どうぞよろしくお願いします。
いやCENTER:MIDDLE:って感じで両方入れればいいんよ それぞれ横と縦と役割がハッキリ決まってるから両方揃えたかったら両方指定する必要があるわけ
MIDDLEだと横方向にセンタリングされないのでCENTERであってると思います。 https://wikiwiki.jp/sample/表組み
解消済みなのを確認したためクローズしました。
記入ミスかもしれませんが、表組みの上下中央揃えはMIDDLE:ではないですか？
ありがとうございます。 wikiwikiのManualにはファイル名未指定に関する記述がなかったため見逃してました。 「attachref+未指定=注意文非表示」「ref+未指定=注意文表示」となりました。 解決済みとさせていただきます。
やはり症状が改善されていません。本日、設置_喫茶ブレンド物語と引き継ぎ_喫茶ブレンド物語を同じ方が編集を行い、後者の編集分が現時点では、TOPページやカイロソフト 攻略一覧 新作順、創作♪パティシエ部_Bonbon Cakeryなどの一部ページでは反映されていません。 喫茶ブレンド物語_Cafe Master Storyや箱庭タウンズ_Dream Town Storyなどは反映されています。
トピックを建てる前までに視認していない不具合が度々、起きています。各MenuBarページにecacheプラグインを設置したのはバックアップページを参照すると2ヶ月も前で、このような症状は起きておりませんでした。改善をお願いします。
>まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。 イメージつきにくい感じですかね、例えばまとめページは以下のような感じで500近いキャラがいます。（本来はflex_box間のmargin消すためにcssbox使ってるから更に入れ子になってます） これを「図鑑順」に並べたいページと「種類・レア別(図鑑No表示は省く)」に分けたいページに使います。
https://wikiwiki.jp/～～/まとめページ #flex_container{{ #flex_box{{ |~図鑑No.001|h |剣士★5～&ref(キャラ画像.png);～キャラ名| }} #flex_box{{ |~図鑑No.002|h |剣士★4～&ref(キャラ画像.png);～キャラ名| }} #flex_box{{ |~図鑑No.003|h |魔術師★5～&ref(キャラ画像.png);～キャラ名| }} #flex_box{{ |~図鑑No.004|h |弓師★5～&ref(キャラ画像.png);～キャラ名| }} #flex_box{{ |~図鑑No.005|h |剣士★5～&ref(キャラ画像.png);～キャラ名| }} : }}}
で、includexで呼び出す側にflexやcss持っていくと、ていうのはまず難しいかと。抽出したデータの間に入れるとか(replace的な仕組みがあれば)、「図鑑順」「種類・レア別」用に分けたまとめページを作れば可能かもしれませんが。。。
ここまで書きましたが、#nullで試行錯誤し、なんとかまとめページ側を改良する(もちろんflex_box/cssboxはそのまま)ことで求めていた結果になったのでこの件問題なしとさせていただきます。 ※改良後：HTMLデータ量＝900kbぐらい。複雑化しすぎたせいで本文コストが3000ms近いけど、ecacheのおかげか実測全体は100ms切ってるので良しとします。
状況がよくわからないです。 例えば以下
結果的に{{}}の間に何もないcssbox/flex_boxが大量に残り、それに比例してHTMLタグが大量に作成されます
まとめページの容量が膨れ上がると言ってるのですか。 cssやflexで記述した結果が不正に大容量で出力されるわけではないですよね。 書いたとおりに出力された結果なら仕方ないと思います。 求めてる機能はcssやflexにとって何も意味がないのではないでしょうか。 includexで活用するためにcssやflex側を対応するのは本末転倒だと思います。 includexの使い方を工夫するか、まとめページの書き方を工夫してみたらどうですか。 まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
存在しないファイルを指定するからそうなるので、未指定にすればいいです。 attachrefは添付するファイルを後から指定できる機能です。 以下のように先頭を未指定にします。リンクをクリックすれば添付できます。
&attachref(,nolink,zoom,150x150){■};
ご助言ありがとうございます。各製品/MenuBarページはそのようにすると反映されなくなったので、 MenuBarページだけをそのように適用して様子見してみようと思います。
自分でも詳しく調べてみて、こちらに記載している下記の内容と助言頂いた内容が合致して理にかなっているので、納得しました。
page=ページ名 キャッシュを区別するページ名。デフォルトではカレントページ。MenuBarなど、他のページの一部として動作するページ内に設置する場合に page=MenuBar のように設定します。
>> 2で示したWikiWiki公式の説明では
キャッシュを区別するページ名。デフォルトではカレントページ。MenuBar に設置する場合に page=MenuBar とするためのようなもの。
とあるので、カレントページに関する認識がおそらく違うのではないかと‥‥ MenuBarが常にカレントページであるならこのpage=MenuBarの説明は書かれていないでしょう。 MenuBarページ自体を開かなければ、MenuBarはカレントページにならないはずです。
少なくともWikiWiki公式からピンポイントで page=MenuBar という一例が示されている以上、指定して損は無いかと思います。
すみません、紛らわしかったようなので書きかえておきます。 &refと&attachrefで注意文が若干異なりますが、両方でそうなります。
回答ありがとうございます。ecacheプラグイン周辺の記述はどのページにおいても、ここ最近は変更していないので運営サイドのメンテナンスが行われた挙動変更によるものと考えています。
ためしがき/echcheテストによれば、
page=ページ名 キャッシュを区別するページ名。デフォルトではカレントページ。MenuBar に設置する場合に page=MenuBar とするためのようなもの。
オプション指定がない場合はecacheプラグインを置いているページのキャッシュを参照する。つまりページをまるごとecacheプラグインで囲むような場合はpage指定が不要。
とあり、各ページのecacheの対象はMenuBarページも含めてカレントページのため、特に変更せずにこれまで通りで良いと考えております。
今回のように、見るページによって編集履歴内容が違い、ひどいページだと1日以上もの更新が滞るような問題は今までに発生してきませんでした。(ecache時間指定3601秒をしているため)もし、仕様変更がなされたのであれば、運営より具体的にどのようにすべきなのかアナウンスがほしいところです。
関係しているか分かりませんが、ecacheの引数にpage指定が無いのが気になりました。 もしかするとpage指定が無いことで各ページごとにMenuBarのキャッシュが作られているのかもしれません。
https://zawazawa.jp/wikiwiki/topic/8#ecacheプラグイン こちらの説明を読む限りでは、下記のようにしてキャッシュ先にMenuBarを指定してあげる必要があります。
#ecache(reset=3601,page=MenuBar){{{
MenuBarを編集したところ、反映されるようになりました。
編集内容 #includex(others/strategy-simple-list,num=9:13,titlestr=off,firsthead=off) ↓ #includex(others/strategy-simple-list,num=8:12,titlestr=off,firsthead=off)
なぜ、各ページの表示不備が治ったのか不明です。意図せず原因不明のまま自己解決しましたが、今後も再発するおそれがあるため「解決済」タグは付けずにしておきます。
refの話ですか。タイトルのattachrefでそうなりますか。
このように書くと少しだけの空白ができます、こちらを使ってみるのはどうでしょうか
-ほげほげ ほげほげ ~ほげほげ (この上に空白ができる)
#table_editに関してトピック作成しようと思って検索したらヒットしたのでこちらに。
現在の書式では、主に以下の理由から利用しないまたはできない事があります。
上でも書かれていますが、とりあえず以下のような記述ができるだけでもかなり助かります。
#table_edit{{ 表 }}
編集の手間や敷居を下げるための書式なのに、使いづらくてそもそも利用されないのは本末転倒だと思います。
その他の要望として、#table_editの個別編集画面で表示される列の項目(表の1行目)に改行の書式「&br;」を適用しないようにしていただきたいです。 表の横幅の都合で「&br;」を利用してるだけなので、個別編集画面にも適用させて視認性を悪化させるのは避けて欲しいです。
プラグインの導入をご検討いただきありがとうございます。
表示について気になる点がありますのでご連絡いたします。
表の上段はＨ&br;Ｐというような形でbrプラグインを用い無理やり縦書きにしたもの、 下段は&tategaki{ＨＰ};というような形で本tategakiプラグインを用い縦書きにしたものです。 下段の縦書き部分が若干右寄せになっており、可能であれば修正していただきたいです。
当環境はgoogle pixel 6a/android ver.14で、ME edge 123.0.2420.61とChrome 123.0.6312.80の2つのブラウザで上記のような表示になることを確認しています。
項目の行でも2行以上の結合があっても同事象が起こります。
先頭列が上下で結合して2列目から結合していない場合
2列目まで上下で結合して3列目から結合していない場合
更に続報です。先月末リリースのEdge 121にて正式対応しました。（現在は後続の122がリリースされています） https://forest.watch.impress.co.jp/docs/news/1564032.html
残る懸念はiOS 15のみとなります。
私からもタブプラグインの導入を強く希望します。
例えばこちらのようなプラグインを導入して頂くことは可能でしょうか。
iOS15は以下の理由で切り捨てても良いと思います。
ご対応よろしくお願いします。
認証のない書き込みは制限をカットしてほしい
失礼いたしました。開発中だった機能が誤って反映されてしまったため、修正いたしました。上記の機能はございません。「管理者コンタクト」の内容の入力は「コントロールパネル」でのみ行え、表示は「お手紙アイコン」でのみ確認できます。事情によりプレーンテキスト形式を採用しております。混乱させてしまい申し訳ございません。
参考までに、現在同様の役割を担っているページと同じ内容を記載した際のスクリーンショットを添付します。
対応ありがとうございます
画像が表示されるようになりました
画像の表示が変になり、添付 のページを開き画像ファイルを開くとデータが壊れていますと表示される
自分の管理しているwikiも初めて開いたwikiも同じ現象でした
簡体中国語においても日本語のフォントと中国語のフォントが混ざって崩れてしまっているので、同様にzh-CNで正常に表示できると思います。恐らくアルファベットに近い文字の言語でも同様にことが起きているんじゃないかと思います。
すみません一時的な不具合だったようです直りました。
こちらの事と同じ症状で
今日作成したページに画像を複数アップロードしましたが画像が表示されません。
https://wikiwiki.jp/torays/-s/ab2e33f0
こちら解決したため、原因や対処法の事後報告を追記した上でクローズします。
確認遅くなりました。回答ありがとうございます。
指摘を受け、Windowsにインストールされているフォントを見直した所、なぜか「ヒラギノ角ゴ ProN」の「W6」のみがインストールされ、「W3」が無い状態でした。それによって、W6（太字）で固定になっていた可能性が高いです。
Adobe Creative Cloudから確認し、「W3」をインストールした所、画像の通りW3とW6が使い分けられている事を確認しました。
個別環境の問題についてご指摘頂きありがとうございました。
少し前までは正常に収納されていました。
>> 1
ありがとうございました。
>> 1
ありがとうございました。
管理メニューからタグの再構築というのがあるので、それを試してみたらいいと思います。
ページ名に変な記号が入ってるので上手く消せないのでしょう。
類似の話題
とりあえず確認することとして
フォトンのインストール状態の確認
既存の他のフォントをみるとわかりますが、一つのフォントにWeightが複数割り当てられてれば2フォントフェイスとか表示されます。さらにプレビューで適当な文字列をいれればそれぞれ表示されます。
ヒラギノ角ゴシックProNは自分の環境には無いので確認できませんが、
Adobe Creative Cloudで検索すると以下がインストールされるようです。
ヒラギノ角ゴ ProN W3
ヒラギノ角ゴ ProN W6
W3が通常でW6が太字のようです。
ここを見ると
W3がWeihgt:300でW6が600。wikiwikiの標準が400で太字が700のようなので、このへんのアンマッチが関係ありそうな気もしますが
そもそも従来からMacはそれで表示できているのだろうし、
font-weightの代替え規則みると辻褄は合わせてくれそうだし、
個別の問題のような気も。
#tablescroll(){{}}の内容にテーブル書式以外が含まれるとErrorになるようです。
普通にテーブル書式の部分だけ囲めば使えます。
Include呼び出しで展開するまえにチェックが入るのでしょう。
以前がどうだったか覚えてませんが。
Includeの参照元のページで元からtablescrollで囲っておけば、それは機能します。
ただ、includeを使ってページによってtablescrollのオプションを変更したり、
そもそも元ページではtablescrollを使いたくないなど、自由度が下がりますね。
現状では以下のようにOGPが設定されています。
og:site_nameですでにサイト名は記載されているので、og:titleについてはtitleと同じように「ページ名 - サイト名」を挿入するようにして欲しいです。
og:descriptionやog:imageについては、現状では対応が難しいと思います。ただ、新たにプラグインを追加してそれでできるように対応を検討して欲しいです。例えば、#ogdescriptionというのを作り、#ogdescription(説明)という形でページ内に明記することが考えられます。og:imageについても添付ファイルを参照する形にすれば可能だと思えます。
どうぞよろしくお願いします。
いやCENTER:MIDDLE:って感じで両方入れればいいんよ
それぞれ横と縦と役割がハッキリ決まってるから両方揃えたかったら両方指定する必要があるわけ
MIDDLEだと横方向にセンタリングされないのでCENTERであってると思います。
https://wikiwiki.jp/sample/表組み
解消済みなのを確認したためクローズしました。
記入ミスかもしれませんが、表組みの上下中央揃えはMIDDLE:ではないですか？
ありがとうございます。
wikiwikiのManualにはファイル名未指定に関する記述がなかったため見逃してました。
「attachref+未指定=注意文非表示」「ref+未指定=注意文表示」となりました。
解決済みとさせていただきます。
やはり症状が改善されていません。本日、設置_喫茶ブレンド物語と引き継ぎ_喫茶ブレンド物語を同じ方が編集を行い、後者の編集分が現時点では、TOPページやカイロソフト 攻略一覧 新作順、創作♪パティシエ部_Bonbon Cakeryなどの一部ページでは反映されていません。
喫茶ブレンド物語_Cafe Master Storyや箱庭タウンズ_Dream Town Storyなどは反映されています。
トピックを建てる前までに視認していない不具合が度々、起きています。各MenuBarページにecacheプラグインを設置したのはバックアップページを参照すると2ヶ月も前で、このような症状は起きておりませんでした。改善をお願いします。
>まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
イメージつきにくい感じですかね、例えばまとめページは以下のような感じで500近いキャラがいます。（本来はflex_box間のmargin消すためにcssbox使ってるから更に入れ子になってます）
これを「図鑑順」に並べたいページと「種類・レア別(図鑑No表示は省く)」に分けたいページに使います。
で、includexで呼び出す側にflexやcss持っていくと、ていうのはまず難しいかと。抽出したデータの間に入れるとか(replace的な仕組みがあれば)、「図鑑順」「種類・レア別」用に分けたまとめページを作れば可能かもしれませんが。。。
ここまで書きましたが、#nullで試行錯誤し、なんとかまとめページ側を改良する(もちろんflex_box/cssboxはそのまま)ことで求めていた結果になったのでこの件問題なしとさせていただきます。
※改良後：HTMLデータ量＝900kbぐらい。複雑化しすぎたせいで本文コストが3000ms近いけど、ecacheのおかげか実測全体は100ms切ってるので良しとします。
状況がよくわからないです。
例えば以下
まとめページの容量が膨れ上がると言ってるのですか。
cssやflexで記述した結果が不正に大容量で出力されるわけではないですよね。
書いたとおりに出力された結果なら仕方ないと思います。
求めてる機能はcssやflexにとって何も意味がないのではないでしょうか。
includexで活用するためにcssやflex側を対応するのは本末転倒だと思います。
includexの使い方を工夫するか、まとめページの書き方を工夫してみたらどうですか。
まとめページの方にflexやcssを記述せず、includexで呼び出すほうのページに書いてみたらどうですか。
存在しないファイルを指定するからそうなるので、未指定にすればいいです。
attachrefは添付するファイルを後から指定できる機能です。
以下のように先頭を未指定にします。リンクをクリックすれば添付できます。
ご助言ありがとうございます。各製品/MenuBarページはそのようにすると反映されなくなったので、 MenuBarページだけをそのように適用して様子見してみようと思います。
自分でも詳しく調べてみて、こちらに記載している下記の内容と助言頂いた内容が合致して理にかなっているので、納得しました。
>> 2で示したWikiWiki公式の説明では
とあるので、カレントページに関する認識がおそらく違うのではないかと‥‥
MenuBarが常にカレントページであるならこのpage=MenuBarの説明は書かれていないでしょう。
MenuBarページ自体を開かなければ、MenuBarはカレントページにならないはずです。
少なくともWikiWiki公式からピンポイントで page=MenuBar という一例が示されている以上、指定して損は無いかと思います。
すみません、紛らわしかったようなので書きかえておきます。
&refと&attachrefで注意文が若干異なりますが、両方でそうなります。
回答ありがとうございます。ecacheプラグイン周辺の記述はどのページにおいても、ここ最近は変更していないので運営サイドのメンテナンスが行われた挙動変更によるものと考えています。
ためしがき/echcheテストによれば、
とあり、各ページのecacheの対象はMenuBarページも含めてカレントページのため、特に変更せずにこれまで通りで良いと考えております。
今回のように、見るページによって編集履歴内容が違い、ひどいページだと1日以上もの更新が滞るような問題は今までに発生してきませんでした。(ecache時間指定3601秒をしているため)もし、仕様変更がなされたのであれば、運営より具体的にどのようにすべきなのかアナウンスがほしいところです。
関係しているか分かりませんが、ecacheの引数にpage指定が無いのが気になりました。
もしかするとpage指定が無いことで各ページごとにMenuBarのキャッシュが作られているのかもしれません。
https://zawazawa.jp/wikiwiki/topic/8#ecacheプラグイン
こちらの説明を読む限りでは、下記のようにしてキャッシュ先にMenuBarを指定してあげる必要があります。
MenuBarを編集したところ、反映されるようになりました。
編集内容
#includex(others/strategy-simple-list,num=9:13,titlestr=off,firsthead=off)
↓
#includex(others/strategy-simple-list,num=8:12,titlestr=off,firsthead=off)
なぜ、各ページの表示不備が治ったのか不明です。意図せず原因不明のまま自己解決しましたが、今後も再発するおそれがあるため「解決済」タグは付けずにしておきます。
refの話ですか。タイトルのattachrefでそうなりますか。
このように書くと少しだけの空白ができます、こちらを使ってみるのはどうでしょうか
#table_editに関してトピック作成しようと思って検索したらヒットしたのでこちらに。
現在の書式では、主に以下の理由から利用しないまたはできない事があります。
上でも書かれていますが、とりあえず以下のような記述ができるだけでもかなり助かります。
#table_edit{{
表
}}
編集の手間や敷居を下げるための書式なのに、使いづらくてそもそも利用されないのは本末転倒だと思います。
その他の要望として、#table_editの個別編集画面で表示される列の項目(表の1行目)に改行の書式「&br;」を適用しないようにしていただきたいです。
表の横幅の都合で「&br;」を利用してるだけなので、個別編集画面にも適用させて視認性を悪化させるのは避けて欲しいです。
プラグインの導入をご検討いただきありがとうございます。
表示について気になる点がありますのでご連絡いたします。
表の上段はＨ&br;Ｐというような形でbrプラグインを用い無理やり縦書きにしたもの、
下段は&tategaki{ＨＰ};というような形で本tategakiプラグインを用い縦書きにしたものです。
下段の縦書き部分が若干右寄せになっており、可能であれば修正していただきたいです。
当環境はgoogle pixel 6a/android ver.14で、ME edge 123.0.2420.61とChrome 123.0.6312.80の2つのブラウザで上記のような表示になることを確認しています。
項目の行でも2行以上の結合があっても同事象が起こります。
先頭列が上下で結合して2列目から結合していない場合
2列目まで上下で結合して3列目から結合していない場合
更に続報です。先月末リリースのEdge 121にて正式対応しました。（現在は後続の122がリリースされています）
https://forest.watch.impress.co.jp/docs/news/1564032.html
残る懸念はiOS 15のみとなります。