鍍金池/ 問答/ PHP問答
背叛者 回答

嚴(yán)格來講,這些東西都與部署無關(guān),Laravel 不過是一個 PHP 框架而已,Laravel 應(yīng)用的部署與常規(guī)項目的部署并沒區(qū)別,在服務(wù)器上只要有它需要的運行環(huán)境即可,通常在服務(wù)器端根本不會存在以上的名稱環(huán)境。

那么上面的東西是啥?它們不過就是一個開發(fā)環(huán)境而已,就像你學(xué) PHP 的時候,開發(fā)環(huán)境集成包一個意思,你同樣有很多選擇,比如給 windows 用的 WampServer、PHPStudy 還有給 mac 環(huán)境使用的 XAMPP 等等,它們做的事情都是一樣的:創(chuàng)建一個有 PHP、mysql、nginx/apache 的運行環(huán)境而已。

所有,laravel 官方只不過是給大家提供了不同環(huán)境下的集成開發(fā)環(huán)境,加速與統(tǒng)一你的開發(fā)環(huán)境,不必在環(huán)境這事兒上踩坑。

就是這樣。

舊言 回答

個人觀點:不推薦,在case后面做公式,直接case單一的值就好。
為什么不推薦? 、、邋遢。

switch( $search ) {
    case 'like':
        $key.=' like';
        $this->_datas[$key] = '%' . $value . '%';
        break;
    case 'greater':
        $key.=' >=';
        $value = strtotime( $value );
        $this->_datas[$key] = $value;
        break;
    case 'less':
        $key.=' <=';
        $value = strtotime( $value . " +1 day" );
        $this->_datas[$key] = $value;
        break;
    case 'lessthan':
        $key .= ' <=';
        $value = strtotime($value);
        $this->_datas[$key] = $value;
        break;
    case 'big':
        $key.=' >';
        $this->_datas[$key] = $value;
        break;
    case 'small':
        $key.=' <';
        $this->_datas[$key] = $value;
        break;
    case 'in':
        $key.=' in';
        $this->_datas[$key] = '(' . implode( ',', $value ) . ')';
        break;
    case 'notequal':
        $key.=' <>';
        $this->_datas[$key] = $value;
        break;
    case 'noteq':
        $key.=' !=';
        $this->_datas[$key] = $value;
        break;
    default:
        $this->_datas[$key] = $value;
}

如果case下面拼裝sql的代碼一致,可以這樣寫:

case 'big':
case 'small':
case 'noteq':
    $this->_datas[$key] = $value;
遺莣 回答
  1. 檢查你的443端口是否開放了:
openssl s_client -connect example.com:443
  1. 改成廣義設(shè)定:
<VirtualHost [ip address]:443> 改成 <VirtualHost *:443>

更詳細的參看: https://stackoverflow.com/que...

你好胸 回答

sessionStorage穩(wěn)定是穩(wěn)定的,但這種需求存sessionStorage不好,可以手動修改,有bug。

最好還是存一個變量內(nèi)。

ps:sessionStorage是以文件形式存本地硬盤內(nèi)的,變量是存內(nèi)存中的。

喵小咪 回答

聽你意思好像whj.domain.com,m.whj.domain.com的/api/ 都指向 php_project目錄
所以針對/api/單獨設(shè)root就行了

#whj.domain.com

server_name whj.domain.com;
root /path/pc_front_project;
location / {
    ...
}
location /api/ {
    root /path/php_project;
    ...
}
陌上花 回答

這樣的鏈接后面一般都有一次性的Token,后臺驗證后自動設(shè)置為登錄狀態(tài),也有相應(yīng)的cookies設(shè)置。鏈接大概是這樣子的。
https://www.thesite.com/index?token=a6sd6afs68a8sd78a&otherparams...

故人嘆 回答

其實編譯php后有很多配置文件;

##復(fù)制php-fpm啟動腳本
sudo cp init.d.php-fpm /etc/init.d/php-fpm

##賦予腳本執(zhí)行權(quán)限
chmod +x /etc/init.d/php-fpm

參考Ubuntu下php+nginx+mysql的安裝與配置

兔囡囡 回答

解決了,刪除指定包然后重新 require 一次
估計是開始時用的源不同導(dǎo)致的沖突出現(xiàn)的問題

抱緊我 回答
  • 試了網(wǎng)上幾個方法都不管用,于是我直接簡單粗暴的把 webpack.prod.conf.js 中的 兩處
  • CommonsChunkPlugin注釋掉了。就沒報錯,目前沒問題。
  • 下面把代碼放一下
var path = require('path')
var utils = require('./utils')
var webpack = require('webpack')
var config = require('../config')
var merge = require('webpack-merge')
var baseWebpackConfig = require('./webpack.base.conf')
var CopyWebpackPlugin = require('copy-webpack-plugin')
var HtmlWebpackPlugin = require('html-webpack-plugin')
var ExtractTextPlugin = require('extract-text-webpack-plugin')
var OptimizeCSSPlugin = require('optimize-css-assets-webpack-plugin')

var env = config.build.env

var webpackConfig = merge(baseWebpackConfig, {
  module: {
    rules: utils.styleLoaders({
      sourceMap: config.build.productionSourceMap,
      extract: true
    })
  },
  devtool: config.build.productionSourceMap ? '#source-map' : false,
  output: {
    path: config.build.assetsRoot,
    filename: utils.assetsPath('js/[name].[chunkhash].js', true),
    chunkFilename: utils.assetsPath('js/[id].[chunkhash].js')
  },
  plugins: [
    // http://vuejs.github.io/vue-loader/en/workflow/production.html
    new webpack.DefinePlugin({
      'process.env': env
    }),
    new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
      },
      sourceMap: true
    }),
    // extract css into its own file
    new ExtractTextPlugin({
      filename: utils.assetsPath('css/[name].[contenthash].css', true),
      allChunks: true
    }),
    // Compress extracted CSS. We are using this plugin so that possible
    // duplicated CSS from different components can be deduped.
    new OptimizeCSSPlugin({
      cssProcessorOptions: {
        safe: true
      }
    }),
    // generate dist index.html with correct asset hash for caching.
    // you can customize output by editing /index.html
    // see https://github.com/ampedandwired/html-webpack-plugin
    ...utils.getHtmlPlugins(),
    // keep module.id stable when vender modules does not change
    new webpack.HashedModuleIdsPlugin(),
    // split vendor js into its own file
     <1.--------------------------------------------------------------------->
    // new webpack.optimize.CommonsChunkPlugin({
    //   name: 'vendor',
    //   minChunks: function (module, count) {
    //     // any required modules inside node_modules are extracted to vendor
    //     return (
    //       module.resource &&
    //       /\.js$/.test(module.resource) &&
    //       module.resource.indexOf(
    //         path.join(__dirname, '../node_modules')
    //       ) === 0
    //     )
    //   }
    // }),
     ----------------------------------------------------------------------
    // extract webpack runtime and module manifest to its own file in order to
    // prevent vendor hash from being updated whenever app bundle is updated
     <2.--------------------------------------------------------------------->
    // new webpack.optimize.CommonsChunkPlugin({
    //   name: 'manifest',
    //   chunks: ['vendor']
    // }),
     ----------------------------------------------------------------------
    // copy custom static assets
    new CopyWebpackPlugin([
      {
        from: path.resolve(__dirname, '../static'),
        to: config.build.assetsSubDirectory,
        ignore: ['.*']
      }
    ])
  ]
})

if (config.build.productionGzip) {
  var CompressionWebpackPlugin = require('compression-webpack-plugin')

  webpackConfig.plugins.push(
    new CompressionWebpackPlugin({
      asset: '[path].gz[query]',
      algorithm: 'gzip',
      test: new RegExp(
        '\\.(' +
        config.build.productionGzipExtensions.join('|') +
        ')$'
      ),
      threshold: 10240,
      minRatio: 0.8
    })
  )
}

if (config.build.bundleAnalyzerReport) {
  var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
  webpackConfig.plugins.push(new BundleAnalyzerPlugin())
}

module.exports = webpackConfig
厭惡我 回答

不用開啟服務(wù)器配置,通過兩步來獲取open_id,第一步先通過appid和secret獲取access_token,第二步用access_token來獲取open_id。

涼心人 回答

如果你們是需要發(fā)送短信。這個一般沒有直接使用CMPP協(xié)議對接的。
像阿里大魚的短信,也是走的http協(xié)議。你可能走入了誤區(qū)了。

陪她鬧 回答

http request消息里面請求行攜帶了請求類型是[get]還是[post],或者是其他[put] [head]等,瀏覽器會對報文進行解析。
請求行以一個請求類型符號開頭,以空格分開,后面跟著請求的URI和協(xié)議的版本。

默認是get.

兮顏 回答

你好,請問rules里的validator可以和async-validator結(jié)合起來嗎?難道得一個的寫驗證器

茍活 回答

https://segmentfault.com/n/13... 這是我一篇筆記,可以參考參考,是個白話故事形式的講解,我覺得挺生動的,希望幫到你

扯機薄 回答

外面多嵌套一層設(shè)置樣式,是不是可以解決

葬憶 回答

對于參數(shù)綁定為何可以避免SQL注入,建議題主可以了解一下,值得注意的是prepare語句只能解析一條SQL,下面摘要說明一下prepare的作用:
首先從mysql服務(wù)器執(zhí)行sql的過程開始講起,SQL執(zhí)行過程包括以下階段 詞法分析->語法分析->語義分析->執(zhí)行計劃優(yōu)化->執(zhí)行。詞法分析->語法分析這兩個階段我們稱之為硬解析。詞法分析識別sql中每個詞,語法分析解析SQL語句是否符合sql語法,并得到一棵語法樹(Lex)。對于只是參數(shù)不同,其他均相同的sql,它們執(zhí)行時間不同但硬解析的時間是相同的。而同一SQL隨著查詢數(shù)據(jù)的變化,多次查詢執(zhí)行時間可能不同,但硬解析的時間是不變的。對于sql執(zhí)行時間較短,sql硬解析的時間占總執(zhí)行時間的比率越高。而對于淘寶應(yīng)用的絕大多數(shù)事務(wù)型SQL,查詢都會走索引,執(zhí)行時間都比較短。因此淘寶應(yīng)用db sql硬解析占的比重較大。

Prepare的出現(xiàn)就是為了優(yōu)化硬解析的問題。Prepare在服務(wù)器端的執(zhí)行過程如下

1) Prepare 接收客戶端帶”?”的sql, 硬解析得到語法樹(stmt->Lex), 緩存在線程所在的preparestatement cache中。此cache是一個HASH MAP. Key為stmt->id. 然后返回客戶端stmt->id等信息。

2) Execute 接收客戶端stmt->id和參數(shù)等信息。注意這里客戶端不需要再發(fā)sql過來。服務(wù)器根據(jù)stmt->id在preparestatement cache中查找得到硬解析后的stmt, 并設(shè)置參數(shù),就可以繼續(xù)后面的優(yōu)化和執(zhí)行了。

Prepare在execute階段可以節(jié)省硬解析的時間。如果sql只執(zhí)行一次,且以prepare的方式執(zhí)行,那么sql執(zhí)行需兩次與服務(wù)器交互(Prepare和execute), 而以普通(非prepare)方式,只需要一次交互。這樣使用prepare帶來額外的網(wǎng)絡(luò)開銷,可能得不償失。我們再來看同一sql執(zhí)行多次的情況,比如以prepare方式執(zhí)行10次,那么只需要一次硬解析。這時候  額外的網(wǎng)絡(luò)開銷就顯得微乎其微了。因此prepare適用于頻繁執(zhí)行的SQL。

Prepare的另一個作用是防止sql注入,不過這個是在客戶端jdbc通過轉(zhuǎn)義實現(xiàn)的,跟服務(wù)器沒有關(guān)系。 

建議題主看下MySQL官方文檔(https://dev.mysql.com/doc/ref...)。什么?看不懂英文?試試百度翻譯吧:https://fanyi.baidu.com

clipboard.png

淚染裳 回答

從截圖來看,這個cookie屬于請求頭request的cookie,使用瀏覽器的debug工具追蹤一下在哪里相應(yīng)了這個cookie的吧,這樣才能拿到cookie