I'm trying to combine Padrino with Sinatra-Assetpack, without success.
This is my Gemfile:
source :rubygems
gem 'rake'
gem 'sinatra-flash', :require => 'sinatra/flash'
# Component requirements
gem 'haml'
# Assets requirements
gem 'sinatra-assetpack', :require => 'sinatra/assetpack'
# Test requirements
# Padrino Stable Gem
gem 'padrino', '0.10.6'
in my app/app.rb file I set:
require 'sinatra/assetpack'
class Coffee < Padrino::Application
register Padrino::Rendering
register Padrino::Mailer
register Padrino::Helpers
register Sinatra::AssetPack
assets {
serve '/js', from: '/app/assets/javascripts'
serve '/css', from: '/app/assets/stylesheets'
css :main, ['/css/main.css']
js :application, ['/js/application.js']
}
enable :sessions
end
my javascript files are in /app/assets/javascripts and css files in /app/assets/stylesheets, but Padrino respond with a 404 for both /css/main.css and /js/application.js
Any ideas?
Thanks
Figured out the issue, in my application anyway, but from the looks of your app.rb code it's probably the same for you;
Assetpack serves files from the directories you specify in your serve calls, relative to your application's root. In padrino, the application root is yourapplication/app, so if you tell assetpack to serve css from /app/assets/stylesheets for instance, its really looking for the files in yourapplication/app/app/assets/stylesheets.
The second part of the problem was that in the AssetPack docs, it shows the code
set :root, File.dirname(__FILE__)
before the register Sinatra::AssetPack line, which I assume is setting the application's root directory properly so that AssetPack will look in the root application directory instead of app. However, even If I modified that call to set to go up one directory from the app.rb file (since it sits in the app dir in Padrino), it didn't seem to have any effect on AssetPack.
In short, modifying the from: paths in the `serve' calls to be relative to your app directory should fix the problem. In your case, they should be:
serve '/js', from: '/assets/javascripts'
serve '/css', from: '/assets/stylesheets'
Related
TL;DR
Does PHP 5.4 built-in webserver have any bug or restriction about relative paths? Or does it need to be properly (and additionally) configured?
When I used to programming actively I had a system working under URI routing using these lines in a .htaccess file:
RewriteEngine On
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php [L]
The FrontController received the Request, find the proper route from given URI in a SQLITE database and the Dispatcher call the the Action Controller.
It worked very nicely with Apache. Today, several months later I decided to run my Test Application with PHP 5.4 built-in webserver.
First thing I noticed, obviously, .htaccess don't work so I used code file instead:
<?php
if( preg_match( '/\.(?:png|jpg|jpeg|gif)$/', $_SERVER["REQUEST_URI"] ) ) {
return false;
}
include __DIR__ . '/index.php';
And started the webserver like this:
php.exe -c "php.ini" -S "localhost:8080" "path\to\testfolder\routing.php"
So far, so good. Everything my application need to bootstrap could be accomplished by modifying the include_path like this:
set_include_path(
'.' . PATH_SEPARATOR . realpath( '../common/next' )
);
Being next the core folder of all modules inside a folder for with everything common to all applications I have. And it doesn't need any further explanation for this purpose.
None of the AutoLoader techniques I've ever saw was able to autoload themselves, so the only class manually required is my Autoloader. But after running the Test Application I received an error because my AutoLoader could not be found. o.O
I always was very suspicious about realpath() so I decided to change it with the full and absolute path of this next directory and it worked. It shouldn't be needed to do as I did, but it worked.
My autoloader was loaded and successfully registered by spl_autoload_register(). For the reference, this is the autoloading function (only the Closure, of course):
function( $classname ) {
$classname = stream_resolve_include_path(
str_replace( '\\', DIRECTORY_SEPARATOR, $classname ) . '.php'
);
if( $classname !== FALSE ) {
include $classname;
}
};
However, resources located whithin index.php path, like the MVC classes, could not be found. So I did something else I also should not be doing and added the working directory to the include_path. And again, manually, without rely on realpath():
set_include_path(
'.' . PATH_SEPARATOR . 'path/to/common/next'
. PATH_SEPARATOR . 'path/to/htdocs/testfolder/'
);
And it worked again... Almost! >.<
The most of Applications I can create with this system works quite well with my Standard Router, based on SQLITE databases. And to make things even easier this Router looks for a predefined SQLITE file within the working directory.
Of course, I also provide a way to change this default entry just in case and because of this I check if this file exist and trigger an error if it doesn't.
And this is the specific error I'm seeing. The checking routine is like this:
if( ! file_exists( $this -> options -> dbPath ) ) {
throw RouterException::connectionFailure(
'Routes Database File %s doesn\'t exist in Data Directory',
array( $this -> options -> dbPath )
);
}
The dbPath entry, if not changed, uses a constant value Data/Routes.sqlite, relatively to working directory.
If, again, again, I set the absolute path manually, everything (really) works, the the Request flow reached the Action Controllers successfully.
What's going on?
This a bug in PHP's built-in web server that is still not fixed, as of PHP version 5.6.30.
In short, the web server does not redirect to www.foo.com/bar/ if www.foo./bar was requested and happens to be a directory. The client being server www.foo.com/bar, assumes it is a file (because of the missing slash at the end), so all subsequent relative links will be fetched relative to www.foo.com/instead of www.foo.com/bar/.
A bug ticket was opened back in 2013 but was mistakenly set to a status of "Not a Bug".
I'm experiencing a similar issue in 2017, so I left a comment on the bug ticket.
Edit : Just noticed that #jens-a-koch opened the ticket I linked to. I was not awar of his comment on the original question.
I installed Composer and a SDK for Mailgun's service. These are the steps i followed:
# current directory
cd ~
# Install Composer
curl -sS https://getcomposer.org/installer | php
# Add Mailgun as a dependency
php composer.phar require mailgun/mailgun-php:~1.7
According to the instructions, all I did after that was (index.php):
<?php
require 'vendor/autoload.php';
use Mailgun\Mailgun;
# First, instantiate the SDK with your API credentials and define your domain.
$mg = new Mailgun("key-my-key-goes-here-987654321");
$domain = "somedomain.com";
Then, I tried to get the list of bounced emails:
$data = $mg->get("$domain/bounces", array('limit' => 15, 'skip' => 0));
var_dump($data);
...and I'm getting this error:
Warning: require(vendor/autoload.php): failed to open stream: No such
file or directory in /var/www/html/index.php on line 2 Fatal error:
require(): Failed opening required 'vendor/autoload.php'
(include_path='.:/usr/share/pear:/usr/share/php') in
/var/www/html/index.php on line 2
So I'm guessing it has something to do with composer's installation/configuration perhaps? Thanks for any help...
The way you programmed it, you must have the following files all in the same directory:
composer.json
index.php (your test script)
And you must have run the composer require command while being inside this directory. This will also create a directory named vendor here, and add plenty of files, amongst them vendor/autoload.php.
If however your test script isn't in this location, the require call will not find the file where you tell PHP to find it. This isn't any failure of Composer, but simply the fact that you have to include that file according to your situation, not by copy&paste code. If you change the path of your test script, you have to change the path of the vendor directory as well.
I am trying to load a graph in fuseki. The server is working as it should.
But when I try s-put inside the fuseki folder it tells me s-put is not found?!
hdeus$ ls
DEPENDENCIES config.ttl s-delete
Data fuseki s-get
LICENSE fuseki-server s-head
NOTICE fuseki-server.bat s-post
ReleaseNotes.txt fuseki-server.jar s-put
config-examples.ttl fuseki_config.ttl s-query
config-inf-tdb.ttl log4j.properties s-update
config-tdb.ttl pages s-update-form
hdeus$ sudo ./s-put http://localhost:3030/ds/data default Data/books.ttl
sudo: ./s-put: command not found
Any idea what the problem might be? I tried copy/paste s-put from the ls output but stil nothing... I am working in mac os X
Is the file executable? If you unpacked from the zip file, you need to set the s-* executable. Also, you need ruby installed.
I'm writing a classic style sinatra app, and trying to package my scss files with sinatra-assetpack, but it's not working.
This is my main web file:
require 'rubygems'
require 'sinatra'
require 'haml'
require 'sass'
require 'compass'
require 'sinatra/assetpack'
set :root, File.dirname(__FILE__)
set :environment, ENV["RACK_ENV"] || "development"
configure do
Compass.configuration do |config|
config.project_path = File.dirname(__FILE__)
config.sass_dir = 'views/stylesheets'
end
set :haml, { :format => :html5 }
set :scss, Compass.sass_engine_options
assets {
serve '/javascripts', from: 'public/javascripts'
serve '/stylesheets', from: '/stylesheets'
# The second parameter defines where the compressed version will be served.
# (Note: that parameter is optional, AssetPack will figure it out.)
js :lib, '/javascripts/script.js', [
'/javascripts/lib/modernizr-2.5.3.js',
'/javascripts/lib/underscore-min.js',
'/javascripts/lib/slides.min.jquery.js',
'/javascripts/lib/jquery.scrollTo-1.4.2-min.js'
]
css :app, '/stylesheets/screen.css', [
'/stylesheets/screen.css',
'/fonts/meta.css'
]
js_compression :jsmin
css_compression :sass
}
end
I'm using this in my layout file:
= css :app, :media => 'screen'
The screen.scss file is stored in /views/stylesheets/screen.scss, and the meta.css is in /public/fonts/meta.css. Are the references to screen.css incorrect? Should they be served from a different directory?
Also I had this in my main web file
get '/stylesheets/screen.css' do
content_type 'text/css', :charset => 'utf-8'
scss :'stylesheets/screen'
end
Putting it in or removing it didn't fix anything - is this route necessary?
You should not keep your get '/stylesheets/screen.css' route anymore.
I also noticed you have compass in your Gemfile / app files. Sinatra AssetPack notes that it is not compatible with compass. You can include sinatra/support though to use it such as their example application here.
Change your serve '/stylesheets', from: '/stylesheets' statement to serve '/stylesheets', from: '/views/stylesheets' to reflect where you would like to serve the sass files from.
After all that, you should be able to serve your javascript and scss like below:
= css :app, :media => 'screen'
= js :lib
Trying to get the hang of deploying a rails 3.1 App ...
Based on what I've read, I've put the following code in my deploy.rb:
before "deploy:symlink", "assets:precompile"
namespace :assets do
desc "Compile assets"
task :precompile, :roles => :app do
run "cd #{release_path} && rake RAILS_ENV=#{rails_env} assets:precompile"
end
end
But to tell you the truth, I can't notice any difference with or without it. Is there something I'm missing here?
EDIT* found the answer:
http://spreecommerce.com/blog
To pre-compile assets for production you would normally execute the following rake task (on the production server).
$ bundle exec rake assets:precompile
This would write all the assets to the public/assets directory while including an MD5 fingerprint in the filename for added caching benefits.
NOTE: In production all references to assets from views using image_tag, asset_path, javascript_include_tag, etc. will automatically include this fingerprint in the file name so the correct version will be served.
There is configuration to do, but it should be correctly set by default. Get in your config/application.rb and see if you find this:
if defined?(Bundler)
# If you precompile assets before deploying to production, use this line
Bundler.require(*Rails.groups(:assets => %w(development test)))
# If you want your assets lazily compiled in production, use this line
# Bundler.require(:default, :assets, Rails.env)
end
...
config.assets.enabled = true
You should also have those in your production.rb file:
# Compress JavaScripts and CSS
config.assets.compress = true
# Don't fallback to assets pipeline if a precompiled asset is missed
config.assets.compile = false
This should be set that way. Is it?