CI框架 -- 开发环境、生产环境

开发者常常希望当系统运行在开发环境或生产环境中时能有不同的行为, 例如,在开发环境如果程序能输出详细的错误信息将非常有用,但是在 生产环境这将造成一些安全问题。

ENVIRONMENT 常量

CodeIgniter 默认使用 $_SERVER[‘CI_ENV‘] 的值作为 ENVIRONMENT 常量, 如果 $_SERVER[‘CI_ENV‘] 的值没有设置,则设置为 ‘development‘。在 index.php 文件的顶部,你可以看到:

define(‘ENVIRONMENT‘, isset($_SERVER[‘CI_ENV‘]) ? $_SERVER[‘CI_ENV‘] : ‘development‘);

1、$_SERVER[‘CI_ENV‘] 的值可以在 .htaccess 文件或 Apache 的配置文件中 使用 SetEnv 命令进行设置(Nginx 或其他 Web 服务器也有类似的设置方法)。

2、或者你可以直接删掉这个逻辑,根据服务器的 IP 地址来设置该常量。

使用这个常量,除了会影响到一些基本的框架行为外, 还可以在开发过程中使用它来区分当前运行的是什么环境。

对默认框架行为的影响

CodeIgniter 系统中有几个地方用到了 ENVIRONMENT 常量。响。

错误报告

如果将 ENVIRONMENT 常量设置为 ‘development‘ ,当发生 PHP 错误时错误信息会显示到浏览器上。

与之相对的,如果将常量设置为 ‘production‘ 错误输出则会被禁用。

配置文件

另外,CodeIgniter 还可以根据不同的环境加载不同的配置文件, 这在处理例如不同环境下有着不同的 API Key 的情况时相当有用。 这在 配置类 文档中的“环境”一节有着更详细的介绍。

时间: 2024-10-12 17:44:42

CI框架 -- 开发环境、生产环境的相关文章

[原创译书] JS函数编程 3.2 开发和生产环境

?? Functional Programming in Javascript 主目录第三章 建立函数式编程环境 开发和生产环境 环境 编程风格与应用所部署或者将要部署的环境没啥关系.但是库就有关系了. 浏览器 主要的Javascript应用还是跑在客户端的,也就是浏览器.基于浏览器的环境对于开发来说非常好, 因为浏览器无处不在,你可以在本地机器上写代码,解释器是浏览器的Javascript引擎, 所有的浏览器都有开发者终端.火狐的FireBug提供了非常有用的错误信息,并支持断点等等, 不过同

在package.json里面的script设置环境变量,区分开发及生产环境。注意mac与windows的设置方式不一样

在package.json里面的script设置环境变量,区分开发及生产环境. 注意mac与windows的设置方式不一样. "scripts": { "publish-mac": "export NODE_ENV=prod&&webpack -p --progress --colors", "publish-win": "set NODE_ENV=prod&&webpack -p -

spring boot--日志、开发和生产环境切换、自定义配置

Spring Boot日志常用配置: # 日志输出的地址:Spring Boot默认并没有进行文件输出,只在控制台中进行了打印 logging.file=/home/zhou # 日志级别 debug-> info -> warning -> error # 默认级别为 info # 如果设置了debug=true的时候,日志级别会自动降低为debug # ROOT代表默认全局设置 logging.level.ROOT=INFO # 可以设置指定包的输出级别,这样的话,指定的包,级别以下

webpack开发与生产环境配置

前言 作者去年就开始使用webpack, 最早的接触就来自于vue-cli.那个时候工作重点主要也是 vue 的使用,对webpack的配置是知之甚少,期间有问题也是询问大牛 @吕大豹.顺便说一句,对于前端知识体系迷茫的童鞋可以关注豹哥的微信公众号,<大豹杂说>.豹哥对于刚开始小白的自己(虽然现在也白)知无不谈,而且回复超快超认真.这里真的很感谢豹哥.前段时间工作不忙,自己就啃了啃webpack的官方文档,毕竟知识还是在自己脑袋里踏实.然后根据vue-cli的配置文件丰富了一点新的东西,发布出

Maven_如何为开发和生产环境建立不同的配置文件 --我的简洁方案

其实也是最近才看Maven, 以前都是用ant+ivy, 对于轻量级的项目来说足够了, 而且非常灵活. 看了看Maven, 约定.... 现在编程都说约定, 约定是挺好, 问题是超出约定的事情太多了, 到头来还要依赖其他东西, 真不想用maven啊. 以前我们开发环境和生产环境的配置文件都是单独分开目录存放的, ant脚本搞个变量就自动打包不同的文件了. 我觉得管理起来也很容易, 所以看到很多maven为解决开发/生产环境的方案真是不太理解啊:  1. 什么 ${your.configurati

spring 项目分开发和生产环境

1.pom 文件修改 <profile> <!-- 本地开发环境 --> <id>dev</id> <properties> <profiles.active>dev</profiles.active> <webXmlPath>src/main/filters/dev/web.xml</webXmlPath> </properties> <activation> <ac

vue-cli3区分开发和生产环境

vue-cli3出来很久了,之前一直使用vue-cli2的配置,并且区分了生产和开发环境,自己的理解,环境分两大类,开发环境 和生产环境 对于命令来说,就是dev和build的区别, 一般都会有预发布和正式生产两个环境区别 预发布 就使用预发布的接口 正式的就使用正式的接口 对于程序员来说,本地测试也需要测试预发布的接口和生产的接口,上线也需要区分上到预发布或者上到生产 所以根据这些的不同,分成了两大部分,每一部分都分了预发和正式 具体可以参照下图 根据这些不同呢,就在package.json中

Rails : 产品环境(生产环境)的部署

rails server (默认为开发环境) rails server -p503 -e production (指定为生产环境 ,并指定站点端口) rake RAILS_ENV=production assets:precompile --trace (预编译) intel app frame jquery mobile rails routes restful

MySQl开发和生产环境索引对比

--1.创建索引信息表create table `t_index_update` (  `table_name` varchar(20) COLLATE gbk_bin DEFAULT NULL,  `index_name` varchar(20) COLLATE gbk_bin DEFAULT NULL,  `index_cols` varchar(100) COLLATE gbk_bin DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=gbk COLL