Seit dem Update auf lighttpd 1.5 gab es Problem mit den alten rewrite rules. [1]
Hier sind welche für lighttpd 1.5.
-- rewrite rules for wordpress http://greatwebguy.com/web-servers/lighttpd/lighttpd-15-rewrite-rules-for-wordpress-22/
url.rewrite-once = (
"^/(wp-.+).*/?" => "$0",
"^/(sitemap.xml)" => "$0",
"^/(xmlrpc.php)" => "$0",
"^/keyword/([A-Za-z_0-9\-]+)/?$" => "/index.php?keyword=$1",
"^/.*?(\?.*)?$" => "/index.php$1"
)
There was a time, when I shared a blog. This post was written by Stephan. See all blogpost from him or stalk him on github.
Hier möchte ich die wichtigsten Schritte festhalten, um mit dem sehr tollen wicked_pdf plugin PDF Dateien zu erstellen. Dabei soll vor allem die Integrierung von Bilddateien beschrieben werden, die ich mit dem on-the-fly processing/encoding framework dragonfly erzeuge.
Plugin installieren
cd /path/to/rails_app
rails plugin install git://github.com/mileszs/wicked_pdf.git
Statische Version von wkhtmltopdf herunterladen und in neu angelegten Rails Ordner “bin” legen
cd /path/to/rails_app
mkdir bin
# passende statische Version für wkhtmltopdf in diesem Ordner abspeichern
Neuen Initializer in der config für wicked_pdf erstellen mit folgendem Inhalt:
#Datei /path/to/rails_app/config/initializers/wicked_pdf.rb
WickedPdf.config = {
#:wkhtmltopdf => '/usr/local/bin/wkhtmltopdf',
#:layout => "pdf.html"
:exe_path => Rails.root.join('bin', 'wkhtmltopdf-i386').to_s,
}
Den exe_path müsst ihr auf den Namen eurer geladenen wkhtmltopdf-Datei anpassen. Bei mir ist es “wkhtmltopdf-i386”.
In eurem Controller gibt ihr dann an, welche Action auf PDF antworten soll. Die möglichen Optionen findet ihr hier
class MyController < ApplicationController
def show
#...
respond_to do |format|
format.html # show.html.erb
format.xml { render :xml => @my }
format.pdf do
render :pdf => "my",
:layout => "pdf.html",
:disposition => "inline",
:show_as_html => params[:debug].present?
end
end
end
end
View show.pdf.erb anlegen
#view
<h1>Hallo show von MyController</h1>
In diesem View könnt ihr jetzt ganz normales HTML schreiben, das mit dem entsprechenden Styling für die PDF formatiert wird.
GANZ wichtig:
Es gibt zwei Möglichkeiten, die Urls der verwendeten AssetHelper von Rails absolut zu gestalten:
In eurer Enviromentkonfiguration (development.rb, production.rb, test.rb) könnt ihr asset hosts festlegen
ActionController::Base.asset_host = "assets.example.com"
Dies kann aber bei größeren Projekten leicht zu Problemen führen, wenn man mehrere asset hosts verwendet (ist aber mit entsprechendem Aufwand möglich).
Ich lasse mir im entsprechenden View alle Angaben zum Request ausgeben und erzeuge daraus die absoluten Url’s. Dies funktioniert vor allem in Verbindung mit Dragonfly perfekt:
#Ermittlung des request, ergibt z.B. http://localhost:3000 bei einer Standard-Rails-Anwendung
<% prefix=request.protocol+request.env['HTTP_HOST'] %> # => http://localhost:3000
# project mit Draognfly macro "cover_image"
<%= image_tag prefix+project.cover_image.url %>
Alternativ kann auch eine Option von Dragonfly genutzt werden, bei dem der Host festgelegt werden kann:
<% prefix=request.protocol+request.env['HTTP_HOST'] %>
<%= image_tag project.cover_image.url(:host => prefix) %>
Wenn ihr in eurer Testumgebung aber immer noch keine generierten Bilder in der PDF vorfindet oder die PDF Generierung von wkhtmltopdf endlos weiterläuft, müsst ihr in eurer “development.rb” Datei noch folgendes setzen.
config.consider_all_requests_local = false
Ich hoffe, ich konnte euch weiterhelfen
Bis zum nächsten Mal
Lighttpd Trunk besorgen [1] und kompilieren.
apt-get install subversion pkg-config libtool automake libglib2.0-dev
svn checkout svn://svn.lighttpd.net/lighttpd/trunk/
cd trunk
./autogen.sh
./configure --prefix=/usr
make
make install
Statt ‘make install’ kann man auch ein ‘checkinstall’ versuchen.
Für PHP mit FCGI spawn-fcgi besorgen und kompilieren. [2]
svn co svn://svn.lighttpd.net/spawn-fcgi/trunk spawn-fcgi
cd spawn-fcgi
./autogen.sh
./configure --prefix=/usr
make
make install
Statt ‘make install’ kann man auch ein ‘checkinstall’ versuchen.
spawn-fcgi starten. [3]
/usr/bin/spawn-fcgi -s /tmp/php-fastcgi.sock -f /usr/bin/php-cgi -u www-data -g www-data -C 5 -P /var/run/spawn-fcgi.pid
lighttpd.conf anpassen
$PHYSICAL["existing-path"] =~ "\.php$" {
proxy-core.balancer = "round-robin"
proxy-core.protocol = "fastcgi"
proxy-core.allow-x-sendfile = "enable"
proxy-core.backends = ( "unix:/tmp/php-fastcgi.sock" )
proxy-core.max-pool-size = 16
proxy-core.rewrite-request = (
"_pathinfo" => ( "\.php(/.*)" => "$1" )
)
}
lighttpd neustarten
/etc/init.d/lighttpd restart
Fertig.
There was a time, when I shared a blog. This post was written by Stephan. See all blogpost from him or stalk him on github.
RefineryCMS in der Rails 3 Version lieferte einige Änderungen betreffend des Umgangs mit Bildern und Dateien. Es wurde nun auf die Verwendung von Dragonfly gesetzt, die als Rack Middleware in der Railsanwendungen betrieben wird.
Folgend eine kleine Gedankenstütze für die Verwendung in den Active Record Models, um Verbindungen mit den neuen Image und Resource Plugins zu erreichen:
Refinery Engine benutzt eine Bilddatei: z.B: eine Galerie hat ein Titelbild
Model:
class Gallery < ActiveRecord::Base
belongs_to :image
#Galerie-Migration muss eine Spalte image_id (Rubykonvention) besitzen oder kann mit :foreign_key => :eigener_name angepasst werden
#belongs_to image, :foreign_key => :title_image
end
View:
<%= form_for([:admin, @gallery]) do |f| %>
#andere Modelattribute z.B. Titel
<div class='field'>
<%= f.label :image_id -%>
<%= render :partial => "/shared/admin/image_picker", :locals => {
:f => f,
:field => :image_id,
:image => @gallery.image,
:toggle_image_display => false
} %>
#image_picker speichert die id des ausgewählten Bildes im Feld image_id
</div>
<% end %>
Refinery Engine benutzt mehrere Bilddateien: z.B: ein Projekt hat ein Titelbild und ein Statusbild
Model:
class Project < ActiveRecord::Base
belongs_to :title_image, :class_name => "Image"
belongs_to :status_image, :class_name => "Image"
#Projekt-Migration muss die Spalten title_image_id und status_image_id (Rubykonvention) besitzen oder kann mit :foreign_key => :eigener_name angepasst werden siehe Beispiel zuvor
end
View:
<%= form_for([:admin, @project]) do |f| %>
#andere Modelattribute z.B. Titel
<div class='field'>
<%= f.label :title_image_id -%>
<%= render :partial => "/shared/admin/image_picker", :locals => {
:f => f,
:field => :title_image_id,
:image => @project.title_image,
:toggle_image_display => false
} %>
# image_picker speichert die id des ausgewählten Titelbildes im Feld title_image_id
</div>
<div class='field'>
<%= f.label :status_image_id -%>
<%= render :partial => "/shared/admin/image_picker", :locals => {
:f => f,
:field => :status_image_id,
:image => @project.status_image,
:toggle_image_display => false
} %>
# image_picker speichert die id des ausgewählten Statusbildes im Feld status_image_id
</div>
<% end %>
Will man eine Galerie mit vielen Bildern abbilden, muss man eine has_many Relation erzeugen
Model:
#gallery.rb
class Gallery < ActiveRecord::Base
#Verknüpfungstabelle zur Join-Tabelle
has_many :galleryitems, :dependent => :destroy, :order => "galleryitems.position ASC"
#Verknüpfungstabelle zur Image Engine von RefineryCMS
has_many :images :through => :galleryitems
end
#galleryitem.rb
class Galleryitem < ActiveRecord::Base
belongs_to :image
belongs_to :gallery
#Galleryitem-Migration muss die Spalten image_id und gallery_id (Rubykonvention) besitzen oder kann mit :foreign_key => :eigener_name angepasst werden
end
Generell finde ich die gesamte Logik, die Bilder- und Datei-Uploads in RefineryCMS in einer Datenbank abzuspeichern nicht sehr komfortabel. Es führt zu Problemen bei Änderung von Dateinamen und lässt das Hochladen von Bildern zu einer sehr langwierigen Angelegenheit werden (Refinery 0.9.9 wird bereits HTML5 Multiupload ermöglichen). Ich muss noch einige Recherchen beenden (Rails Metal, Rack und vor allem Dragonfly) und vielleicht kann ich bald ein neues Filebrowser-Plugin für RefineryCMS vorstellen, bei dem ich mich konzeptionell an den Filebrowser von Typo3 orientiert habe.
Ich will nicht zu viel versprechen, aber demnächst mehr von mir
Gruß skeller1
There was a time, when I shared a blog. This post was written by Stephan. See all blogpost from him or stalk him on github.
Bei Code-Änderungen im Rails lib Ordner muss zwingenderweise immer der Server neugestartet werden. Dies ist bei der aktiven Entwicklung natürlich sehr störend. Mit folgender initializer-Datei kannst du dieses Verhalten unterdrücken und es werden bei jedem Request die Dateien im lib-Ordner neu eingelesen. Lege dafür eine neue Initializer-Datei unter config/initalizers an. Der Dateinamen kann beliebig gewählt werden.
if Rails.env == "development"
lib_reloader = ActiveSupport::FileUpdateChecker.new(Dir["lib/**/*"], true) do
Rails.application.reload_routes!
end
ActionDispatch::Callbacks.to_prepare do
lib_reloader.execute_if_updated
end
end
Das sieht zwar jetzt alles gut aus, doch wir müssen in der config/application.rb noch das automatische Laden der Libs aktivieren.
config.autoload_paths += %W( #{config.root}/lib )
Ein Dank geht an den User pbhogan, der auf StackOverflow die Lösung veröffentlicht hat (Link Original Beitrag).
Anmerkung:
Diese Lösung funktioniert leider nicht im lib Ordner von Rails Engines. Dort müssen sich die Entwickler noch etwas einfallen lassen.
Viel Spaß