ダミー

【Adalo】二つのAdalo間でアプリの移行

ノーコードでアプリ開発のできるAdaloの使い方。今回は二つのAdalo―例えば開発用とリリース用や開発者用と発注者用のなど二つのAdalo間でアプリを移行する方法をご紹介します。
https://ja.adalo.com/

Adaloのプランについて

Adaloには無料で使えるプランからさまざまなプランが用意されていますが、アプリを移行する場合移行元Adaloと移行先Adaloが共にApp StoreやGoogle playにアプリを公開できるプロフェッショナルプラン（以上）であることが必要です。
https://ja.adalo.com/pricing

移行元Adaloですること

左メニューでSetting ＞ App Accessの「Allow anyone to clone this app?」を
「Cloneable(Screens & Data)」に設定します。

設定を変えるとCloneable Linkが生成されるのでリンクURLをコピーし「OPEN」ボタンをクリックします。
シェア画面には「CLONE APP」ボタンが出来ています。

移行先Adaloですること

移行先Adaloにログインして先ほど生成されたCloneable Linkにアクセスし、「CLONE APP」ボタンをクリックします。これだけで、移行先AdaloにDBも含めたアプリが移行されます。

移行元Adaloの設定を戻すのを忘れずに

移行元Adaloの Setting ＞ App Accessの「Allow anyone to clone this app?」を
「Not Cloneable」に戻しておきましょう。

石造文化財アイコン「長慶（Chokei）」

みなさんの普段通る道に、お地蔵さまや古い道標などの石造物はありませんか？
実はあるけど、普段気にしていないから目に入らないだけかも知れません。
そんな街角の石造物を調査している団体やグループがあります。
この度、歴史と地図に特化したIT開発を手がけている Code for History さまのご依頼を請けて石造物の位置をマップ上にマーキングするアイコンを制作しました。
石仏情報学会

石造物アイコン

「石造文化財アイコン 長慶(Chokei)」としてオープンデータで公開されました！

Code for History さまによって石造文化財アイコン 長慶(Chokei)としてオープンデータで公開されています。必要な方はルールに則ってご利用ください。
https://github.com/code4history/IconForStoneAssets
プロジェクト名「長慶(Chokei)」は奈良に多くの石造物を残した奇豪、「吉村長慶」から採ったものです。

11月29日プレスリリースが発行されました

歴史と地図に特化したIT開発を手がけているCode for Historyが、石造文化財をアイコンとして表示できる「長慶（Chokei）」を11月11日に公開
https://www.value-press.com/pressrelease/308926

利用例1：令和館林石造物悉皆調査

館林には50年前の有志によって調査された、市内石造物の準悉皆調査があります。石造物の種別、年代、サイズなどだけでなく、刻銘なども判読された貴重なデータなのですが、反面、写真や正確な位置などはなく、現況との突合せは不可能な状況です。加えて、デジタル化もされておらず、統計/集計操作などもできない状況です。このまま現況との突き合わせがなされず、さらに将来になって突き合わせが困難になれば、せっかくの調査が死に体のデータとなってしまいます。そのため現況とのつきあわせ調査を行い、それをオープンデータ化するためのプロジェクトを始めました。

https://code4history.dev/TatebayashiStones/

利用例2：奈良地蔵プロジェクト

奈良市の道端の地蔵堂や小祠、石仏などをオープンデータ化するプロジェクトです。奈良市では、街角の小さな祠や石仏ですら、1300年、700年といった歴史を持ち、さらに マンションの土台にすら、地蔵の置き場が設計の上組み込まれるほど、現代にまで信仰が根付いています。都会のコンビニ以上の密度で存在する、小さく身近な信仰の場にあふれているのですが、残念ながら奈良市民には身近すぎるためかその魅力に気付いておらず、平城宮や世界遺産は宣伝しても、こういった身近な魅力を宣伝したり、外国人に説明しアピールしたり活動はありません。そこで、奈良市の祠、石仏をリストアップして紹介し、誰もが使えるオープンデータとして提供することで、新たな教育や街づくり、観光ビジネスの可能性に繋がると考え、2016年活動を開始しました。

https://code4history.dev/JizoProject/

インストールして月日がたったWordPressをメンテナンスしようとしたとき、このプラグイン何？誰が入れたの？前から入ってた？私は入れてないけど…なんてことにならないように、プリグインリストは必ず作るようにしています。

一方、レンタルサーバー各社は、「簡単インストール」「クイックインストール」などの呼称で、誰でも簡単にWordPressのインストールができるツールを準備しています。最近ではデータベースを触らなくても自動的にWordPress用にテーブルを作ってくれたりして、インストールのハードルがますます下がっていますね。それに伴い、自動的インストールされるプラグインもあります。そこで、サーバー会社のツールを使ってWordPressをインストールしたときに、自動的に入るプラグインの一覧を作りました。WordPress

さくらインターネット（調査時期：2022年8月）

  • Akismet Anti-Spam (アンチスパム)
  • All In One WP Security
  • Autoptimize
  • Classic Editor
  • Disable Google Fonts
  • Hello Dolly
  • ImageMagick エンジン
  • Protect Uploads
  • TS Webfonts for SAKURA RS
  • WP Multibyte Patch
  • WP Super Cache

けっこういろんなプラグインが入りますね。
TS Webfonts for SAKURA RSは、モリサワ社のWebフォントが使えるサービスです。さくらインターネット社がモリサワ社と契約をしていて、さくらインターネットユーザーがモリサワフォントを使えます。

GMO―ロリポップ、ヘテムル（調査時期：2022年6月）

  • Akismet Anti-Spam (アンチスパム)
  • Hello Dolly
  • WP Multibyte Patch
  • Site Kit by Google
  • SiteGuard WP Plugin

必要そうなプラグインがいい感じで選択されていますね。

X-server（調査時期：2022年10月）

  • Akismet Anti-Spam (アンチスパム)
  • Hello Dolly
  • TypeSquare Webfonts for エックスサーバー

シンプルです。余計なプラグインは何も入らないようです。
TypeSquare Webfonts for エックスサーバーは、モリサワ社のWebフォントが使えるサービスです。X-server社がモリサワ社と契約をしていて、X-serverユーザーがモリサワフォントを使えます。

まとめ

クイックインストール/簡単インストール などのツールを使ってWordPressをインストールしたときは、まずどんなプラグインが自動的にインストールされているかを確認し、そのサイトに不要であれば削除してから、必要なプラグインをインストールしましょう。

cssの@importの廃止が近づき、やっと@useに移行しようと考えてる方も多いでしょう。ここではVSCodeの拡張機能で多くの人に使われているLive Sass Compilerを使ってコンパイルします。難しいことは他のサイトに任せて、まずはごく簡単な_test.scssというscssを作ってテストしてみましょう。

.hoge{
  .red{
    color: #F00;
  }
}

これをstyle.scssに@useで読み込んでみます。@useではパーシャルscssのファイル名の「_」と、拡張子を省略します。
なので、style.scssはこんな感じです。

@use 'test';

そして保存すると、自動的にjsonで設定しておいたフォルダにstyle.cssが書き出されている…はず。

Success

「Success」も出てますよね。
確かにstyle.cssが出力されています。
早速、style.cssの内容をみてみましょう。

@use 'test';

え？ナニコレ？コンパイルされてない。こんなシンプルなscssが！？
Successって出てたのに、どうして…？
@importならコンパイルできていたのに。
調べたところ、そのPCに古いバージョンのLive Sass Compilerが入っていました。
ｖ3.0.0は@useをコンパイルできません。

現時点の最新はｖ5.4.0です。

これからLive Sass Compilerをインストールする方もご注意ください。検索で複数出てきます。

MW WP Form はウェブサイトにフォームを設置するWordPressのプラグインです。入力画面 > 確認画面 > サンクス画面 と遷移するので人気があります。Google reCAPTCHA にも対応しています。今回はこの MW WP Form を使ったお問い合わせフォームが突然画面遷移しなくなくなる不具合について解消法をご紹介します。

当記事の環境：WordPress 5.8、MW WP Form 4.4.0、WP Fastest Cache 0.9.3

現象の確認

複数の環境で確認したところ
・スマホはiPhone、Android共に問題はない
・AさんのWindows+Chromeでは正常、BさんのMac+Safariでは正常、それ以外の組み合わせで入力後確認画面に遷移しない
・テストサーバーに移設すると正常
つまり、本番サーバーでかつ特定のOS、特定のブラウザのときに不具合が起ることがわかりました。

フォームのページを WP Fastest Cacheの対象から除外する

調査を進めるうちにキャッシュが影響していると思われたので、フォームページをキャッシュから除外することにしました。当該サイトではキャッシュコントロールのプラグインとして WP Fastest Cache を使っていましたので、以下はWP Fastest Cache での方法となります。

「WP Fastest Cache の設定」の「除外する」タブから、除外するページにルールを追加します。特定のページを除外する場合は「Is Equal To」とそのページのスラッグ（例：contact など）を指定します。確認画面、サンクス画面がある場合はそれらも除外しましょう。

WP Fastest Cache

動作にばらつきがあったワケ

Webのお仕事をしていると「スマホでうまくいかない」「WindowsのIEだけうまくいかない」「Mac Safariだけうまくいかない」ということがよく起こります。
ところが、今回は不具合が起こる組合せがすぐにわからずプチパニックになりましたが、それにはちゃんとワケがあったのです。
落ち着いて WP Fastest Cache の設定を見ると以下のように
「ログインユーザーに対してキャッシュを表示しない」
「モバイルユーザーにデスクトップ版のキャッシュを表示しない」
にチェックを入れています。

例えば特定のブラウザだけ不具合が起こらなかったのは、そのブラウザでWordPressにログインした状態で送信していたから。
スマートフォンで不具合が起こらなかったのはモバイルユーザーにキャッシュを表示しない設定になっていたから。
つまり不具合が起こらなかった環境では元々キャッシュを表示しない設定だったのです。

また、設置したときに送信テストしても、その時点ではキャッシュが効いてないので問題は起こりません。

WP Fastest Cache

参照サイト

当記事では以下のサイト参照いたしました。制作者に感謝いたします。
MW WP Form FAQ

おすすめ記事