手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表分类:PHP

Dcat-Admin with vue

有时候你不得不承认,DCAT-admin / laravel-admin 做后台是属于比较方便的。你硬要说nova之类的,我也无话可说。但毕竟nova要钱,而且文档并没有国内的全。

为什么说dcat-admin,主要还是laravel-admin好久没有大更新了。然后laravel-admin的多应用要钱。虽然我买了,但更新太慢,我现在还是用dcat了。

很多人在github上面问,为什么不支持VUE。其实也能理解 ,vue如果用了, pjax就不太好用了。但我还是得说,如果你只是简单的,不做特别复杂的应用,还是有办法支持vue的。

首先全局引用JS,Admin::js(),这个不用多说,如果不想全局引用,那就在自己的页面里,将它引用出来就行了。

然后用了个简单的demo,

XML/HTML代码
  1. <div id="sign-form">  
  2.   @{{ form }}  
  3.   <el-input v-model="input" placeholder="请输入内容"></el-input>  
  4.     
  5.   <el-steps :active="active" finish-status="success">  
  6.     <el-step title="步骤 1"></el-step>  
  7.     <el-step title="步骤 2"></el-step>  
  8.     <el-step title="步骤 3"></el-step>  
  9.   </el-steps>  
  10.     
  11.   <el-button style="margin-top: 12px;" @click="next">下一步</el-button>  
  12.   
  13. </div>  
  14. <script>  
  15.   var form = {};  
  16.   new Vue({  
  17.     el: '#sign-form',  
  18.     data() {  
  19.       return {  
  20.         form: form,  
  21.         input: '{{date('Y-m-d H:i:s')}}',  
  22.         active: 0  
  23.       };  
  24.     },  
  25.     mounted() {  
  26.       this.request();  
  27.     },  
  28.     methods: {  
  29.       formReset() {  
  30.         this.form = form;  
  31.       },  
  32.       request() {  
  33.         this.form = {a: 1, b: 2, c: 3, d: 5};  
  34.         {{--laravel.get('{{api_url('union/bind/check/123')}}', res => {--}}  
  35.         {{--  console.log(res);--}}  
  36.         {{--});--}}  
  37.       },  
  38.       next() {  
  39.         if (this.active++ > 2) this.active = 0;  
  40.       }  
  41.     }  
  42.   });  
  43. </script>  

 

保存后,点开网页看看。确实不会再加载了。但这种VUE,就只适合单页面用用了(当然,本身也就是为了在复杂的表单上使用它。也够了)

---差点没有保存。。

 

composer clear-cache

看起来这个标题好象没啥,今天被折腾了好久

因为网络不好,所以在更新的时候一直更新不下来。再更新就报zip包出错,多次尝试都是这样。
删除vendor目录,再试也是这样
开始以为是墙的问题,毕竟压缩包都在github上,所以爬了梯子试了下,还是zip包出错
 
因为发现问题都是出现在load from cache,所以想了下,还是用composer clear-cache清空一下。然后composer global update,再回到本目录,进行composer update
 
一切OVER
 

说实话。又是一次迁移

总感觉博客一直处于风雨飘摇之中,从08年到现在,好象迁移了不下6次了吧

从最开始服务器放在同普路机房,迁移到E动的江阴机房,再到阿里云,再后来到linode,再到腾讯香港,再到layerstack,再到阿里云。经历了种种磨难。

如果又回归阿里云了。所幸数据迁移还算比较容易,由于东西都没有上GIT,其实也是属于比较痛苦的事情,比如打个包就2.6G,其中也一堆垃圾数据(本来一直想图片上云也没有做,数据库也有20多M。),垃圾数据中还包括了一个vbox(如今也没有用了),还有一些已经找不到的软件,比如mqs相关的。

后续会对这些数据再做一次清理,然后尝试上github吧。后续还是会考虑自动备份数据库,感觉那样更合适一点。(现在没有搞)

博客也10多年了,不知道自己在坚持什么。

laravel predis `AUTH` failed: ERR Client sent AUTH

之前写过一篇:laravel 队列报错:`AUTH` failed: ERR Client sent AUTH, but no password is set [tcp://127.0.0.1:6379] ,就在前两天,今天上线看的时候,发现pm2 status的时候显示failed。

于是就在看到底是怎么回事,按理这个参数应该没问题啊?经过不停的测试不停的测试,发现

1、将paramaters放在default和cache中,仍然报错

2、将paramaters放在options里,一样报错

3、将default/cache中的password删除,只除paramaters,报错

4、将default/cache中的password删除,删除paramaters,留options中的paramaters,报错

5、将所有涉及到密码的地方删除,成功

--------再看predis的github发现他已经几年不更新了。所以,我也只能忍喽?不然怎么办?如果有设置密码,就将这个key加回来【因为之前测试过,如果确实有密码,并且设置了,没问题】

再看,pm2 stauts,还是报错,那问题就来了。因为我直接php artisan queue:work --tries=5 --sleep=1没有错,但为什么pm2启动就报错呢?于是查看进程,ps uax|grep artisan,发现运行路径是在release/4目录下。而不是current目录【之所以目录结构 是这样,是缘于我采用deployer进行项目部署的】

即使我在current目录下执行pm2 start xxx.yml,也是默认在release/4路径,毕竟它是映射过来的

所以最终我只能修改yml文件,将artisan路径设置为绝对路径。强行指定为current所在的绝对路径。这样就没有问题了。

至此,Auth没有设置密码的问题解决。同时还解决了artisan 执行queue:work 路径不对的问题(如果不解决这个,这意味着无论我怎么执行,都不在正确的目录下了)

Tags: laravel, predis, auth

deployer 快速部署

 deployer是一个PHP版的部署工具,支持各类框架以及裸PHP的部署(支持的框架,其实也只是帮你预置了一些代码,方便你调用而已)

但deployer在部署的时候,其实都是从头开始执行了一遍流程,如果只是简单的改了一些小BUG,不影响整体的,这样的话,就性能太低了。或者说不是叫性能太低,是太耗时间了。毕竟composer帮你执行一遍。好歹也得有个1~2分钟了吧。git 拉一下全库,又得1~2分钟这得多痛苦。

所以简单写了一个task,如果更新不涉及composer/migration,就这样执行一下下喽

PHP代码
  1. desc("只更新代码");  
  2. task("pull",function(){  
  3.     writeln(run("cd {{current_path}} && git pull"));  
  4. });  
  5.   
  6. desc("更新代码,并清除一些缓存");  
  7. task("update",[  
  8.     'pull',  
  9.     'artisan:cache:clear',  
  10.     'artisan:config:cache',  
  11.     'artisan:route:cache',  
  12.     'artisan:optimize',  
  13.     'artisan:queue:restart'  
  14. ]);  

这种就是属于临时性的。全量还是得靠 dep deploy。

想想的话,这样好象也暂够用了。如果将dep再配置一个后台,也可以完成很多事情。算了,不折腾

 

 

Tags: deployer

Records:64112345678910»