WEB制作

WEB制作

BlazorでFTPアップしたものの「Loading…」から進まない場合に試したこと

普通のレンタルサーバーで普通に動くBlazorのWebアプリ

拙者みたいな江戸時代から代々Webデザインを家業にしているような中流Webデザイナーからすると、Webブラウザが実行できる唯一のプログラミング言語と言えばJavaScriptのみである。

だから、Webアプリっぽいものを作ろうとすればJavaScriptの上級スキルが必須・・・というのは一昔前の話で、令和5年の現代においてはC言語とかC#とか、おおよそWebサイト制作とは縁が無さそうな言語までがWebブラウザで実行できるような変換技術が開発されているのだ。

それがWebAssemblyという技術である。

Blazor WebAssemblyとは

誤解を恐れずに(99%誤解しているかもしれない)言うと、Blazorはマイクロソフトが開発したC#版のRuby on Railsみたいなものである。

自動的に作られるWebアプリのテンプレート的なものをベースにして、ちょこまかと必要な所をいじれば3分クッキング的にWebアプリが完成するというアレだ。実際には3分では無理だと思うけど、腕に覚えがある人ならば、ちょっとしたWebアプリだったら2~3時間で作れないこともないという。

Blazorには拙者が把握している範囲では、大きく分けて2種類存在している。一つはサーバー上で色々やるタイプの本格的なサーバーサイド型のBlazor Serverだ。これは現在の拙者のテクノロジーレベルでは手が出せないので割愛する。

もう一つが本項で取り上げるBlazor WebAssemblyである。

拙者が思うにBlazor WebAssemblyでは、世界より5年遅れの日本Web界としては現状ほとんど取り上げられていないにも関わらず、Ruby on RailsとかPHPフレームワークのLaravelとかと違って、そのへんの適当なレンタルサーバーにFTPでポンっと上げるだけで動作するWebアプリが作れることである。

本格的なデータベースがどうのこうとなると話は別だと思うけど、外部と通信しないようなタイプのWebアプリだったら、本当にそのへんのレンタルサーバーで普通に動作する驚ぎの技術なのだ。

しかも書いているプログラミング言語はC#っていうのも驚ぎだし、おそらくはJavaScriptに変換されているのかよくわからないけど、実際上、とてもスムーズにWebブラウザで動作するWebアプリが作れるのである。

実際のサンプル制作については、下記の電子書籍を参考とした。

FTPでアップするとハッシュがどうので動かない

Blazor WebAssemblyは中流Webデザイナーの常識を超えた技術であることはすでに述べたが、Visual Studioでサンプルアプリを作ってローカルに書き出してFTPで任意のディレクトリにアップしたところ、「Loading…」という表示で止まってしまう現象に悩まされた。

しかも、Chromeでは普通に動作するのに、FirefoxだけLoading…で停止するという気持ち悪い状態。

まぁ、ChromeはHTMLの記述が間違ってたりしても勝手に直して表示してくれたりするから、厳格なFirefoxだけエラーが出るというのはありがちではあるけど。

integrity 属性内の “sha256” ハッシュが・・・というエラー

途方に暮れても仕方がないので、Firefoxのデベロッパーツールのコンソールを覗いてみると下記のエラーが表示されていた。

「integrity 属性内の “sha256” ハッシュが subresource のコンテンツと一致しません。」

はい、そうですか・・・、としか言えないのが中流Webデザイナーの限界。上級エンジニアみたいな人じゃないと全くわからんですわ。

普通はエラー文言で検索すると解決策のページに引っかかったりするもんだけど、5年遅れの日本ではBlazor人口が少ないので、ほとんど情報が引っかからないという。

1件だけ日本語のページ様が引っかかってバイナリモードで転送を試みるも拙者の環境では改善されなかった。

「所詮は中流Webデザイナーの手に負えるものじゃないな」と諦めて寝ることにした。

解決策は2か所消すだけだった

翌朝、早起きタイプの拙者は午前5時から何気なく検索キーワードを変えて、懲りることなく解決策を探すことにした。

その中で得た情報としては、FTPでアップする前に2か所だけ削除すると良いということであった。似たようなことで困る人は沢山いると思うけど、本当に情報が少ないよ、Blazor君・・・。

解決策はプログラムの知識は関係なく、テキストエディタでローカルに書き出された下記のhtmlとjsonをいじるだけ。

index.html

最初に読み行くファイルである。

head内にある「」の行を削除する。ルートディレクトリ的な処理をしているものだと思われる。

blazor.boot.json

_frameworkディレクトリにある。名前順だったら一番上にあるはず。

このジェイソン君の2行目あたりに
“cacheBootResources”: true,というのがあるので、価をfalseに変える。

つまり正解は
“cacheBootResources”: false,

エラーの原因を推察してみる

中流Webデザイナーの理解には限界があるが、改行コードの問題らしい。

WinSCPを使ってFTPで転送する時にバイナリモードにしたけど、それでもだめだった。FileZillaとか他のFTPソフトだったり、Windows環境なのがダメだとか、MacとかUNIX系だったら問題ないのかしらん。

Blazorに挑戦したいニッチなWebデザイナーの人とかの参考になればと思う。にしても、ChromeとFireFoxでここまで表示に違いが出るのは、さすがWebアプリといったところか。

WEB制作

WordPress5.xや6.x系列の使いづらいGutenberg(グーテンベルク)について嘆いてみる

いつも時代はイージーな方に流れていく。

筆者は何度も仮免試験に落ちながらも必死でマニュアル車の免許を取ったものだが、今の時代、自動車はオートマ車が当たり前。それどころか、自動運転の時代に向かっている。

iPhoneなどスマホが普及したのは、様々なことができる高機能のデバイスという理由もあるが、小学生から生意気盛りの反抗期真っ最中の中高生や、認知症寸前の年寄りまで誰もが使えるくらいに簡単なデバイスだからだ。

裏ではとんでもなく複雑な処理をしていても、それをユーザーに見せないようにしている。昔からのアップルのお家芸だ。

普通にスマホを使ううえで、ITの専門技術や難解なプログラミングの知識が求められることはない。高機能をイージーに落とし込んでいるのである。

同じことはWordPress5.xや6.x系列に採用されているGutenberg(グーテンベルク)という、ワープロソフト感覚で使える初心者向け標準エディターについても言える。

WordPressは一般素人向けにシフトしてきている

WordPress4.x系列以前だと、基本的には記事を投稿するにはHTMLのコードを記述する必要があった。

見出しを書くには実際、企業なんかでは一般人が作成することが多い

全ての企業がそうだとは限らないし、まともな大手企業とかだとWorpressみたいな無料CMSを使っていることはあまりなかったりするものの、有料の他のCMSでも投稿記事を入力する作業はHTMLに精通していない一般人がやっていることが多い。

昔いた職場だと、HTML辞典みたいな入門書を見ながら、記事を書く編集者とかライターとかが、せっせこ入力して「画面が崩れちゃったんですけど、どうしたらいいでしょうか・・・」と半泣きで相談されたりする場面が多かった。

程度問題ではあるが、HTMLで記事を作るというのは、それなりに知識がある人じゃないと難しいのである。

そういった実社会でのCMSの使われ方を考えると、グーテンベルクみたいなグータラ仕様の記事作成画面がデフォルトになるのは理にかなっていると言えるだろう。

なぜグーテンベルクは使いにくいか

世間全般ではWordPressの記事作成というのは、HTMLに詳しくない一般人の方が多いというのはすでに述べた通りである。

ヘッドレスCMSという玄人向けで、欧米で主流の新しいタイプのCMSが日本でも台頭していきている昨今、WordPressみたいな旧式のCMSが生き残るためには多少の犠牲があったとしてもイージーな方向にシフトするしかない。それは拙者も認めるところだ。

グーテンベルクのどこが使いにくいかというと、痒いところに手が届かないところである。

ブロックエディターでブロックとブロックのマージンを調整したいとか、特定のコードを挿入したいとかの場合に難儀する。

「カスタムHTM」と「コードエディター」が救世主?

グーテンベルクでHTMLのコードを書きたい場合、「カスタムHTML」というパーツを呼び出してその中に書くか、初めから「コードエディター」というモードを使うか「クラシックエディター」などのプラグインを導入するかである。

いずれもにしてもオプション扱いであって、メインストリームな機能ではない。近いうちに廃止されたりサポートされなくなったり、不具合が出ても放っとかれる可能性もある。

あと以外と不便なのが、HTMLのコードだったら他のエディターとか出先でスマホとかで作っておいて丸ごと張り付けるだけで済んだものの、グーテンベルクだとログインして画面内で作成しないとならない不便さがある。

・・・ということを別案件でグーテンベルクをいじりながら思ったのであった。

ネットを見ても使いやすいと両手を挙げて絶賛している人は大抵一般人で、ぼそっと使いづらいと嘆いているのは玄人っぽい人という傾向も見て取れる。

WEB制作

Googleアナリティクスの新バージョン「GA4」を導入してみた

アクセス解析の定番とも言えるGoogleアナリティクス。個人でそこそこの熱量でブログなどのサイト運営していたり、業務でWebに関わっている人なら身近な存在、もしくは名前程度は知っている人がほとんどだろう。

業務だと競合で有料のadobeアナリティクスを使っていることも結構あるものの、個人だと無料で使えるGoogleアナリティクスがほとんどだと思う。

そんなGoogleアリティクスだが、従来型のユニバーサルアナリティクスが2023年7月で使えなくなることから、新バージョンであるGA4に切り替える必要が出てきている。

嫌々ながら早速やってみた

今回のバージョンアップでは、アクセス解析のコードを新規に発行してサイトのコードを張り替えたり、Googleアナリティクスの画面で色々いじったりしないとならないのでなかなか難儀だ。

そもそも問題、Googleアナリティクスの画面や仕様はコロコロ変わるので覚えるのが大変なのだが、今回のGA4に至っては進化したのかどうかアクセス解析の専門家じゃない人からしたらよくわからないというのが正直なものの、画面や使い勝手、アクセス解析の内容が大きく変わっているような印象を受ける。

まだベータ版的な雰囲気も漂うし、設定を解説しているページも割と最近作られたはずなのに早速キャプチャと相違があったり、なかなか難儀な作業であった。

ざっくりと設定方法

例によって仕様が短期間で変更する可能性があるので参考程度でキャプチャなしで書いてみる。

いつものGoogleアナリティクスの画面にアクセスして、設定アシスタント的な画面を探そう。初回だけポチポチっと発行作業が必要だけど、従来のユニバーサルアナリティクスの設定が消えてしまうことはない。追加されるイメージだ。

今度はまたポチポチっと頑張って、トラッキング情報を表示させよう。

これを目的のサイトのしかるべき場所に貼り替えればOKだ。

トラッキングコードを貼る場所

と言っても、トラッキングコードなんて滅多に張り替えることがないから、数年前に作業してそれっきりという人も多いはず。

基本的にはhead内に貼ることなっていて、Googleの推奨ではheadの一番最初となっているけど、サイトの仕様とか個人的ポリシーで何となく気持ち悪い場合はheadの最後とかでもいいと思う。

WordPressの場合は親切なテーマの場合はカスタマイズ設定とかにアクセス解析のコードを入力できる場合もあるので、前回の作業を忘れちゃっている場合は探してみよう。

手動で対応する場合はFTPでテーマ内のディレクトリにあるheader.phpをいじるのが一般的。ミスった時のためにバックアップをとっておくとよい。

Googleで推奨されるプラグインはやめた方がいい

GA4の設定アシスタント的なもののウィザードに従うとWordPressのアクセス解析の自動設定プラグインを推奨されるけど、個人的にこれは辞めた方がいい。

面倒だからと試しに入れてみたが3つくらいプラグインが追加されて、メールの広告みたいのも届くわで速攻で削除した。

Web界の意識高い層の人たちはもちろん、それなりにWebの経験がある人からしたらWorPressのプラグインは最小で使うのが基本であって、この程度のコードコピペで済むものをプラグインで対応されるのがデメリットが大きいのだ。

覚えておいて損はないが、プラグインを増やすと管理の難易度が増大し、制作の自由度は下がる。セキュリティも低下する。マイナス作用が大きいのだ。

GA4でもメールレポートはできる

以前のユニバーサルアナリティクスでは設定をしておけば自動的にメールでアクセス解析のレポートを送ることができた。

パッと探した感じだとGAに同じ機能は存在しないようだが、GoogleのLooker Studioっていうサービスを使えば似たようなことができる。

むしろ、簡単にグラフだとかグラフィカルな内容でレポートを自動送信させることができるみたいなので、興味のある人や上司とかに命令されている人は調べてみるとよいだろう。

ちなみに、サードパーティーの無料アクセス解析レポートみたいのはGA4だと対応してない場合もあるみたい。Googleの公式サービスの方が充実しているから、まぁ仕方ないかな。