運営サイトで使用する注意書きテンプレートです。
▼ 住所について
省略せず、正確に入力してください。
表記は日本郵便が推奨する書式に修正することがあります。
京都の通り名や、字・大字などは省略いたします。
部屋番号は建造物名の後に移動します。
▼ 宛名について
個人宅の場合、必ず個人名を指定してください。
リモートワークで自宅に届ける場合、社名のみでは届かない恐れがあります。
事業所の場合、商号や屋号（会社名・店名・事務所名・病院名・学校名など）が必要です。
個人名のみでは届かない恐れがあります。
ショートバージョン
住所は省略せず、正確に入力してください。
リモートワークで自宅に届ける場合、社名では届きませんので、個人名を指定してください。
事業所の場合、個人名のみでは届きませんので、商号や屋号（会社名・店名・事務所名・病院名・学校名など）を指定してください。
ふと思い立って、問い合わせフォームを追加してみました。
プラグインには「Contact Form 7」を採用しました。
専用の固定ページを追加して、フォームを埋め込むタグのみを記入しました。
初期状態から少しだけ文字を変更し、テスト送信も無事に成功しました。
どれぐらい利用されるのか未知数ですが、しばらく様子を見てみましょう。
なお、先のプラグインは問い合わせメールは送信するだけの機能しかないようです。
そこで、メールをデータベースに蓄積できるプラグイン「Flamingo」の導入も進められます。
製作者が同じということで、連携を期待しましょう。
イラストレーターでドキュメント内のオブジェクトを操作したいのですが。
まずは、ドキュメント全て、要は開いているファイル全て取得。どちらでも良い（結果は同じ）模様。
$.writeln(documents);
$.writeln(app.documents);
で、appって何。色々検索したけど、日本語の説明を見つけられない。なお、英語では見つけたけど、読んでもよくわからない。
次に、アクティブドキュメント、要は今操作しているファイルの取得。どちらでも良い（結果は同じ）模様。
$.writeln(activeDocument); $.writeln(app.activeDocument);
で、app（以下略
ここからが本題。動かない理由がわからなくて、ちょっと気持ち悪い。コードを一気に書きます。
// ローカル（グローバル）
$.writeln(documents);
$.writeln(app.documents);
$.writeln(activeDocument);
$.writeln(app.activeDocument);
// 関数
function hoge() {
$.writeln(documents);
$.writeln(app.documents);
$.writeln(activeDocument);
$.writeln(app.activeDocument);
}
hoge();
// ウィンドウからのイベント
var win = new Window('palette', '窓');
var btn = win.add('button', undefined, '釦');
btn.onClick = function() {
$.writeln(documents);
$.writeln(app.documents);
$.writeln(activeDocument); // ここでコケる
$.writeln(app.activeDocument);
}
win.show();
明確な答えが見つからないけど、イラストレーターは自分を呼ぶ出すのにBridgeTalkクラス経由で実行する必要があるとのこと。なるほど…って、なんでやねん？！
var win = new Window('palette', '窓');
var btn = win.add('button',undefined,'釦');
btn.onClick = function() {
var bt = new BridgeTalk();
bt.target="illustrator";
bt.body = 'hoge();';
bt.send();
};
function hoge() {
$.writeln(documents);
$.writeln(app.documents);
$.writeln(activeDocument);
$.writeln(app.activeDocument);
}
win.show();
これで動くのはわかったけど、正直なところ気持ち悪い。Windowクラスがローカルを汚染、ここではactiveDocumentを削除してしまうのか？しかしdefined関数がないので定義判定が出来ないため確認できず。そもそもBridgeTalkクラスを呼ぶとactiveDocumentが復活するのは、BridgeTalkクラスがグローバルを汚染していることになるのでは？
activeDocuemtを使うためだけにBridgeTalkクラスを呼ぶのは気持ちが悪いから、activeDocumentを再定義すれば良いのかもしれない。と思ってactiveDocuent関数を書いたら、そこでイラストレータがフリーズする。これはダメみたい。
それならばgetActiveDocument関数を書けばいいと思ったけど、documentがアクティブかどうかの判定方法がわからない。document(s)のプロパティ一覧を調べても、アクティブかどうかを取得する方法がない感じ。そもそもアクティブかどうかはアプリケーションの状態なので判定できないのだろう。なるほど、それでBridgeTalkクラスが必要なのか。って思ったけど、だったらWindowクラスからのイベントで呼ばれない場合に動くのが説明つかない。やはりグローバルかどうかが鍵なのか？
<a href=”https://store.shopping.yahoo.co.jp/printry/”>プリントライ Yahoo!店</a>で銀行振込を利用した支払は年々減っており、ここ最近は全く指定されなかったので、バッサリと終了することにしました。現在はクレジットカードと電子決済・ポイントによる支払のみとなります。
Amazonではセラー（ストア）ごとの休業日設定ができません。クソですね。
ということで、年末年始で配送が滞る商品の販売を休止し、注文が入らないようにしました。商品の設定には納期の項目もあるのですが、アップロードでできる一括設定の方法が複雑でよくわからないのと、いつ届くのかという問い合わせ攻撃を回避するためです。
Amazonはセラーの自己発送をやめさせたい施策を次々打ち出していますので、休業日設定は絶対に実装されないでしょうね。直送品以外はとりあえず出荷できるので、休み無しでやろうと思ってます。
キャンバスボードの骨（骨組み）は一般的に木材です。それに布を張ってキャンバスになるわけですが。新しい商品として、紙製の骨にソフトクロスを張ってキャンバスボード（風）を作れないか検討中です。骨を木材にすると色々面倒そうなのです。そこでボール紙を使って紙製の骨を作ろうとしています。最低限の強度と立てかけられる安定性が必要になります。
始めは1枚の展開図から1つのキャンバスの骨を組み立てようとしましたが、強度も安定性もなく、台紙の使い方に大きく無駄が出てしまうので没になりました。そこで、部品に分けて分解された状態の骨を組み立てる方法を採用することにしました。角と軸に分けて組み立てると強度も出るような設計をなんとかひねり出し、なかなかいい感じになっています。後はどれだけ詰められるかというところでしょうか。
再送箱の設計って、難しいけど楽しんですよね。コピー用紙にフリーハンドで思いついたままに展開図を書き込んで組み立てて試しつつ、良さげなものができたら、イラレ上で清書してボール紙を実際にプロッタで抜いて組み立てるというのが基本的な流れです。なお、箱設計用の専用ソフトは持っていません。
メジャーなのは、実物のキャンバスボードにUVプリンタを使って直接印刷する方法ですが、UVプリンタがないのと、キャンバスの在庫も持ちたくないので、この方法は内製では採用しません。実のところは、コロナ禍のせいでポスタープリントの受注が壊滅していて、大判プリンタをどうにかして稼働させないと行けないのと、ソフトクロスの資材がホコリを被っているのが主な原因だったりします。なお、キャンバスボードの外注ってどうなのかな～と現時点では乗り気ではありません。
先日のことですが、出店申請が通過し正式に出店が決定しました。基本的には既に出店済みのYahoo!店・Amazon店と同様の展開を予定しています。
ストアのトップページは次のURLになります。
なお、この記事の投稿時点ではまだ未開通です。
メールサーバをcoreserverにおいた場合、アカウントに一般的な接続設定を済ませただけでは、ルートのメールが表示されません。これは、ルートと言っても実際にルートではなく、「INBOX」というフォルダに格納されているためです。よって、outlookでcoreserverに接続する場合は、サーバ設定のルートフォルダに「INBOX」を入力する必要があります。
なお、thunderbirdでは自動的に設定されるので、この作業は不要です。これでthunderbirdから乗り換えられますね。
coreserverに限らず、メールサーバのシステムによってはルートに「INBOX」の指定が必要なようです。必要ではないサーバーがあるのかといえば、それは知りません。
ちなみに、imapとsmtpの設定ですが。
imapは、サーバ名：xxx@coreserver.jp、ポート：993、暗号化：SSL/TLS。
smtpは、サーバ名：xxx@coreserver.jp、ポート：587、暗号化STARTTLS。
WordPressで構築されたサイトの移動をする案件が降りてきまして、それのテストを行っています。前の投稿でWordPressのアップデートについて書きましたが、実は移動テストのための下準備だったのですね。つまり自分のブログを移動（テストなので複製ですが）して流れを確認しようということです。
移動にはプラグインを利用すればかんたんということで「All-in-One WP Migration」を採用しました。WordPressのアップデートを無視して実行したのですが、処理自体は完了したものの「サイトに重大なエラーがありました。」と表示されてしまうことに。
移動後に調整するのは、不具合の原因が不明確なまま着手することになり、はっきりいって無駄な行為です。まずはバージョンを併せてから移動を行うことにしました。とりあえずWordPressを最新版の5.5.1に合わせます。そして移動のためのプラグインを導入します。ここまでは無事に終わりました。
コピー元とコピー先のバージョンが同じなのを確認して、サイトのエクスポートを行います。このブログは地味に長いので300MBを超えるデータになりました。ファイルをダウンロードできるようになるまで、30分ぐらいでしょうか、そこそこ時間がかかりました。512MBを超えるとプラグインの制限で扱いが厄介になるらしいのですが、その範囲内に収まっていたので一安心です。
コピー元からエクスポートしたファイルを、コピー先にインポートします。逆にならないよう注意しましょう。インポートの時間もそこそこかかります。エクスポートもインポートも気長に待ちましょう。
インポートの完了を確認して、サイトを確認します。目立った不具合もないようで、無事にコピーが完了しました。バージョンを併せていなかった場合の不具合を考えると、しっかりした準備をしておけばとても簡単な作業になりました。日頃のバージョンチェックも大事ですね。
いい加減古いまま使いう付けるのもアレなので、更新してみました。PHPが5.4のまま放置していたので、7.4にしたところ、「WordPress サイトに重大なエラーがありました。」と表示されてサイトが機能不全に。デバッグモードを有効にすると出るわ出るわエラーの嵐。1つずつ治すのもアホらしいのでWordPressを入れ直すことにしました。
データベースをローカルにバックアップして、このサイトはcoreseverでホストされているので、インストール機能を使って上書き。データベースの接続設定を今までのと同じに設定するとそのまま使えました。
テーマやプラグインが全て初期化されているので、適当に選んでいるところです。テーマはそれほど気に入ってなかったので別に構わないのですが、プラグインに内を入れていたのか記録もなく覚えてもいないのでさっぱりです。とりあえずtwitter投稿とアンチスパムぐらいは入れておきましょう。