2018-11-05

Wordpressのインストールは成功したが表示が崩れたときのメモ

wordpress

少し変わったサーバー設定で作業したら困ったのでメモ。

概要

コーポレートサイトにブログを新設したい、という案件。
CMSはWordpress。
現在の静的コンテンツが置かれているサーバー(A)とは別のサーバー(B)にWordpressだけ展開するというもの。
URLはサーバーAのブログ用ディレクトリと、サーバーBのルートが紐づいている、という仕組み。
(例)http://example.com/wp_dir/ = http://cgi-server/test/root/

症状

http://example.com/wp_dir/からインストールに進むも、その時点で表示が崩れている。※
とりあえず進めてインストール成功するもインデックス画面も表示が崩れている。※
ログインもできない。
※コンソールエラー「Failed to load resource: net::ERR_NAME_NOT_RESOLVED」が出ている。

原因

Wordpressを展開した方のサーバーBのリバースプロキシが原因で、Wordpressのパスが書き換えられてしまっていた。

そのためFailed to load resource: net::ERR_NAME_NOT_RESOLVEDのエラーで、「読み込めないよ」と言われているURLも
http://cgi-server/wp-admin/js/anguage-chooser.min.js
とか、直接サーバーBのしかもルートからパスを読んでエラーになっていた。
http://example.com/wp_dir/からアクセスしているのにここはどこなんだ、ということでした。

対処法

functions.phpからサイトURLを指定する。
冒頭に
update_option( 'siteurl', 'http://example.com/wp_dir/' );
update_option( 'home', 'http://example.com/wp_dir/' );
と実際に指定したいurlを絶対パスで記入する。
参考
サイト URL の変更 - WordPress Codex 日本語版

蛇足

Failed to load resource: net::ERR_NAME_NOT_RESOLVEDについて
見慣れないエラーなので調べたがあまり要領を得ず。

Chrome - net::ERR_INSECURE_RESPONSE のエラーが発生していてページ遷移できないことがある。｜teratail

>違うサーバー名のホストがレスポンスしてきたぞ

とあるので、名前の通りサーバー名がちゃんと解決してないよ、ってことかなと。
実質404みたいなものなので、上記の通りパスが通れば良いというのは変わらず。
勉強になりました。

2018-10-21

Uncaught TypeError: Cannot read property 'top' of undefinedが出た時

"Uncaught TypeError: Cannot read property 'top' of undefined"
このエラー文が出るときは大抵、動的に追加した要素のoffset()を取得しようとしている場合が多い。
今回もサイドバーをスクロール追従させる処理を書いている時に、サイドバーを動的に読み込んでいるせいでエラーが出た。

記述を$(window).on('load', function(){});へ移動して対処。
無事エラーは出なくなった。

2018-10-13

contact form7からメールが送信されない

WordPress

Rest APIが悪さをしているか、テストサーバーが試用期間のためか。
今回は急ごしらえした自前のテストサーバーだったため。
クライアントのテストサーバーで設置したところ問題なく動いた。

Contact Form 7 でメールを送信できない原因と２つの解決方法

2018-10-02

sourcetreeで何回もパスワードを聞かれた時のメモ

git

sourcetreeでクローンするときに昔どう解決したか忘れて焦ったのでメモ。

いつも同じuserでログインするとは限らないので、
usernameを明示的に記載してやれば上手くいく。

>http://username@host/path/to/repo
https://community.atlassian.com/t5/Sourcetree-questions/Sourcetree-keeps-asking-for-login-and-password/qaq-p/146765

業務で複数のBacklogを往来していたのが原因だった。

2018-09-21

nodeとyarnのバージョン変更したメモ

node gulp

nodeとyarnのバージョン変更したメモ

普段と全く違う環境で作業する機会があったが、node.jsのバージョンを変えるのに毎回検索するので備忘録。
yarnは最新版をインストールされてしまうのでバージョンを指定してインストールする方法のメモ。

nodeはnodebrewで変更。
$ nodebrew use v8.11.2

yarnはnpm使ってバージョン指定した。
$ npm install -g yarn@[version]

参考
https://qiita.com/toshi0607/items/37eb13ab979422306d3b

2018-09-20

何がエンジニアのレベルを表すのか-コードの質を担保するものについて-

HTML・CSS

自分のレベルについて

ブログを書き始めて、「自分のレベル」について考えることが増えた。
「誰に（どの技量の人に）向けた記事か」は「誰が（どの技量の人が）書いた記事か」と当然影響が深い。
自分のレベルが分かっていないと、誰に向けて書いている記事なのか、
狙いがあっているかどうかも自覚できない。
そうなると読者にとってミスマッチな内容になりかねない。
ギターの音が出せればいいだけの人に、ピックアップの仕組みから話したところでそんな話求めてないわけだ。
そもそもギターの音が出せないレベルの人はそれを読んで「お、ついでに勉強になるやんけ」とはならない。多くの場合上位互換は起きない。
コーナリングのコツを伝授！とかで書いてある内容が「ここでアクセル全開、インド人を右に! 」とかだったら速めの回転のスーパーウリアッ上が出てしまいますがな。
そう言うミスマッチを防ぐために、(ゲーメストは誤植だけど)「普段これぐらいの技量の自分が、これをできるようになるまで」と言う具体的な例を示した方が、読み手がフィルタリングしやすいのかな、と今の所落ち着いた。

そもそも自分のレベルはいかほどか

話を戻して、そう言うこともあり「そもそも自分はどれぐらいのレベルなんだろう」と考えるようになった。
客観的に指標があれば給与交渉もしやすいし、相場の単価と自分の価格設定と比較もできる。
安売りするつもりはないが、異様に高額なのも気持ちが悪いもので、
納品した商品に見合う適切な価格がもらえればいい（真理）ので、そういった調整も必然性を持ってできる。

文句言うほどではないけど「この価値あった？」と考えてしまう時が一番切ない。
安くないマッサージに行って身体をバラバラにされるような攻撃を受けた自分ならわかる。
並ぶほどじゃない味のラーメン屋。
洗濯一発で伸びてしまった6000円のシャツ。
価格に見合わない、しょっぱいブツは端的に言ってダサいのだ。ダサいのは嫌。
ダサいくらいなら漢でいたいんや。
A)「おいおいこれじゃ君に見合わないだろ、ホラ」
B)「何言ってんのさ、そんなものの代わりにスコッチをくれよ」
C)「まったく君ってやつは」
D)「ウンバル=ヴォガリータ=ミドレ」
E)「ハッハッハッハ」

実際にどうなの

で、自分について列挙してみる。

レスポンシブのLPなら一日で作れる。
CMS組み込み出来る。
jQueryであれこれしたり、ライブラリのカスタマイズで頭をかかえる、と言うようなことは減ってきた。
gulpでローカル環境立てて、sassを使ってオートリロードでサクサク静的コーディングしている。
Gitは当然。グループ作業万歳。リポジトリ大爆破。
運用前提でメンテナンスしやすいコードを意識。
命名規則、ディレクトリ構造も基準のルールあり。

でも、悲しいかなこれって「下の中」かなと思っている。
とはいえ体感的な評価だけでは芸がないと思い、
スキルチェックや、チェックシート型のレベル分け云々の記事を流し見していても妥当なところだろう。
なんだか寒くなってきたな...。

何が質なのか

さておき、こう言った客観的なチェック項目を見ていて、
抽象的な「質の高いコード」の「質」とは？ということについて気付いたことがある。
(ちょっと前の記事だけど)

http://w3q.jp/t/7905
- 現在の私のコーダーレベルが知りたいです。 -
>作業量自体はコーディングのレベルにあんまり関係ない。
>それよりもサイトにあわせて最適な設計・機能の実装が出来て、メンテナンスを考慮したり、制作時にページを簡単に量産できるような仕組みを考えられることが大事。
>常に改善点見つけながら制作していくことが出来れば、すぐにコーディングの腕もあがるよ。
http://language-and-engineering.hatenablog.jp/entry/20110702/p1
- HTMLとスタイルシート（CSS）の業務スキルレベル　判別表　（５段階） -

割と自分は「速さ」だと思っていたけど、結果的な見た目や出来上がってくる速度よりも、
見えない部分が質を担保しているのだと思った。
他の人が見ても運用しやすいコード、単純にインデントがついていて見やすい、コメントがあってわかりやすい　と言った単純なことから
バリデートチェックがしてある、ロードのストレスがない、ファイルが軽量化されている、そもそも記述が少なくまとまっている、　他にも
的確なCSSの設計、BEM記法、ディレクトリ構造がすっきりしている、sassの分割の仕方がわかりやすい、と言った「作業そのものがしやすいか否か」というところまでが
具体的な質につながってくるのだと思った。
そして質が伴っているから量になった時に速度に差が出てくる。
作業の質が悪いから遅いのだとも言える。

「初めは遅くても、まずは綺麗に切れるようにしなさい。速くするのは後からでも出来る」
昔居酒屋のバイトで初めてネギの千切りを習う時に言われた言葉で、記憶に残っている。
これは制作でも同じで、
汎用クラスでゴテゴテのパーツを切り貼りした1ページも、
うまく設計されたcssで作られた1ページも、
それまでは見た目は同じかもしれないが、
ここからあと5ページを複製してもらったら圧倒的に後者の方が労力が少なく済む。
労力が少ないから質にも気を配れると言う好循環を産む。

「作業量自体はコーディングのレベルにあんまり関係ない」のは確かで、さらにいえば
「作業量（制作ページ数）によって労力が左右されない技術・設計」がレベルを表しているのかなと思った。
単純な力技・早業は限度がある。
めちゃくちゃ足が速いびっくり人間になれるかどうかではなく、車を作れるか否かが分かれ目なのだろう。
そして車(ノウハウ)は一度作ってしまえば、何度でも使えるし、メンテナンス次第で性能を上げていくことができる。

まとめ

目に見えるもの以外に質が担保されていることが多いのだと思った。
整った制作ルール・環境自体を作ることができて、さらに適切に扱える人のことを技術者と言うのだろう。
怠け者の方が良い、と聞いてイヤイヤ俺はきっちりやるッス！と言うやる気も良いが、
労力をかけないすなわち無駄な作業を無くせる技術、それイコール上流の技術を知っているからこそ成せる技と言うことで。
チクチク経験値を積むことが何事も大事なので今日も俺はネットの海を漂うわけっす。

2018-08-20

重なった背景レイヤーをcssで表現する

HTML・CSS

色違いだったり、画像のレイヤーが重なったデザインを擬似要素で表現する。
紙モノ的なデザイン。
見出し箇所などでよく見る気がする。

f:id:numb_yam:20180820171338p:plain
これでいうと、赤い背景レイヤーと緑枠のコンテンツ領域とが重なっているところ。

html

<div class="wrap">
  <h1 class="ttl">タイトルとか</h1>
  <div class="content">
    <div class="sec">内容とか</div>
        ...以下略
  </div>
</div>

css

.wrap{
  /* 包含ボックス */
  position: relative;
  z-index: 1;
}
.wrap::before{
  /* 装飾部分 */
  content: "";
  display: block;
  position: absolute;
  top: 0;
  left: 0;
  z-index: 1;
  width: 100%;
  height: 100px;
  background-color: #fc402c;
}
.ttl{
  position: relative;
  z-index: 3;
  /* 以下デザイン部分 */
  padding: 20px 0;
  color: #fff;
  font-size: 1.5rem;
  font-weight: bold;
  text-align: center;
}
.sec{
  position: relative;
  z-index: 3;
  /* 以下デザイン部分 */
  width: 30%;
  height: 100px;
  padding: 10px;
  border: solid 2px #86c036;
  border-radius: 4px;
  background: #fff;
  color: #86c036;
  font-weight: bold;
  text-align: center;
}
.contente{
  display: flex;
  justify-content: space-around;
}

※コンテンツのz-index(ここでは適当に3)は、装飾パーツのz-indexより上ならばなんでも良い。

この場合h1のブロック要素を使ってコンテンツ領域全体をネガティブマージンで引き上げる、といった表現でもいいが、物理的にhtmlのタグを増やさない方が好みなのでよく使っている。
他にも表現があったら教えてください。

ナム山

家最高今年一年でサックスが吹けるようになるか観測中

Wordpressのインストールは成功したが表示が崩れたときのメモ

概要

症状

原因

対処法

蛇足

Uncaught TypeError: Cannot read property 'top' of undefinedが出た時

contact form7からメールが送信されない

sourcetreeで何回もパスワードを聞かれた時のメモ

nodeとyarnのバージョン変更したメモ

何がエンジニアのレベルを表すのか-コードの質を担保するものについて-

自分のレベルについて

そもそも自分のレベルはいかほどか

実際にどうなの

何が質なのか

まとめ

重なった背景レイヤーをcssで表現する

html

css