I've a slimframework v3 application that provide REST API for an Angular application.
I want to upgrade to v4, but there's quite a lot of changes and the upgrade page, while it mention what is changing, it's pretty dry on how to make those change and get a working application at the end.
For example, it says the new App() no longer takes the settings... ok... where does the settings go now ? Likely in the Dependency Container but this is changing too.
I fear that I will do a lot of code change and get a non working app and will spend ages on figuring out what's wrong.
So do you have any suggestion on how to proceed, step by step, to achieve a working upgrade from 3 to 4?
I've googled a bit, but I didn't find some walkthrough/tutorial on this subject.
I've managed to perform the upgrade.
It's way too long to document it here, so I've made a blog post here :
https://blog.mansonthomas.com/2019/11/upgrade-slimframework-v3-to-v4-how-i.html
I'll improve the article (readability & content)
Related
I am working on a plugin in CakePHP3 and I need to create a simply Oauth 2.0 Server API that allows to do a simple CRUD on the users' table and create sessions when needed.
I have done some research here in StackOverflow and it seems that the best choice would be
https://github.com/uafrica/oauth-server
Now, I have tried to make it work according to the doc in the repository but since it will be a plugin, not the core of the application I do not understand how it is supposed to work and which file I need to update.
Would somebody be so kind to give me the list of steps I need to follow and the actual files that need to be updated?
Many Thanks in advance
The uafrica/oauth-server project is woefully out of date. It requires v4.1 of league/oauth2-server, which is now currently at v7.2. Version 5 of that project was completely rewritten and is not backwards compatible with v4.x.
I don't think there's an out-of-the-box CakePHP 3 plugin that works with the current version of league/oauth2-server.
You'll have to either build your own plugin from scratch, or try to hack the uafrica/oauth-server project to get it work with league/oauth2-server.
I'm trying to integrate the Quickbooks Online API into Laravel 5. I've got the code working outside of Laravel using the Consolibyte package. But its written in what I'll call a classic PHP style - meaning there are a number of REQUIRE_ONCE files etc. I'm sure I can crank through and integrate it all, but in the interest of saving time, I'm wondering if anyone else knows of a package for Laravel 5 which already does this?
Ultimately I need to be able to create Customers, Vendors and Invoices. Don't really need the rest of the functionality that the Consolibyte package uses (which is a great package by the way).
If you're using this code:
https://github.com/consolibyte/quickbooks-php
You only need to require one file. There's no real work required to get this working in Laravel. Just do this in your Laravel app:
require_once './QuickBooks.php';
And you're done.
For anyone else looking to solve this problem, this obscure blog post will save your life. It's a lot to post here, but he essentially uses the consolibyte/quickbooks-php, but wraps it up in creamy Laravel goodness so you can see the "under the hood" objects you need to set up so that you don't break the framework.
I followed the instructions, with some alterations for my app, and it authorized first try (Laravel 5.2).
It's not perfect, but it's as clean as you can get for Laravel right now.
Major props to both the article writer Pawan and the package author Keith Palmer Jr!
You can use this one instead its fully enabled to be installed by composer in Laravel or Yii2. I installed it in Yii2.
https://github.com/beanworks/quickbooks-online-v3-sdk install quickbooks from this url and then use the below url to implement oauth
https://github.com/IntuitDeveloper/oauth-php
You can easily make routes for oauth steps involved and there are samples in the later repo which can be used to learn how to post and query objects from quickbook.
it's about 6 months that the Yii2 preview (May 2013) was released. I think that in 6 months there are a lot bugs that were remove I would like to know it's a big risk for me to use yii2 for production. I would like to try my new project with Yii2. Are the people that use it for project with success? I understand that there are no extension at the moment. Most of time i dont use them !
thank for help))
Yes it's still risky to use yii2 for production, but there're some brave hearts who does it. For example I've heard this site is built with yii2. Also yii2 recently switched to php 5.4 and who knows what else will be changed. So, I would say it depends on your project requirements/strictness/complexity and time you're ready to spend for updating your code when something is changed in the framework. Also keep in mind that documentation isn't complete yet, and you'll have to look into source code quite often.
Ok so Im running 1.7.2 and I installed the codeigniter-modular-seperation library (the newest version which is maintained by Phil Sturgeon , as the wiki said to install that version if Im using 1.7 or above)
-- anyways, the documentation is super light, just says put MY_Router and MY_Loader in the libraries folder which Ive done, and everything is working as far as the module urls go, but when I try and make the modules talk to each other as per both of the following articles:
http://codeigniter.com/wiki/Modular_Extensions_-_HMVC/
http://codeigniter.com/wiki/Modular_Extensions_-_HMVC
but I get
Fatal error: Call to undefined method Modules::run() in siteurl on line 4
I also tried loading the module like this
[code]load->module('ratings/ratings'); ?> [/code]
which yields an error Call to undefined method MY_Loader::module()
So ya, anyone have any idea how to fix this? Any help much appreciated.
soooooooo, correct me if Im wrong, but, it appears that the newer version of HMVC (the one you are advised to download if you use 1.7+), does not support cross loading of controllers. I switched to the old version and its working perfect, although I have to say Im not sure I understand the purpose of making it modular, if you aren’t able to cross load from other controllers (unless you are just using the modules to create completely separate unique webpages by using each directory as its own mini codeigniter installation.
I replaced the new with the old version and its working perfect.
Phil, if you read this, do you have any plans to implement cross controller/resource loading in a future version? Because (and I mean no disrespect you know a hell of a ton more about php than me), it seems like the whole power behind the Zend framework is its modularity. The problem I have with Zend is its honestly the most confusing shit I have ever attempted to understand (I have an ecommerce store running on magento), but even though its confusing and frustrating as all hell, its absolutely brilliant because of how extendable it is. I feel like if CI were more modular (without hacking it up all over), it would have 2000x the power as it does now.
I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7