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.
Related
I'm trying to access the controller from another CodeIgniter.
I have a CodeIgniter 3.0.4 that containing:
Application
codeigniter2
css
js
...
so I have already tried $this->load->library('../controllers/home'); ,
but it shows me the Unable to load the requested class: Home
And I'm trying to login to both at the same time so I need to access each Session
I would strongly suggest that you simply either import the required library or combine both apps into the latest CI 3.1 as there have been several security fixes plus many more bug fixes. Upgrading from 2.x to 3.x is usually a very simple task.
However, you will not be able to use the CI loader to load a controller or library outside the normal directories, and you will not be able to share sessions across them either, as both sessions will have a different format for their session tables.
At a push, you might be able to create a bridge library, that includes the files you want, from the older CI version, but to be honest, unless the libraries you are connecting to are completely empty of any CI references, more like functional helpers rather than libraries, it just is not going to work, or would take far more work to achieve that it would to just upgrade and combine your old system. The advantages of doing that far outweigh the problems you are going to face with a bridging mechanism.
Sorry if that is not a lot of help, but in short, combine them into one app and upgrade to the latest version ASAP.
Best wishes,
Paul.
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
I'm working on a project that is currently using the Zend Framework 1.7.6, however the current release of the framework 1.9.1 has some features that would really make my life a little easier, so I want to update the framework.
As this is quite a jump I know that it is going to break parts of my application. Items such as the bootstrap are very different between the versions. Apart from this what other issues can you see me hitting if I do this update? What experience has anyone had updating to 1.9.1 from a lower version??
I'm just trying to justify, what I think might be a little painful to complete.
Thanks.
Most important change is new Autoloader with optimistic namespace matching. But you can use fallbackAutoloader feature (see manual) to revert to old-style autoloading.
Other change is _Zend_Application_ and new Bootstraping process - but I guess there is no need to use it. You can still use your old bootstrap. Just couple fixes here and there ;)
So much for the most important changes from my point of view.
If you use Zend_Validate_NotEmpty, and were doing anything strange like filtering input to be an object of some sort, Zend_Validate_NotEmpty now causes an error if the item isn't a float/int/string/array/boolean - so Objects don't cut the grade anymore.
Other than the autoloader, you should also have to check the signatures of any methods you have overridden as a fair few have changed.
I am an autodidact so dont know much about conventional web development however, I have wrote a complete social networking website yet I dont know how to debug. My website has some problems and I need to learn debuggin things around/
First of all I need instructions how to install Xdebug on WAMP (since I use phpDesigner). I tried a lot using tutorials on the web everytime I get a new error. I also tried puting it in the /ext/ directory and activating it from the WAMP PHP Extensions menu. Doesnt Work!
So if anyone odf you out there uses PHPDesigner with Xdebug (not the package that comes along, rather install it on WAMP) please help me and I would really be grateful. BTW PHP version is 5.3.0
Next thing is this is how is the the control flow of my website :-
htaccess -> redirect everything to index.php if file doesn't exist.
index.php ->
include all libraries (__autoload).
initialize classes.
Get the $_SERVER['REQUEST_URI'] to get the $page.
If $page is found
Check if the user is logged in,
if yes then include view/$page.php
or else redirect to login.php page
If page is not found then
redirect to 404.php
Is this control flow good for debugging? because I really cant understand the real MVC concept so I created something like this.
There is a tutorial for installing XDebug for use with phpDesigner here.
MVC is an organizing principle (also called a "design pattern"). It can be helpful keeping logically similar parts of a project together, and encouraging clean interfaces between them, but—especially for low complexity projects—strict MVC modeling isn't always an improvement.
You ask:
Is this control flow good for debugging?
Debugging is to identify flaws in programs. Writing a program to be easy to debug is like intentionally driving a car off the left side of the road so you'll know where to direct an ambulance to find you. Granted—there are small things which can be done to greatly improve debugability. But the point is to architect any control structure so it naturally expresses the algorithm. By doing that, it is far more likely to avoid the need to debug. Anything you can do to write correctly functioning code is justifiable.
Your control flow is clear to me. I wouldn't have any qualms about working on it.
Use xDebug.
Its very easy to install and use.
and you can download xDebug from here http://www.xdebug.org/
step by step tutorial for setup xdebug with WAMP is available at sachithsays.blogspot.com/
I am deciding on a framework to try out for PHP. I have narrowed it down to CakePHP and CodeIgniter. I have a couple of questions for any of you who have used or are familiar with both:
I like the fact that CakePHP keeps most of the code outside of the webroot by default. Especially since I may end up using a single framework install for multiple apps. I see CodeIgniter will do that too, but you have to configure it and move some stuff around. Is that workaround secure and reliable, or is it an afterthought hack?
Which (if not both) is easier to upgrade, and maintain over the long term? As new versions of the framework (and PHP itself) come out. I don't want to find my stuff either breaking, or becoming outdated.
Edit:
This is a very old post, but I thought I would update it with what I finally ended up doing, which was to use Kohana.
You should try both frameworks for a week or so, building something trivial (like a blog or wiki) in both, and see which you prefer using. Whatever makes the most sense to you will probably sustain you the longest through upgrades an deprecations.
CakePHP is in a bit of a volatile state right now, still unearthing bugs while pushing to release version 1.2 (which is not backward compatible). I wouldn't suggest building a critical application with it if you need something rock solid right now. If you can wait a month or two for things to settle, then it's probably a moot point.
To address your concerns:
1) Cake and CI do it the same way (iirc). They are equally secure, reliable, and hackish on this front.
2) Everything changes. If you need concrete, perpetual assurance of stability and backward compatibility, roll your own framework. There's not that much to it, and you're guaranteed that nothing changes unless you want it to.
I have deployed multiple applications on CakePHP and it's been a very, very, nice experience. You can't go wrong either way, as both are solid.
is a non-issue.
CodeIgniter has a sponsor behind it, so it's definately the one to choose for the long term. Also, it's faster.
This is a non issue. The app has a couple of lines which says where the core and your application code lies. You just need to change those lines.
You can never anticipate this one.
The state of PHP is a wildcard here. One app (CI) is built to be compatible with PHP4 the other requires PHP5. If you need to deal with the possibilty of a web host only supporting older versions of PHP then you need to go with CO.
Another issue is unit testing. If you require your framework to ship with tests, then CI is not the way to go.
Personally, I feel comfortable with CI because of the corporate backing. The company behind CI is making real profit from their efforts. Though CI is free, their paid product (ExpressionEngine) will eventually live on CI. The same could be said of the Zend Framework and even the birth of Rails (originally built for Basecamp.)
A minor correction to an above comment: both are compatible with PHP4, not just CI. Also, I don't think that having a sponsor makes CI and more or less upgradable or maintainable. Money doesn't solve those problems in the least.
I use CakePHP for a variety of applications and I've been happy with it thus far. 1.2 is a huge improvement over 1.1, and while the library source may change from RC3 to Final, I don't think any code you write will become obsolete. My only niggle is that the Manual isn't as comprehensive as it should be (in my opinion), and I end up in the API quite a bit. The trade-off there is that I now understand the code behind the scenes very well. In any case, I highly recommend it.
On the other hand, I've never played around with CI, so I can't recommend CakePHP over CI. I would take each for a spin and see which one grabs you. Whichever one you choose, study the hell out of its conventions and capabilities. When I started with Cake, I unwittingly wrote a bunch of code to do something Cake did "automagically" by having me set one variable in the controller.
CodeIgniter is very flexible as you would see once you try it. So how your application would be maintainable would fall you your hands.
I have also deployed multiple applications using the same installation. I usually create 2 applications for CMS projects (one for admin, one for the front-end).
To address both of your questions from a CodeIgniter perspective (I don't use Cake):
1) CodeIgniter doesn't keep itself outside the webroot by default, but it can do so with some very simple changes. The first part of my CI tutorial series explains how to do so, along with a walk through of the setup of a new CI instance. Once finished the only part of CI that needs to be in the webroot is a small index.php bootstrap file.
2) I've got an application which I originally developed in CI 1.4.x and I've sucessfully migrated to 1.5.x then 1.6.x. With each new release the CI dev's make available detailed upgrade instructions laying out what needs to be replaced so upgrades are fairly easy.
Jim.