Hi Zend framework guys,
I have a question for you :
There is production , development , testing etc that we can set .
I assume we have 3 different db for these .
But I have a doubt how do we access the url for testers and developers ?
Do we need to pass as a GET value and set whether its development , or for testing ? Or is there any other way ?
http://localhost/ is the url and I am the developer who uses it, How do we give the url for testers ? I am not a server admin , so if you guys have some other techniques using the same code base ?
Or do I want to have 3 code base itself for testing , development , production etc . For production its OK :) , but just an example .
The question was asked by some of my friends when I introduced them #ZF , but I was not sure whether I am right when passing it as a GET value and setting it .
ie like site/?version=dev or something like that :) . If you have an answer I love to hear .
Edit :
I was looking for a way like #David Weinraub says "Are you saying you want to use a single virtual host, a single location, but be able to force the execution context into dev, testing, production mode? That's kind of unusual."
Answer by #Iznogood is also right . But I was looking for a way #David Weinraub says . So marking it as correct for its a kind of unusual.
Thank you guys for your helps.
Are you saying you want to use a single virtual host, a single location, but be able to force the execution context into dev, testing, production mode? That's kind of unusual.
If not, that is, if you will deploy dev, testing, production to different servers and (which strikes me as the more common arrangement), I agree with #izogood: Issue your SetEnv directive either in .htaccess or upstream at the vhost level.
Since many of my projects don't have a formal "build process" - just a straight FTP upload, often to shared hosting; kind of basic, I know - I prefer to keep my .htaccess free of deployment-specific content. As a result, I tend to issue the SetEnv directive at the vhost level on my local dev machine, and then let the APP_ENVIRONMENT constant - defined in public/index.php - default to 'production'.
in your .htaccess if you use one thereshould be
SetEnv APPLICATION_ENV production
Wich is where you would switch between the different environment.
So on your stagin server its
SetEnv APPLICATION_ENV staging
on your dev server
SetEnv APPLICATION_ENV development
etc...
Assuming you setup your db in application.ini.
Related
I have a ZF3 project with a controller which opens excel-files and compares them with an template which will be openened, too.
On my development notebook (xampp) everything works fine, at my production system (ubuntu) the phpspreadsheet causes errors (I think it is the one).
here a snippet from my code:
$fileName="./public/files/" . $fileName; //.\ neu
echo $fileName;
$template= new Spreadsheet();
$importdcl= new Spreadsheet();
$template= \PhpOffice\PhpSpreadsheet\IOFactory::load('./public/files/Template_DCL_final.xlsx');
$importdcl= \PhpOffice\PhpSpreadsheet\IOFactory::load( $fileName);
echo "filename geladen";
I already have the folders in non relative paths because basePath() doesn't work, it won't give any result.
The echo statement is just because the server log won't give any errors. On my development system I get the echo text on my production system the error seems to be at the load statements.
First question: How could I use relative paths in here?
Second question: How can I get an idea wether is something wrong with the spreadsheet class?
This is what composer loaded:
"phpoffice/phpspreadsheet" : "dev-develop",
Is it a problem, because it has this dev version? At this point I'm quite confused because I played with the pathes of the files, I changed the rights manually in the folder, I checked server logs and now I don't have any idea left.
Here the rights in the folder:
Any helpful suggestions appreciated.
Answer (hopefully) to the first question: if your application is based on ZendSkeletonApplication, then you can use paths relative to your application root (from index.php):
/**
* This makes our life easier when dealing with paths. Everything is relative
* to the application root now.
*/
chdir(dirname(__DIR__));
So if your data files are located in <application root>/public/files, then you should be able to read them from controller/service/etc. using public/files/<file name> path. You can test it with eg. the file_exists function.
I’m unable to answer your second question, but here are some suggestions (OK, questions…):
what is the status code of your (production) server’s response?
Do you have read/write permissions to the data files from the server’s account (www-data?)?
Does phpspreadsheet depend on any PHP extensions? Do you have them installed on both your development machine and the server?
What PHP version is installed on the server? Do you or phpspreadsheet use any features that may be unavailable on that version?
Try running your project not through Apache, but with PHP’s builtin server (but don’t do it long-term) and try to reproduce the issue.
According to the Ruby on Rails Guide: Caching, caching is disabled by default in the development and testing environments. If I make a small CSS change, run rails server and access my site at localhost:3000, I can see my change. However, if I access my rails server on my iPhone at 10.0.1.2:3000, the CSS doesn't update, even Chrome in Incognito Mode. When I try different iPhone that has an empty cache, the change is there.
I found a stack overflow post that described the same problem. Here were the suggested solutions:
Remove the public/assets directory. I don't have one.
Add config.serve_static_assets = false to environments/development.rb. It's already there.
Delete /tmp/cache/assets, add config.serve_static_assets = false to environments/development.rb and restart the server. I tried this and it didn't work.
Here's my relevant environments/development.rb config:
# In the development environment your application's code is reloaded on
# every request. This slows down response time but is perfect for development
# since you don't have to restart the web server when you make code changes.
config.cache_classes = false
# Show full error reports and disable caching
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
I'm pretty sure this is happening because Rails only does fingerprinting in production: http://guides.rubyonrails.org/asset_pipeline.html#in-production
This means that in development browsers that are more cache-aggressive can run into this issue.
Try adding this to your development.rb:
config.assets.digest = true
Or more preferable something conditional for when you're doing mobile development
# One of the few exceptions I'd make to a no ENV variables rule
# for my rails environment config files
config.assets.digest = true if ENV["MOBILE_DEBUG"]
How are use accessing your local machine via your iphone ?
have you configured any network settings or you push it to a different server and access from there, because the thing is if you are pusing it to a different server , that sever might be running in the production mode.
HTH
I don't have an iPhone to test, but it sounds like a normal browser caching issue. Try these instructions for clearing the browser cache. If that works, you'll need to do it each time you update your CSS (or J
I had a similar problem. It happened because my config/environments/development.rb had contained config.asset_host = 'http://localhost:3000'
I've removed it and all works fine.
I would like to deploy a nestacms blog on webbynode by using the webbynode gem as allways I do with rails. Altough Webbynode seem to support Sinatra and Rack application easily, I get a WARNING during deployment stating that the application will not run smoothly because it lacks a public folder:
WARNING: Missing public folder in your Rack app, it'll not run smoothly!
Actually the rapid application development (RAPP webbynode gem) sets the need of a public folder into the Nginx configuration:
server {
listen 80;
server_name super_duper_blog.webbyapp.com ;
root /var/rapp/super_duper_blog/public/;
passenger_enabled on;
}
Instead this is my nestacms config.ru:
require 'rubygems'
require 'bundler/setup'
Bundler.require(:default)
require 'nesta/app'
Nesta::App.root = ::File.expand_path('.', ::File.dirname(__FILE__))
run Nesta::App
It would be nice if the author and SO user Graham Ashton could jump in and help me. Anyway, how could I get around the problem?
UPDATE
After creating the project, with nesta new you nedd to:
Create a public folder manually
Add some content in it. Say for ex. humnans.txt and favicon.ico
git add . and git commit -m "added public with humans and favicon"
wn push
And your nestacms website will go on line at a private webbynode address (blog.webbyapp.com)
Then you can use wn changedns www.example.com to make your site available for the masses
I've never used webbynode, so I'm not sure quite how its set up. Have you seen the Nginx passenger install guide? Could be useful:
http://modrails.com/documentation/Users%20guide%20Nginx.html#deploying_a_rack_app
It says you need public/ and tmp/, so I'm inclined to believe it.
Did you try making these directories yourself? Does the site actually start up? How are you deploying your site to the webbynode?
All my Sinatra apps are deployed with Vlad (see http://effectif.com/articles/deploying-sinatra-with-vlad) which takes care of creating public/ and tmp/ for you. It also touches tmp/restart.txt (see the Passenger guide I linked to above) when you deploy a new version of the site if you tell it that you're using Passenger. Capistrano also works fine (and is more extensively documented these days).
What is the difference on a Wamp or Web Server for the definition of $_SERVER['DOCUMENT_ROOT'] and where does it get defined on both?
And the reason I ask is I have a bunch of live websites that use the $_SERVER['DOCUMENT_ROOT'] definition.
On the live websites, $_SERVER['DOCUMENT_ROOT'] works perfectly.
On wamp server locally, it shows $_SERVER['DOCUMENT_ROOT'] as C:/wamp/www even though I have virtual hosts set up. Everything on wamp works except for the $_SERVER['DOCUMENT_ROOT'] declaration.
I used a php script suggested as a fix. The prepend_script set in auto_prepend_file in php.ini:is as follows:
auto_prepend_file = c:/wamp/www/prepend_script.php
$basePath = dirname(__FILE__); // assuming this script is in c:/wamp/www
$projectPath = preg_replace('#('.$basePath.'/[^/]+)/.*#i', '\\1', $_SERVER['PHP_SELF']);
$_SERVER['DOCUMENT_ROOT'] = $projectPath;
What that did was change the$_SERVER['DOCUMENT_ROOT'] from C:/wamp/www to /itsaboutwirelessnetworks/index.php
When in actuality for it to function properly it should be C:/wamp/www/itsaboutwirelessnetworks and not /itsaboutwirelessnetworks/index.php as the prepend script did.
So in order for myself and others to understand how this can affect them, I would appreciate an explanation of why it works on my live server and not the wamp server.
Hence the original question:
What is the difference on a Wamp or Live Web Server for the definition of $_SERVER['DOCUMENT_ROOT'] and where does it get defined on both?
The documentation says about DOCUMENT_ROOT: (emph mine)
The document root directory under
which the current script is executing,
as defined in the server's
configuration file.
So you should look at your config file and check if there is something strange there i'd say.
(I think that unless you've changed it, C:/wamp/www sounds like a valid value to assign to your document-root. If it should be something else, that must be defined in the config of the virtual host)
This seems like a bug in Apache, as it's defined in the Apache httpd.conf file.
http://www.devcha.com/2010/02/solved-incorrect-value-for.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=26052
Apache/php/mysql websites are most often run on Linux servers and you're developing on Windows, the large differences between them could well account for the different bug behaviour.
If I have a greenfield project, what is the best practice Perl based configuration module to use?
There will be a Catalyst app and some command line scripts. They should share the same configuration.
Some features I think I want ...
Hierarchical Configurations to cleanly maintain different development and live settings.
I'd like to define "global" configurations once (eg, results_per_page => 20), have those inherited but override-able by my dev/live configs.
Global:
results_per_page: 20
db_dsn: DBI:mysql;
db_name: my_app
Dev:
inherit_from: Global
db_user: dev
db_pass: dev
Dev_New_Feature_Branch:
inherit_from: Dev
db_name: my_app_new_feature
Live:
inherit_from: Global
db_user: live
db_pass: secure
When I deploy a project to a new server, or branch/fork/copy it somewhere new (eg, a new development instance), I want to (one time only) set which configuration set/file to use, and then all future updates are automatic.
I'd envisage this could be achieved with a symlink:
git clone example.com:/var/git/my_project . # or any equiv vcs
cd my_project/etc
ln -s live.config to_use.config
Then in the future
git pull # or any equiv vcs
I'd also like something that akin to FindBin, so that my configs can either use absolute paths, or relative to the current deployment. Given
/home/me/development/project/
bin
lib
etc/config
where /home/me/development/project/etc/config contains:
tmpl_dir: templates/
when my perl code looks up the tmpl_dir configuration it'll get:
/home/me/development/project/templates/
But on the live deployment:
/var/www/project/
bin
lib
etc/config
The same code would magically return
/var/www/project/templates/
Absolute values in the config should be honoured, so that:
apache_config: /etc/apache2/httpd.conf
would return "/etc/apache2/httpd.conf" in all cases.
Rather than a FindBin style approach, an alternative might be to allow configuration values to be defined in terms of other configuration values?
tmpl_dir: $base_dir/templates
I'd also like a pony ;)
Catalyst::Plugin::ConfigLoader supports multiple overriding config files. If your Catalyst app is called MyApp, then it has three levels of override: 1) MyApp.pm can have a __PACKAGE__->config(...) directive, 2) it next looks for MyApp.yml in the main directory of the app, 3) it looks for MyApp_local.yml. Each level may override settings in each other level.
In a Catalyst app I built, I put all of my immutable settings in MyApp.pm, my debug settings in MyApp.yml, and my production settings in MyApp_<servertype>.yml and then symlinked MyApp_local.yml to point at MyApp_<servertype>.yml on each deployed server (they were all a little different...).
That way, all of my config was in SVN and I just needed one ln -s step to manually config a server.
Perl Best Practices warns against exactly what you want. It states that config files should be simple and avoid the sort of baroque features you desire. It goes on to recommend three modules (none of which are Core Perl): Config::General, Config::Std, and Config::Tiny.
The general rational behind this is that the editing of config files tends to be done by non-programmers and the more complicated you make your config files, the more likely they will screw them up.
All of that said, you might take a look at YAML. It provides a full featured, human readable*, serialization format. I believe the currently recommend parser in Perl is YAML::XS. If you do go this route I would suggest writing a configuration tool for end users to use instead of having them edit the files directly.
ETA: Based on Chris Dolan's answer it sounds like YAML is the way to go for you since Catalyst is already using it (.yml is the de facto extension for YAML files).
* I have heard complaints that blind people may have difficulty with it
YAML is hateful for config - it's not non-programmer friendly partly because yaml in pod is by definition broken as they're both white-space dependent in different ways. This addresses the main problem with Config::General. I've written some quite complicated config files with C::G in the past and it really keeps out of your way in terms of syntax requirements etc. Other than that, Chris' advice seems on the money.