徒然なるままに プログラミングメモや日々の生活などつれづれとつづっていくblog

2019年6月24日

運用中のMisskeyをv10→v11に更新する。

Filed under: Fediverse,Misskey,オープンソース — ranpei @ 1:06 AM

分散型SNSが流行りだした当初、MastodonのほかにもMisskeyという国産の分散SNSも運用してまいりました。

月日はたちMisskeyも順調に開発が進められてついにv11になったのですが、
このv11からDB鯖がMongoDB→PostgreSqlに変更となったため
更新にひと手間かかります。

国産でありながらあまり情報が出回って無いようですので、
何かのお役に立てばと共有がてらメモを記録します。

■更新手順

リリースノートに更新の作業について書いているのですが、更新手順として

  • 最新ソースを取得後、migrationブランチをチェックアウトする。
  • 設定ファイルにMongoDBとPostgreSQLの接続設定を記載する。
  • ※またconfig.yml内のid:’aid2’となってる箇所をid:’objectid’にしてください
  • npm migrateを実行。
  • ブランチをmaster(もしくは使用するバージョン)に戻してMisskeyを起動する。

を行えばよいです。

ただ、上記には補足があって11.23.0現在までmigrationブランチは整備されています。
なのでv10.100→v11.0.0(migration)→v11.0.0(master)→最新verって感じに徐々に上げていく必要はありません。

上げる場合はその時点での最新バージョンで行いましょう。


手順は割愛します。リリースノート通りにやれば問題ないんで。

(むしろ更新するバージョンに合わせないと何度もやり直す羽目になります;;)

2019年2月27日

マストドンを初めて使う人のためのハウツー

Filed under: Fediverse,Mastodon,オープンソース — ranpei @ 9:37 PM

これからマストドン(Mastodon)を始めようとする方が戸惑うポイントをつらずらと書いていきます。

 

■基本編

  • マストドン(Mastodon)って何?

    Twitterライクな分散型SNSです。(とりあえず今はこれだけ覚えてください。)

  • まず何をすればいいの?

    気になるアカウントをどんどんフォローしていって
    メインとなるホームタイムラインを充実させましょう。

  • 知らない人をいきなりフォローして失礼じゃないの?

    問題ありません。むしろマストドンは「勝手フォロー」「勝手ブースト」が推奨です。

  • Twitterと全然違うね。。。

    別物なんですからむしろ当然では?
    下手にTwitterと同じように使うよりも、別の切り口で使った方が楽しいかもですよ?

■使い方編

  • トゥートって何?

    Twitterでのツイート(つぶやき)のことです。

  • ブーストって何?

    リツイートのことです。

  • 「ホーム」「ローカルタイムライン」「連合タイムライン」って何?

    とりあえずは以下の認識で・・・・

    [ホーム] :メインで利用するやつ。(どんどんフォローしてにぎやかにしましょう。)
    [ローカル]:このサーバーにいる人たちの公開トゥートが見れる。
    [連合] ※ :このサーバー”以外”の人たちの公開トゥートが見れる。(ここから気になる人を見つけてどんどんフォローしよう)

    ※ ごめんなさい。分散型の核となる機能なんですが説明量が多いんで省かせてください;;

  • カメラアイコンの横に「公開」「未収載」「フォロワー限定」「ダイレクト」ってあるけど詳しく教えて

    トゥートの公開範囲ですね。トゥートが見れる範囲が以下のようになります。

    [公開] :トゥートがタイムラインに流されて多くの人の目に留まりやすくなります。
    [未収載] :トゥートはタイムラインには流されませんが、見れないわけではありません。(あなたのアカウントをたどれば普通に見れます。)
    [フォロワー限定]:フォロワーのみが見れる状態でトゥートします。
    [ダイレクト] :特定のアカウントと1対1で話す場合に使用します。(まんまTwitterのDMですね。)

  • 画像を上げると目のアイコンが出たんだけど何?

    NFSWを設定して画像を投稿するオプションです。

  • NFSWって何?

    画像を隠した状態でタイムラインに流します。
    その画像を見る人が不快に思ったり、傷つくことが予想される場合に使用します。

    見る人はクリック(or タップ)すれば画像が見れる状態になります。

  • それ意味あるの??

    ワンクッション置くことで見る人は心の整理が付きますし、
    本当に見たくない人はそのまま見なければいいです。

    私は相手に選択の余地を残してあげる「思いやり」だと思っています。

  • CWって何?

    NFSWの文字版。
    タイムラインには折りたたまれた状態でトゥートが流れます。
    そのトゥートを見る人が不快に思ったり、傷つくことが予想される場合に使用します。

  • ってことは・・・

    はい。見る人はクリック(or タップ)すれば見れる状態になります。

    でもいきなり言葉を投げつけられるよりも
    相手に受け取るかを選択してもらう方が親切ですよね。

 

※もっと楽しく使いたいなら以下のサイトもおすすめです
〇Quesdon(ザ・インタビューズとかaskfmとかそんなかんじのやつ)
https://quesdon.rinsuki.net/
〇カスタム絵文字でお絵かきツール
https://mamemomonga.github.io/mastodon-custom-emoji-oekaki/
〇ドン廃あらーと(毎日午前0時にアカウントの変動状態をトゥートします)
https://donhaialert.herokuapp.com/

2018年4月22日

1つのサーバーでMastodonとPleromaを運用すると相互にフォローできない件

Filed under: Docker,Mastodon,OSS,オープンソース — ranpei @ 8:31 PM

うちの鯖ではDockerで構築したMastodonとPleromaとMisskeyの各インスタンスをVirtualHostでドメインごとに振り分ける運用をしています。

 

ただ、外部のインスタンスとはフォローし合えるのに内部のインスタンス同士ではフォローできずに困っておりました。

 

で、原因を探ったら以下の手順を踏むことで回避できました。

■回避方法

  1. DNSやhostsを使って名前解決できるようにする。
  2. Mastodonのソースをいじる。

 

順に説明していきます。

 

1.DNSやhostsを使って名前解決できるようにする。

まあ、これは真っ先に疑うことですよね^^;

LAN内部からドメインでアクセスするためには内部DNSを構築するかhostsを書き換えなければいけません。

うちは内部DNSを構築済みだったためこいつに設定を追加するだけで済みました。

そして、相互に名前解決できるようになったのですがこれだけでは不十分という・・・・

(一応Mastodonの検索欄で”@名前@ドメイン”で検索した際のエラーが「503 Remote data could not be fetched」→「422 Mastodon::HostValidationError on ドメイン」と変化しました)

 

 

2.Mastodonのソースをいじる。

この「422 Mastodon::HostValidationError」ってエラーについて調べてみてもよくわかんない(422ってWebDav拡張のステータスらしいですが・・・)

しょうがないのでMastodonのソースを見て「Mastodon::HostValidationError」がスローされている箇所を見てみると

app/lib/request.rb(135行目)に気になる部分を発見。

        Addrinfo.foreach(host, nil, nil, :SOCK_STREAM) do |address|
          begin
            raise Mastodon::HostValidationError if PrivateAddressCheck.private_address? IPAddr.new(address.ip_address)
            return super address.ip_address, *args
          rescue => e
            outer_e = e
          end
        end

これはプライベートアドレスの場合は問答無用にHostValidationErrorにしている??

 

で、PrivateAddressCheckについて調べてみるとconfig/environments/development.rbでわざわざfalseを返すように書き換えを行っていました。

ということはここのチェックでfalseとなるようにすればいいのでは??っと思いconfig/environments/production.rb側に以下の記載を追記。

module PrivateAddressCheck
 def self.private_address?(*)
 false
 end
end

 

そしてDockerコンテナをビルドしなおしてみると・・・・


$ docker-compose build web
$ docker-compose up -d

無事検索欄で”@名前@ドメイン”で検索してもちゃんとアカウントが表示されるようになりましたv^^v

 

 

とりあえずフォローできない問題は解決したんですが以下の2つが気になる。。。

  1. Mastodonはなぜわざわざプライベートアドレスをはじくようにしているのか?
  2. この対応の仕方で不都合が起きることはないのか?

そんなわけでこの対処方法は自己責任で行ってください。

2016年11月7日

Docker + LDAP+ MailServer(Postfix + dovecot) + Roundcubeを構築する

Filed under: Docker,Linux,OSS,postfix,Roundcube,オープンソース — ranpei @ 3:11 AM

ちょっと流れから脱線しますが、

Dockerを使ってのメールサーバー構築に成功したため

その内容をメモとして残します。

 

1.メールサーバーの要件

現在のメールサーバーの使い方なのですが、

以下の2つがあるためこれらを満たす必要があります。

・サービス毎のメールアカウント管理

・フリーメールの集約

サービス毎のメールアカウントを管理するのは前にも言ったようにLDAPL+バーチャルメールボックスで行けるのですが、

フリーメールの集約はFetchmailを使っているためこれが動作する環境である必要があります。

ではできるのか?というとRoundcubeにはFetchmailの設定をWeb上で行えるプラグインが存在します。

ですが、Fetchmailは取得したメールをローカルのMDAにフォーワードすることしかできないのできません。

つまりRoundcube自身にプラグインが入った状態でなおかつローカルにMDAが存在する必要があるのです。

 

2.考えられる構成は?

考えられる構成は2種類あります。

1つは以下のようにすべてを1つのContainerにまとめること。

%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc_%e5%8d%98%e4%b8%80%e3%82%b3%e3%83%b3%e3%83%86%e3%83%8a

もう1つは以下のように転送用のメールサーバーを構築してメインのメールサーバーにメールを転送すること。

%e3%83%a1%e3%83%bc%e3%83%ab%e3%82%b5%e3%83%bc%e3%83%90%e3%83%bc_%e5%88%86%e9%9b%a2%e5%9e%8b

 

今回はどうしてもメールサーバーとRoundcubeは別に構築したかったため後者で構築を行いました。

 

3.メールサーバーを構築する

これらのContanerについては要件を満たすものがなかったため

DockerHub上のものを改造する形で自分で作りました。

GitHubに挙げてますのでダウンロードしてください。

 

// メールサーバーのチェックアウト
$ git clone https://github.com/gittrname/mailserver-ldap.git
// Roundcube + Fetchmailサーバーのチェックアウト
$ git clone https://github.com/gittrname/roundcube-fetchmail.git

・docker-compose.yml

version: '2'
services:  
  mail:  
    build: mailserver-ldap  
    ports:  
      - "25:25"  
      - "465:465"  
      - "587:587"  
      - "110:110" 
      - "143:143"  
      - "995:995"  
      - "993:993"  
    links:  
      - ldap  
    extra_hosts:  
      - "mail.example.com:127.0.0.1"  
    environment:  
      - "LDAP_SERVER=ldap"  
      - "DOMAIN=example.com"  
      - "HOSTNAME=mail.example.com" 
      - "LDAP_BASE=ou=People,dc=example,dc=com"  
      - "LDAP_USER_FIELD=uid"  
  roundcube:
    build: roundcube-fetchmail
    ports:
      - "80:80"
    links:
      - ldap
      - mail
    extra_hosts:
      - "fetch.example.com:127.0.0.1"
    environment:
      - "ROUNDCUBE_DEFAULT_HOST=mail"
      - "ROUNDCUBE_SMTP_SERVER=mail"
      - "ROUNDCUBE_USERNAME_DOMAIN=example.com"
      - "HOSTNAME=fetchmail.example.com"
  ldap:  
    image: sharaku/ldap  
    ports:  
      - "8080:80"  
    environment:  
      - "LDAP_DOMAIN=example.com"  
      - "LDAP_ADMIN_PWD=password"  
      - "LDAP_ORGANISATION=LDAP for docker."

 

※ RoundcubeとLdapAdminのポートが被らないようにしてください。

後はLdapAdmin上でユーザーを作成すればメールアカウントの作成は完了します。

 

 

定期的なメールの取得はログインした後「設定」⇒「Fetchmail]で設定します。

取得先のドメイン、ユーザー、パスワードを設定すると15分間隔でメールを取得し、

ログインユーザー@ドメインにメールを転送します。

 

ちょっとデータの永続化に多少の不安がありますが

一応、やりたいことはできたので公開してます。

2016年10月28日

Docker + PowerDNS + Sqlite + PowerDNS AdminでDNSサーバーを作る

Filed under: Docker,ESXi,OSS,オープンソース — タグ: — ranpei @ 12:00 AM

内部ツール系サーバーを構築するに当たり

内部DNSサーバーにはBindでは無くPowerDNSを使用していきます。

 

PowerDNSを使うことにしたのは単にGUIツールが存在しており

ファイルをいじって設定する手間が省けるな~とおもたっからですw

 

1.Dockerイメージを作成する

管理するドメインは大した量ではないのでDBにはSqliteをチョイス

管理GUIはSqliteに対応した物が無いため、API駆動のPowerDNS Adminを選んでみました。

PowerDNS + SqliteのDockerイメージは見つかったものの、

PowerDNS AdminのDockerイメージは見つからないし・・・・

そもそもこれぐらいならひとまとめにしてもいいじゃない!

ってことでPowerDNS + Sqliteをベースに自分で作ってみました。

[github]

PowerDNS Adminが80番ポートを使用するため、

PowerDNS標準のWebサーバーが8080番ポートに変更になっています。

また、内部運用するに当たり「DNSフォワーダ」の設定が追加されたので

管理外ドメインの問い合わせを外部にフォーワードしてくれます。

2.Dockerコンテナを起動する

$ git clone https://github.com/gittrname/powerdns-sqlite3-gui.git
$ docker build -t powerdns-sqlite3-gui powerdns-sqlite3-gui
$ docker run -p 53:53/tcp -p 53:53/udp -p 80:80 powerdns-sqlite3-gui

起動したらブラウザでGUIにアクセスしまずは管理用アカウントを新規に作成してください。

powerdnsadmin%e3%83%ad%e3%82%b0%e3%82%a4%e3%83%b3%e7%94%bb%e9%9d%a2 powerdnsadmin_%e3%82%a2%e3%82%ab%e3%82%a6%e3%83%b3%e3%83%88%e7%99%bb%e9%8c%b2

作成したアカウントでログインしたらドメインを追加しレコードの設定を行います。

powerdnsadmin_%e3%83%80%e3%83%83%e3%82%b7%e3%83%a5%e3%83%9c%e3%83%bc%e3%83%89 powerdnsadmin_%e3%83%89%e3%83%a1%e3%82%a4%e3%83%b3%e8%bf%bd%e5%8a%a0

digコマンドで動作の確認ができればDNSサーバーの構築は完了です。


$ dig www.ranran.mydns.jp @[DNSサーバーのIP]

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.ranran.mydns.jp @[DNSサーバーのIP]
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35567
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;www.ranran.mydns.jp. IN A

;; ANSWER SECTION:
www.ranran.mydns.jp. 3600 IN A [対象サーバーのIP]

;; Query time: 43 msec
;; SERVER: 192.168.11.102#53(192.168.11.102)
;; WHEN: Thu Oct 27 23:59:11 JST 2016
;; MSG SIZE rcvd: 64

2016年10月20日

既存サーバーのConcrete5データをDockerコンテナに移設する

Filed under: Concrete5,Docker,Linux,OSS,オープンソース — ranpei @ 6:09 AM

Concrete5のデータを移行していきましょう。

やり方はConcrete5公式の「concrete5 サイトを復旧(リストア)する方法」を参考にすればすんなりいきます。

 

1.移設元サーバーから移設データを取り出す

# cd /var/www/html/concrete
// データ格納フォルダをtarで固める
# tar cvf concrete-content.tar blocks/ css/ elements/ files/ helpers/ jobs/ js/ languages/ libraries/ mail/ modules/ packages/ page_types/ single_pages/ sitemap.xml themes/ tooles/ updates/
//SQLデータをエクスポート
# mysqldump -u {ユーザー名} -p {パスワード} {データベース名} >> concrete-export.sql

2.Dockerコンテナに反映させる

コンテンツファイルをDockerコンテナに反映させる。

※ コンテナ名:concrete

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/concrete/concrete-content.tar concrete-content.tar
// concreteコンテナ内にconcrete-content.tarをコピー
# docker cp concrete-content.tar concrete:/var/www/html
// tarファイルを展開
# docker exec concrete tar xvf concrete-content.tar
# docker exec concrete /bin/bash -c "chown www-data:www-data -R /var/www/html"

記事データをMySQLコンテナにインポートする。

※ コンテナ名:mysql

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/concrete/concrete-export.sql concrete-export.sql
// mysqlコンテナ内にconcrete-export.sqlをコピー
# docker cp concrete-export.sql mysql:/tmp/
// インポート
# docker exec mysql /bin/bash -c "mysql -h mysql -u {ユーザー名} -p {パスワード} {データベース名} < /tmp/concrete-export.sql"

もしかしたらディレクトリのパーミッション設定をいじる必要があるかもしれませんが・・・

ブログと違ってまだ新規のページを作成していないので何かあれば追記します。

次回、から内部ツール系サーバーの構築を行っていきます。

既存サーバーのWordPressデータをDockerコンテナへ移設する

Filed under: Docker,Linux,OSS,Wordpress,オープンソース — ranpei @ 4:27 AM

Dockerコンテナ環境の構築が完了しましたので、

既存サーバーのデータをDockerコンテナへ移設します。

※ なお、初期インストール画面での設定は終えているものとして話を進めていきます。

1.移設元サーバーから移設データを取り出す

移設するデータは記事データである”MySQLのdumpファイル”、

画像などのメディアファイルやプラグインなどが格納されている”wp-contentディレクトリ”の2つ。

// WordPress配置ディレクトリに移動 (各々のサーバー環境に合わせて読みかえてください)
# cd /var/www/html/wordpress
// wp-contentフォルダをtarで固める
# tar cvf wp-content.tar wp-content
// SQLデータをエクスポート
# mysqldump -u {ユーザー名} -p {パスワード} {データベース名} >> wordpress-export.sql

2.Dockerコンテナに反映させる

wp-contentディレクトリをDockerコンテナに配置する

※ Dockerコンテナ名:wordpress

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/wordpress/wp-content.tar wp-content.tar
// wordpressコンテナ内にwp-content.tarをコピー
# docker cp wp-content.tar wordpress:/var/www/html
// tarファイルを展開
# docker exec wordpress tar xvf wp-content.tar
# docker exec wordpress /bin/bash -c "chown www-data:www-data -R /var/www/html/wp-content"
// ディレクトリのパーミッションを変更
# docker exec wordpress /bin/bash -c "chmod 777 -R /var/www/html/wp-content/cache && chmod 777 -R /var/www/html/wp-content/uploads"

記事データをMySQLコンテナにインポートする。

※ Dockerコンテナ名:mysql

// SCPでファイルを移動
# cd /tmp
# scp {移設元サーバーIP}:/var/www/html/wordpress/wordpress-export.sql wordpress-export.sql
// mysqlコンテナ内にwordpress-export.sqlをコピー
# docker cp wordpress-export.sql mysql:/tmp/
// インポート
# docker exec mysql /bin/bash -c "mysql -h mysql -u {ユーザー名} -p {パスワード} {データベース名} < /tmp/wordpress-export.sql"

で、ブラウザでアクセスするときちんとデータが反映されていたので

これで、移設完了・・・・・と思っていたらブログの記事を書いているときに

画像をアップロードできない問題が発生しまして・・・・・

調べたところ今回の移設でwordpressの配置パスが変わったため

それに合わせて「メディア設定」>「アップロードするファイルの保存場所」のパス設定を

変更する必要がありましたのでメモしておきます。

アップロードパスの変更

 

これでWordpressデータの移設が完了しました。

2016年10月6日

Concrete5.6 日本語版用のDockerfileを作る

Filed under: Concrete5,Docker,Linux,OSS,オープンソース,PC — ranpei @ 11:51 PM

Dockerのインストールが終わってしまえば後はDocker Hubから

使いたいDockerイメージを持ってきてコンテナを作成するだけなのですが・・・・

Concrete5のコンテナを作成するときに問題があったため少しメモを。。。

 

1.発覚した問題

Concrete5の移行手順を調べているときに分かったのですが・・・

最新の5.7では下位互換がなくなっていたのです!!

今運用しているのは5.6・・・これじゃ移行できないよ・・・・・

5.6を探すもなかなか見つからず・・

さらにDocker Hub上のconcrete5のイメージは大半が本家のソースをDLして作られているために

運よく5.6のイメージが見つかっても日本語表示に不安が・・・・

 

2.だったら作ればいいじゃない!

そんなわけで、Concrete5のイメージは自分で作成することにしました。

で、作成したDockerfileが以下

FROM chriswayg/apache-php

RUN apt-get update && \
    apt-get install -y wget unzip php5-mysql php5-gd && \
    apt-get clean && \
    apt-get -yq autoremove && \
    rm -rf /var/lib/apt/lists/*

RUN cd /tmp && \
    wget -O concrete.zip http://concrete5-japan.org/index.php/download_file/view/1920/45/ && \
    unzip concrete.zip && \
    rm /tmp/concrete.zip && \
    cp -rp /tmp/concrete5.6.3.4.ja/* /var/www/html && \
    chown www-data:www-data -R /var/www/html && \
    chmod 777 -R /var/www/html/config && \
    chmod 777 -R /var/www/html/files && \
    chmod 777 -R /var/www/html/packages && \
    chmod 777 -R /var/www/html/themes && \
    chmod 777 -R /var/www/html/updates && \
    rm -rf /var/www/html/index.html

RUN echo php_value default_charset UTF-8 >> /var/www/html/.htaccess && \
    echo php_value mbstring.language neutral >> /var/www/html/.htaccess && \
    echo php_value mbstring.internal_encoding UTF-8 >> /var/www/html/.htaccess && \
    echo php_flag mbstring.encoding_translation Off >> /var/www/html/.htaccess

EXPOSE 80 443

GitHub⇒gittrname/concrete56-ja

バージョン番号などがファイルに含まれる場合は、

バージョンアップ時に変わることを考慮した作りにするのですが今回は考慮していません。

(5.6がバージョンアップされることはそうそう無いでしょう)

このDockerfileをbuildすることでイメージが作成されます。

 

3.docker-composeで一括作成

最後に自前のDockerfileと公式のMySQLイメージを使って

Concrete5のコンテナ環境を作成していきましょう。

  • フォルダの構成

以下のようにファイルを配置します。

作業Root/
  ├ docker-compose.yml
  ├ concrete56-ja/
  |   └ Dockerfile
  └ mysql/
      └ initdb.d/
          └ create_concrete_database.sql
  • docker-compose.ymlの中身
version: '2'
services:
  #####################
  # concrete5.6-ja
  #####################
  concrete:
    build: concrete56-ja
    container_name: concrete
    links:
      - mysql
  #####################
  # mysql
  #####################
  mysql:
    image: mysql/mysql-server
    container_name: mysql
    volumes:
      - mysqldata:/var/lib/mysql
      - ${PWD}/mysql/initdb.d:/docker-entrypoint-initdb.d
    environment:
      - MYSQL_ROOT_PASSWORD={rootユーザーのパスワード}
volumes:
  mysqldata:
    driver: local

MySQL公式コンテナはdocker-entrypoint-initdb.d配下のSQLやシェルスクリプトをコンテナ作成時に実行するので
それを利用し初期DBと接続用ユーザーの作成を行っています。

SQLはこんな感じ

-- Concrete
CREATE DATABASE IF NOT EXISTS concrete CHARACTER SET utf8;
GRANT all ON concrete.* TO 'concrete'@'%' identified by 'concrete';

 

linksでMySQLコンテナを指定していますので、

IPアドレスを調べなくてもコンテナ名を使ってDockerコンテナ間の通信が可能になっています。

あとは、docker-compose.ymlファイルがある階層で

docker-composeを起動するだけでビルドからコンテナ作成まで一通りやってくれます。


// コンテナ起動

$ docker-compose up -d

// 起動確認

$ docker ps -a

 

作成が終わったら公式のインストール手順に従ってブラウザから初期設定を行うだけです。

2015年9月30日

PHPフレームワーク公開

Filed under: PHP,オープンソース,ソース配布 — ranpei @ 3:40 AM

仕事でPHPフレームワークを使ったときに以下の不満点がふつふつと湧き上がってきた。

・クラス名やメソッド名がURIパスになってしまう。

・各ファイルの配置先があらかじめ決められており自由度がない。

・内蔵ライブラリは便利だが外部ライブラリにもっと良いものがあるのに導入に手間がかかる。

 

上記の一部の不満点はメンバーから上がってきたもので

そのときはクラス名とメソッド名の変更で対応したもののもっとうまいやり方があったのでは?と思っていた。

 

もともとPHPは趣味でやっておりオレオレフレームワークで実装することが主だったため

既存フレームワークの良いところを取り入れつつ上記の不満点を解消できないかと試行錯誤していたものが形になったため

せっかくだから公開してみようとということになった。

 

ダウンロードから設置までの流れはこちらにまとめている。(内容が薄いため今後拡充していく予定)

 

現状ではフレームワークの骨組みはどのように作られているかという勉強用のソースという意味合いが強い。

最終的には小規模なシステム開発に向いたフレームワークとしていきたい。

(さすがに中大規模は無理なのでメジャーなPHPフレームワークを使用していただきたい。)

 

あと、ソース類はgithubなどのサービスを利用して配布していければ良いなーとか考えていたり・・・

2014年5月23日

concrete5で日本語が入力できない・・・

Filed under: apache,OSS,PHP,オープンソース — ranpei @ 12:53 AM

現在ブログをCMSツールに移行する計画を実行中なのだが、
その過程で起こった問題を記録のためにメモって置く。

タイトルの通りConcrete5日本語版をインストールして、
さあ、記事を編集だ~~と思っていた矢先
日本語を入力しても化けて表示される問題にぶち当たった。

公式サイトの『よくあるインストール時の問題』に日本語が入力できない場合について書かれているのだが
「これは、お使いのサーバーの設定が、きちんと行われていない為に発生する問題だと思われます。”だと・・・
公式にも書いている.htaccessの記載もやっとるっちゅ~ねん。
MySQLの文字コードもUTF-8だし・・・

いろいろ試してみたところ.htaccessに以下の設定を追加することで解決しました。

php_flag mbstring.encoding_translation Off
Older Posts »

Powered by WordPress