wordpressでimg要素に勝手につけられたsizes属性、width属性、height属性を削除する方法

表題の件、ググると、
add_filterを使った方法(↓)や、

wp_calculate_image_srcsetを使った方法(↓)などが

でてくるのだけど、
ちょっと強引だけど、こんな方法もあるよ、というご紹介。

以下のコードをテーマのfunctions.phpに追加してやればよい。

function custum_theme_content_replacement($the_content) {
        $return = $the_content;
        $return = preg_replace(
            array("/(sizes|width|height)=\"((?:\\\.|[^\"\\\])*)\"/i")
            ,array(" ")
            ,$return
        );
        return $return;
}
add_filter('the_content','custum_theme_content_replacement');

まぁ見てもらえばわかるけど、コードの内容をかいつまんで説明すると、コンテンツを表示するときにsizes属性、width属性、height属性を正規表現を使ってまるっと置換して削除しちまえ、ってことをしている。

かなり強引なやり方だけどね。
選択肢の一つにしてもらえれば。

ダブルクオートやシングルクオートで囲まれた文字を抽出するための正規表現

HTMLの属性値を正規表現で書き換えたいときなど、ダブルクオートやシングルクオートで囲まれた文字を正規表現で抽出する場合は以下の正規表現で抽出が可能。

"((?:\\.|[^\"\\])*)"

HTMLの属性値を限定したい場合は以下のようにすればよい。

(sizes|width|height)="((?:\\.|[^\"\\])*)"

この正規表現の出典は以下のサイトより。

「人力検索はてな」より抜粋
http://q.hatena.ne.jp/1246344237

正規表現の読み方は以下のようになります。
——————————————
"              # 文字列の開始
 (               # キャプチャするグループ化
  (?:              # キャプチャしないグループ化
   \\.               # バックスラッシュによってエスケープされた任意の一文字
   |                 # または
   [^\"\\]           # ダブルクォートとバックスラッシュ以外の一文字
  )                # グループ化終了
  *                # ↑の 0 回以上の繰り返し
 )               # グループ化終了
"              # 文字列の終了
——————————————

なおPHPのpreg_replaceで使用する場合には以下のようにエスケープする必要がある。

preg_replace(
    array("/(sizes|width|height)=\"((?:\\\.|[^\"\\\])*)\"/i")
    ,array("(変換したい文字列)")
    ,$return
);

エロい人ありがとう。備忘録として。

PHPの開発環境にVisual Studio Codeがいい感じ

PHPの開発環境でよさげなエディタがないものかずっと調査していたのですが、
どうやらMicrosoftが作ったフリーのコーディングエディタである「Visual Studio Code」なるものがよさそう。
無料だし。なんせ無料だし。

Micorosoft Visual Studio Code
https://www.visualstudio.com/ja-jp/products/code-vs.aspx

んで、早速触ってみましたよ。

ちなみに、我が家の開発PCは基本的に外に持ち出すことを前提としておりまして、軽量コンパクトなノートPCが開発環境になっております。つまり非力なのです。だからEcripsなんて動かすだけでもCPUとメモリから煙が出そうな重厚なものは不可なのです。

ということで、我が家で一番非力なマシンであるASUS E200HAにVisual Studio Codeをインストールしてみました。

結論として・・・・

結構いけるじゃないの!!
ちょっとモッサリしてるケド。

さすがマイクロソフトのVisual Studioの名を冠しているだけあって、超IDEライク!!
テキストエディタな感じが一切しない!!
だから開発してる気分がモリモリですよ!!
ちょっとモッサリしてるケド。

デフォルトのデザインがいい感じじゃないの!!
ちょっとモッサリしてるケド。

コードの自動補完(スニペット:Snippets)とかIDEライクに効いてくれて、しかもjson形式で設定できるから、メンドクサイUIでちまちま設定する必要もないし!!
ちょっとモッサリしてるケド。

コードハイライトもデフォルトで効いててくれて、とくに設定をイジル必要もなくデフォルトで使えちゃうレベルです。
ちょっとモッサリしてるケド。

Gitなんかもデフォルトで使えちゃうんですよぉぉ!!
Gitなんて使ってないけどね。
あと、ちょっとモッサリしてるケド。

ちなみに、ちょっと古いけど、この↓サイトなどで

Visual Studio Codeの謎ペインの仕様はユーザ離れを起こす原因となり得そうな件
http://www.bunkei-programmer.net/entry/2015/11/25/190000

「純粋なタブの概念ではなく、横にしか分割できないペインが恐ろしく使いにくい」

とおっしゃられていたので、どうにかしてタブウィンドウで開けないものか触っていたらなんとも簡単にできたよ。

左ファイルツリーのファイルをダブルクリックすればタブウィンドウで開くじゃないの。

ってことでVisual Studio Code で複数ファイルをタブウィンドウで開きたい場合はダブルクリックすればいいよ。問題解決。

しばらくVisual Studio Code使ってPHP開発してみようかとおもってますよ。

PHPerはワープアまっしぐら。PHPerの単価が月60万~とかありえない。

そもそもPHPerの単価が月60万~とかありえない。

「フリーランスエンジニアが知るべき、PHP案件のトレンド、特徴、単価相場とは」
https://freelance.potepan.com/blogs/1685.html
より引用

~前略~

フリーのエンジニアが受け取る報酬の相場は一般的にプログラマで「40~60万」、システムエンジニアで「60~80万」と言われています。もちろんスキルや時間によりますが、一般的にはPHPですと相場は月60〜高い方で90万ほどです。

~後略~

この記事についてモノ申したい。

PHPが短期開発に向いているのは正しいが、それはPHPが規模の小さいシステム開発に向いているという理由がある。1人ないし2人という小規模でチャチャっと作ってしまうようなシステム開発でPHPは非常に大きな力を発揮する。そういう小規模なシステムだけに予算自体も少ない。大きなシステムほど成功すれば大きな利益が得られるが、システム規模が小さくなれば利益も少なくなり、自ずとシステム開発予算も小さくなる。

PHP案件は予算200万以下という案件が圧倒的に多い(比べてJava案件は億規模がゴロゴロある)。これに原価60%だと計算すると120万になる。これがエンジニアに支払われる金額となる。予算200万の規模だと工数は延べ2~3人月ぐらいが良いところだろう。工数がかかりすぎだと思うだろうか?これに要件定義や設計期間、運用テストなども含まれていると仮定すると、妥当な数値だ。単純に120万を3で割っても一人当たり40万だ。上流工程で月40万とかはありえないので、マネジメントをする上流SEだけ月60万と計算すると、コーダーに支払われるのは一人当たり30万となる。この計算、発注者と受注者の間にウワマエを刎ねるハイエナ会社(管理費、口座貸費用などの名目でウワマエを刎ねる)が一切いないことを前提に話している(つまり商流が1段)。ハイエナがいればそれだけ技術者に流れる金も少なくなる。

次にPHPは比較的に習得が容易だ(PHPフレームワークなども含め)。つまりPHPerはたくさんいる。技術者がたくさんいれば相場は自ずと下がる。さらに高度な技術者は単価の低いPHP案件など受けない(Java案件などの単価の高い案件にいく)から、PHP案件しか受けられない技術レベルの低い(=単価を安くせざろうえない)技術者しかいない。結果、案件争奪戦はダンピング合戦となり、PHPer=低単価が決定される。結果、高いレベルの技術者は余計にPHPからはなれていく。ここ7~8年ぐらいこの負の連鎖が続いた。これがPHPerのエンジニアリングサービス(技術者派遣)の実情だ。ぶっちゃけて、Javaなら月60万から、PHPなら月30万から、と買い手と売り手の双方で価格相場が形成されている。PHPerがこれを超えて単価を勝ち取るにはPHPコーディング以外の付加価値が必要となる。

ではそもそもPHPで予算規模の大きなシステムはあるのか?あるにはある。しかし全体からすればごくごくわずかで、しかも首都圏に限られる。もちろんそこには高レベルの技術者が集まってくる(Javaでバリバリ稼いでいるけど、PHPが好き、などの場違いな高段者)。あなたはそこで彼らと肩を並べる自信はあるだろうか?

ではなぜPHP案件で予算規模の大きなシステム開発案件がないのか?それは大手システム開発会社が関わっているからだ。大きな予算がついているということは失敗が許されない。つまりリスクをちゃんとヘッジしてくれる大手システム会社にまず話が持ち込まれる。そういう大手はよっぽどのことがない限りPHPなど絶対に使わない。かならずJavaが提案される。(なぜかって?そりゃJava技術者のほうが人件費単価が高いからだよ!!そのほうが見積額を高額にできるからねっ!!)

さらに、エンジニアリングサービスにも地域格差というものがある。関西(主に大阪)は首都圏(主に東京)に比べて単価が80~70%と思っていい。東京での単価60万が大阪なら48万に、東京での単価40万は大阪だと32万になる。「SEなら東京にいけ」というのはこういうところからも来ている(そもそも案件数が首都圏は関西の2倍以上あるというのが主な理由ではある)。

つまり、金を稼ぎたいなら、PHPではなくJavaをやれ、というのが結論だ。というか常識と言っても過言ではない。

冒頭サイトで

PHPの場合はなにしろ開発需要が大きく、求人案件数も多いため、フリーランスの皆さんも多くの案件から自分に合ったものを選ぶことができます。

とあるが、この文章の後ろには「単価(給料)を選ばなければ」という一文が隠れていることを声を大にして言いたい。PHPの仕事は腐るほどあるのだ。だが誰が見てもワープアまっしぐら。あるていど会社組織の体を成している組織(社員を抱えていて食わせていかなければならない組織)では、その単価の安さから受けることができない(受けたら赤字確定だから)。したがってPHP案件は常時人不足。そこが辛うじて現在の単価を維持しているカラクリだ。

このままだと、PHPがあまりにも悲しいのでPHPの優れている点もあげていく。
(技術的に、ではなく、ビジネスとして、という観点から)

PHPはJavaに比べて圧倒的に「安く」作れる。PHPはあらゆるコストがJavaに比べてとても低いのだ。つまり同規模のシステムであれば、Javaに比べPHPのほうが1/10の金額で作れる。これは予算が限られている顧客にとって最大のメリットとなる。したがって、我々のような極小規模のインディペンデント会社が、技術者を売るのではなく、システム開発の全体像から提案して受託開発の受注を狙う場合は、PHPで提案することにより顧客に刺さる可能性が飛躍的に高まる。さらにインフラ周りや改修などの運用コストも低く抑えられるので提案力が出てくる。つまり、起業するとかフリーランスでシステム開発受託を狙う場合、大手と差別化をはかるという意味でPHPは大きな武器となる。逆に、前述に戻るが、末端技術者としてPHP案件に従事するというのであれば、経済的にジリ貧以外のなにものでもない。ワープアまっしぐらだ。「それでもPHPが好き」というのであれば別だが・・・

phpのunserialize()メソッドをつかったエンコードツールを作ったった

phpのunserialize()メソッドをつかったエンコードツールを作った。phpのserialize()メソッドでオブジェクトやら配列をテキスト文字列化(シリアライズ化)したものを入力すると、unserialize()メソッドをつかってデコードして、配列(もしくはオブジェクト)をprint_r()メソッドで出力する。需要あるかわからないけど、俺が開発を進める上でほしいなぁとおもったのでWEBサービスと言う形で作ってみた。もし入り用ならどうぞお使いください。

PHP UnSerialize Encorder

ただ、serialize()したものをunserialize()で戻すのはできるのだけど、逆の配列をserialize()してシリアライズ化するのはできない。セキュリティをクリアするアイディアを思いつかんかった・・・・思いついたら実装するかも。

投稿日:
カテゴリー: PHP技術系

ロリポップのCRON設定でシェルファイルを使ったとき「/bin/sh^M: bad interpreter: No such file or directory」というエラーが出る。

ロリポップのCRON設定でシェルスクリプトを使う場合、以下の様なエラーメッセージが出てハマった。

/bin/sh: /home/users/2/アカウント名/web/my_cron.sh: /bin/sh^M: bad interpreter: No such file or directory

そもそも原因はロリポップじゃなくて、オレ・・・・

結論から言うと「シェルファイルの文字コードをUTF-8、改行コードをLFのみ」に変更するとなおる。

Windows標準の「メモ帳」とか使ってちゃだめなんだぜぇ~

ん~~~UNIX?なにそれうまいの?

WEB用ライトウェイトスクリプトのちょっとアンチテーゼなオブジェクト指向

ずっとWEBアプリ用のライトウェイトなスクリプトをコーディングする仕事をしてきてるわけだけど、前職の先輩が言ってた。

「こういうライトウェイトなスクリプトはファイル一つ一つがクラスのようなものだ」と。

つまり・・・

そのファイルをコピーして使うのが継承すること。

どのファイルをちょっと書き換えるのがオーバーライドすること。

プロパティ(メンバ)はできるだけ別ファイルで定義する。

「できるだけコードを改変せずに」なんて考えない。

カプセル化なんてしない。フルオープンがいい。

逆に、気軽に書き換えて、それが簡単に管理できるようにする。

ライトウェイトなんだからコーディングから機動性を奪ったら長所が消える。

多態性(ポリモーフィズム)なんてしらん。ライトウェイトに所以する機動性で十分だ。

スパゲティになるのはアフォが何も考えずにコーディングするからスパゲティになるのであって、シッカリした管理の元に、統一されたポリシーをコーダー全員が共有してコーディングすれば、スパゲティになんかならない、と。

これって十分オブジェクト指向だ。

すべてこの考えを踏襲しているかというと、そういうわけじゃないけど、ほぼこの思想は俺のコードに受け継がれている。

だから、俺の書くコード量は多いけど、ほとんどがコピペだ。コピペすることを前提書かれたコードだから信頼性も高い。

継承してオーバラードして・・・カプセル化してるから何してるかわからない・・なんてないからコード量は多いけど非常にシンプルで読みやすい。

さらに、本棚を整理するようにコードも整理できるから、さらに読みやすい。つまりバグが少ない。

javaとかCとかからもってきた概念を用途の違うライトウェイト言語に適用しようとするからややこしいんだよ。

投稿日:
カテゴリー: PHP雑記

Microsoft Translate APIとPHPをつかって翻訳モジュールつくってみた。

Google Translate APIがV2になってから有料になったそうで。ってことで月間200万文字(200k character)まで無料のMicrosoft Translate APIを使おうってひとが多いと思う。みーつー。ってことでMicrosoft Translate APIとPHPをつかって翻訳モジュールを作った手順をざ~~っくりご紹介。

つくったコード公開しようとおもったけどメンドクセから、やめた・・・ごめんね。↓で紹介しているサイトみればすぐわかるよ。

ちなみにMicrosoft Translate APIも月間200万文字を超える場合は有料になる。

トークンの取得

Microsoft Translate APIのメンドクサイところは、APIトークンを取得しなければならない点。そのトークンも500秒しか有効じゃない。500秒経過したら再取得しなければならない。うわ、マンドくせ。

ってことで、トークン取得のノウハウは↓のサイトをみればわかるのでじっくり読むように。サンプルコードもあるので、じっくり読むように。ちなみにトークン文字列頭に「Bearer 」(スペースが入っている点に注意)という文字列をいれないといけない点に注意なので、じっくり読むように。

翻訳処理

AJAXでJSONで受け取るもよし、HTTPでプレーンテキスト(XML形式)で受け取るもよし。おれはCRONでPHPブン回して自動翻訳したかったので、HTTPを使用した。↑のサイトにも翻訳処理のサンプルコードが含まれているし、詳しくは↓のサイトにも書いてある。よくよんでちょうだい。

ちなみにGoogle Translate APIは100万文字(100k character)で$20だそうな。月間費用ではない点に注意。

ちなみにちなみにGoogle Translate APIの場合は、わざわざトークンをとる必要はなさげ。AppKeyをURI内に組み込めばよさげ。

投稿日:
カテゴリー: PHP

jQueryをつかってHTML文字列を表示させるときにIEで文字化けする

以下の処理を行うときになぜかIEでのみ文字化けする現象にぶち当たった。

A.phpにイベントを仕掛けて

jQueryのAjaxメソッド発動

B.phpにAJAXリクエストをなげて

B.phpでHTMLテキストを生成して

A.phpのAjaxメソッドに戻して

A.php内のボックスに$(~).html(~)でHTMLテキストを描画

なぜかIEでのみ文字化け!! (´;ω;`)

なぜかIEの「ページ→エンコード→自動選択」をONにすると文字化けがおこらない。

ChromeやFirefoxでは文字化けは一切おこらない。

さらに、自分のテスト環境ではおこらず、本番環境でのみ発生する。

おそらく、ApacheかPHPの設定が異なるために起こっているのだと思う。

(詳細はしらべてないのでシラネ)

ってことで早速Google先生をシバキ倒してみたら、↓に答えのヒントを書いてくれているエロいひとを発見。

感謝感謝。

ズバリ以下のコードをHTMLテキストを吐く直前に書いてやればいい。

header(“Content-type: text/html; charset=UTF-8”);

前述のヒトはJSONデータでお困りだったようだけど、今回は「text/html」なので、そこらへんを修正ってことね。

以上、めでたし、めでたし。