I like CodeIgniter for php development, but I have a client with no tech skills that wants to make his own changes to his site. I taught him how to make pages in MODx (that was a feat in itself). Is it possible to develop a site with CodeIgniter and use MODx as the content management system? Will MODx mangle the framework?
Short answer is "very probably". There's a good chance that modxcms handles all routing, controller actions, etc. on its own. There probably is no simple way to plug either one of these into the other.
Long answer is "it depends" followed by these conditions: what framework does modxcms use? How does it handle calls through its index.php file? What's the overhead of modxcms? If you want to manage routing in CodeIgniter, how will modx interfere? How would it be possible to have these two systems work together absent a some major refactoring of code?
Typically, it makes the most sense to stick to CMSs that are built on a platform that you like. For CodeIgniter, the only one I know of is ExpressionEngine, which is nice and all, but it costs. Other CMSs that I've experienced like Joomla or Drupal are a disaster if you're coming from something as clean as CodeIgniter.
So...not sure if this really helps you much, but I'd operate under the assumption that you can't (or at least shouldn't) mix CI with modx. IMO, it's easy enough to make a decent CMS using CI alone, giving you much more immediate control over the presentation. In my experience, taking a CMS like Joomla and trying to turn it into a complex alternate creation is probably one of the most annoying things a programmer can put himself through.
Related
Having been dong research on codeigniter,kohana and fuel php, they seem excellent for the large scale project I want to create with various sections of code. The system I want to build is to be a core set of code, which can produce a full ecommerce web application with plenty of modules, or can produce a simply few page site, with a news or gallery or whatever.
I have started thinking that I may be looking at the wrong thing for producing basic sites. From my very brief research, it seems (atleast on codeigniter) I need to use the 404 overwrite to point to my pages controller in order to handle basic content pages (from the base url /).
Should I consider a seperate code set for the basic sites, and use these frameworks only for large web apps, or is this the normal way frameworks would handle serving basic content pages.
I personally have a core framework (MVC/CodeIgniter) which I use for even the simplest static sites - Because someone will always say "Oh and can we have a shop" or a contact us form or ...
The overhead of the frameworks themselves is negligible if they're not doing any work - so why not put them in?
Another bonus is that you now know exactly what environment your modules will be in - you don't need to worry about maintaining one versions for sites with the framework and one for those without (One other benefit of using a framework is that it makes if far easier to maintain code in general - especially in multiple-developer environments.)
Th templating engines provided by most frameworks (or easy extensions to them) are often useful even for static sites (custom controls like a news ticker or custom markup/js validation for certain controls)
In short, unless you have extremely limited server resources (mobile device?) use a framework
Edit:
I'd add a note of caution - PHP is a very flexible, powerful language and when used well can create some truly fantastic sites. When used poorly, however, it is easy to make insecure websites.
From your post, you seem relatively new to PHP/Frameworks. Can I suggest you make sure that the framework you pick enforces good behavior (as much as possible)
CodeIgniter removes unsafe $_POST and $_GET variables, replacing them with safe equivalents. It also provides a parameterised mechanism for querying the database which helps avoid SQL inection attacks. These are important things to consider when comparing frameworks.
I personally found CodeIgniter to be a good balance of maintainability, security, extensibility and functionality.
I would consider using a CMS for the basic sites, something like Drupal, they do a lot out of the box and should satisfy your requirements for a basic site.
As for the eCommerce part, from experience its best use something that is separate from the CMS. Largely because projects or frameworks that are designed for that sort of thing are generally an application.
CMSes do what they do they do best, but that all they really do :)
Also have a look at Magento for your eCommerce needs.
Hope this helps.
I think your question is about what to use for "basic websites".
Should I consider a separate code set for the basic sites, and use
these frameworks only for large web apps, or is this the normal way
frameworks would handle serving basic content pages
If by basic sites you mean websites that have little to no dynamically drawn content, I would suggest a CMS such as Wordpress. You mention that you are using PHP and Wordpress is a very popular option. If you are creating a blog and a very static pages, this will be a great option. It can even be modified to do more 'dynamic' things that can be considered "CMS Territory". Once you get the basics of Wordpress down, and if you still feel that you need to modify it a lot, then you should look in to a framework that will allow you to have total control such as Codeigniter, Cakephp, etc.
Hope this helps.
Ben this is an interesting topic and no matter which direction you eventually go it would be nice to know your choice of combination. Depending on your requirements.
For something with medium range functionality OSCOMMERCE might be worth a check on. Also see Zencart, Virtumart and Megento.
I have ready numerous posts here on SO about framework1 vs framework2 however it seems to be alot of personal opinions that are one sided. Based on the following can someone tell me which framework would be ideal for my needs?
Build a rich featured API where other sites and devices can use the API to use website features and access it's content.
RSS Feeds with both XML and JSON for jQuery interaction.
Ability to use layouts / templates that are customizable.
Use of plugins so that I do not need to duplicate code.
Database querying with relationships.
GREAT documentation.
Actively supported.
Doesn't REQUIRE command line access.
Easy to manage file uploads and move the files around so only certain users can download them.
Customizable access level so users can have different access levels depending on which project/section they are viewing.
Low overhead usage.
SEO URLS that do not require the '/view','/edit','/add' in the urls (depending on which action you want to do.)
Support for jQuery
There have been a few frameworks I have seen that support some of these but not all. I am currently using CakePHP for one project but do not think it would fit my needs as the database querying can get horrendous. I have heard a little bit about CodeIgnitor however it doesn't seem to easily use templating (maybe I just misunderstood what I read).
If you could tell me which framework you think would be ideal for these needs and why that would be very helpful!
I'll just spamvertize my little framework overview table here. The simple table answers a few of your technical points:
http://matrix.include-once.org/framework/simple
Use the detail/feature view to cherrypick your options.
RSS isn't a standard feature even with the big frameworks, use a PEAR library
templates: all frameworks use them
plugins: depends on your concept of plugins, most frameworks are extensible though
look for "ORM"
GREAT documentation: that would limit you to codeigniter or cakephp
Doesn't REQUIRE command line access: except symfony+cake, few do
file uploads: this isn't a standard feature, but I'd just mix and match a library
Customizable access level: practically all frameworks come with a permission system
Support for jQuery: this is surprising. Prototype seems to be very strong, only half the frameworks use jQuery by default
CakePHP database querying doesn't have to be horrendous. (Though, I remember my first few projects were definitely hard on the database)
With the right optimization, normalization/de-normalization of your data, and a few tweaks here and there (persistent models comes to mind), you can accomplish everything you've inquired about with CakePHP, and keep your database load to a minimum.
That said, if you truly want to move to something else, I'd go with Zend Framework.
Symfony is bloated, (and yes, fanboys, this is still true).
Codeigniter is super lightweight, but you're going to be doing a LOT more work to accomplish your listed requirements. I've spun up two codeigniter applications, both relatively simple, and both took twice the work / twice the amount of new code than if I had gone with say, CakePHP.
A lot of religious fanaticism floating around when you talk about frameworks. But take a look at the documentation of Fat-Free Framework. It just might catch your fancy and requirements.
Before I answer, let me qualify that I'm certified on Zend, a frequent user of CodeIgniter, and daily user (and hater) of Symfony.
Zend's setup, especially if you're doing a small-medium sized site can be ugly. Especially using the data mapper strategy, you're talking a thousand or more lines of codes just for the model setup. CodeIgniter is much better setup-wise, but still not insignificant.
Command-line free --essentially-- knocks out Zend. It's doable, but not fun (see thousand lines of code, above) Built-in user auth isn't nearly as good on CodeIgniter as Zend, perhaps that's a serious knock....definitely no templating there. Symfony is flat-out done because of the addition of /view /edit, etc.
Hate to break it to you, but it seems that many users of all these frameworks are not native English speakers. Forget about Symfony, seems entirely eastern-European based. I'd hate to be a new-to-php user of Zend Framework with all the competing tuts with their assumptions of some semi-complex concepts. There's a reason that Zend's training is expensive and full.... Again, CodeIgniter is not horrible, but still can be frustrating.
Simply because of our extensive use of Jquery and desire to avoid a ton of hack-around, my company has dumped the frameworks altogether. Now setup is purposeful, not for a framework...just build a DAL, assemble classes, build views, and done. Established functions are re-purposed as "plugins" that we actually know and understand. Most interaction is Jquery based Ajax (sometimes XAJAX) which really doesn't take advantage of the frameworks anyway--and fights tooth and nail with Symfony. For those who argue that frameworks force MVC, I have a VP of Development who does that just fine, thank you. Perhaps it's not the right answer for you, but we're glad we went this route. It's saved weeks worth of documentation-hunting.
My company is looking at various PHP frameworks to build a customer's site. This is a shop that has some legacy in-house frameworks and we're trying to move away from that. In my spare time, I've coded in CodeIgniter and dabbled a bit in Kohana. I have yet to use a CMS like Joomla or Drupal, but I recognize that they're built using an MVC and PAC design pattern respectively. In starting my excavation, I came to the preliminary conclusion that it might make more sense to use something like CodeIgniter to build the user-facing portion of the site and something like Joomla to build the admin-facing portion of the site, such that Joomla is never loaded unless you specifically go to admin.xxxxx.com.
So following this logic (and please do let me know if it's very flawed), I'm here to ask if anyone's ever done anything like this before, and if so, what might be the best method of taking advantage of some of the more automated features of Joomla (sorry if I don't go into too much detail here...I haven't studied Joomla enough to know everything about it....please correct any gross cognitive errors!!) from within a more lightweight framework like CodeIgniter.
Or is this going down the wrong line of thinking? My first instinct is to just link the two by data in the database and never have them communicate directly, but I just wanted to be sure this was correct before I take it to my superiors.
Vielen dank, guys
Quite possibly flawed, all of these CMS's run on assuming that they are used for both admin and user site, the major problem this causes is that code and the way things work are very intertwined meaning that a simple 'hook in to the database' often isn't enough and you'll have to use most of the CMS code just to pull / put valid data - the other caveat with that is that if the admin is upgraded, it can easily change the database schema which would break your front end.
I'd highly recommend going with one or the other, either your own design using frameworks for admin and user site(s) - or just stick to single CMS and bolt on whatever functionality you need with plugins.
Best!
I Agree with Nathan.
When you're using pre-built frameworks you lack the control factor over the core elements, this is not good especially developing for a corporate system, you need to have full control over every part of the system for future developments / integration.
My advice is to start with a small but abstract system it would be more beneficial, my advice is to use a framework like codeignighter that consists of an MVC Pattern but also plays the simplicity role with ease.
Take a look at the OpenSource application called "OpenCart" which is a small MVC Store, the reason I say look at this is because it's an extremely basic MVC Pattern and can be abstracted for your applications.
Hope this information helps.
Regards.
When your using pre-built frameworks you lack the control factor over the core elements, this is not good especially developing for a corporate system, you need to have full control over every part of the system for future developments / integration.
Well I don't know if i would necessarily agree with you about this?
I'm currently starting to write my own CMS in php from ground up using CakePHP (or should i use something else?) for my bachelors degree. And i'm thinking about various stuff that will be needed to do.
One of the things i can not figure out is if i should use a single file (for example, index.php will handle everything, and will include everything) or i should break up my cms into a few smaller files.
so my main questions are
is cakePHP a good choice?
use one file for everything or use multiple files?
do you have any good general advice on building more complex websites using php or any best-practices advice (i don't really understand why they don't teach us this in school)
Using a single entry point or multiple entry points becomes a moot point if you are using most frameworks. CakePHP for instance has an index.php file and all you end up doing is defining models, views, and controllers for different parts of your project. I would imagine that most frameworks these days work this way.
Alternatively, if you choose to roll your own framework and system for managing this, which given this is for a bachelor's degree may be (1) a lot of extra work but (2) more revealing and more instructive, I can speak from experience that I found having a single entry point to be useful.
It enables you to have a common code path for set-up stuff: things like enabling E_STRICT, E_NOTICE, etc. for debugging and reliability purposes. Things like sanitizing form inputs to work around the magic-quotes setting. Yes you can do that from an include 'globals.php' but:
Putting everything in one place also lets you come up with a standard file-naming convention and an __autoload handler that will help remove any include or require directives except for perhaps one. Means you can add classes and such without having to also remember to update a master file.
And this is entirely subjective, but I have found that it's easier to create simpler URLs using this. Instead of /volunteers/communities.php?id=Hedrick_Summit I can do /volunteers/communities/Hedrick_Summit which is more pleasing to me.
As for the choice of CakePHP, I have briefly toyed around with that framework. What I don't like about frameworks in general is they often have to be too general, to the point it results in extra cruft and slower page rendering. And the moment you have to do something that pushes the boundaries of the framework, and you will, you end up fighting the framework.
But to be fair, CakePHP seems to be adequate and generally well-designed. I personally took issue with the ORM layer but that was me striving for perfection and actually trying to do work in the SQL query. It has a reputation for being slow, but unless you're trying to build the next Facebook you should be fine.
Using a single file "entry point" gives you more flexibility when it comes to routing requests to various logic - you'll only ever have to worry about filtering one spot in a request chain.
These are really subjective questions.
I, once, wrote a CMS in php from ground up for my 3rd year project.
What I did was basically:
Checking how other people did it (Plume CMS and CMSmadesimple were a good start)
I didn't use any framework (that was a requirement)
and Yes, I used index.php with multiple params to handle different pages.
Answer is yes use multiple files in multiple directories, it makes all difference in the world when you need to debug or scale.
I would advise you to keep in mind the MVC (Model-View-Controller) pattern.
It is one of the most commonly used (and often misused) patterns in the CMS field.
Also, don't be afraid about looking what other people are doing. Read the code from Joomla, Drupal and other open source CMS. Have a look to language different from PHP to have a comprehensive glance about the possibilities.
Don't try to simply re-invent the wheel. Even if this is simply a Uni assignment, try to put something new on your CMS. Something that would push me to use yours instead of other CMS.
is cakePHP a good choice?
That's a highly subjective question and as such unanswerable. Though, if you want to experiment with architecture (eg. compare front controllers to page controllers), you probably should build more from scratch, as a lot of those decisions have already been made by the writers of said framework (And a lot of other frameworks, for the matter).
use one file for everything or use multiple files?
It's called a front controller (single entrypoint) or page controllers (multiple entry points). Get a copy of Patterns of Enterprise Application Architecture by M. Fowler.
do you have any good general advice on building more complex websites using php or any best-practices advice (i don't really understand why they don't teach us this in school)
There are billions of CMS's. Find some of them and analyse them to find out what they did and how they differ from each other. Trying to categorise the different approaches and compare their strenghts/weaknesses could make for a good paper.
I'm about to start on a small, static website project: no database or CMS required. Basically, a brochure website.
I used the CodeIgniter framework recently to develop a full-blown web application, and I'm wondering if it appropriate to also use CI for smaller, simpler sites.
Typically for a static brochure site I would write regular PHP pages with a few includes thrown in to save on repetition (i.e. HTML with a sprinking of PHP), but this time around I'm wondering if my new friend CodeIgniter might be able to streamline the development process.
Is it sensible to consider a framework for such a simple project, or is it overkill? I'm worried that I might be the proverbial carpenter whose only tool is a hammer, and sees every problem as a nail!
I think almost never, the needs change and come more with time... so it is better to have a good base using a framework to wait the future needs. but if your project will not have a long live time and your needs are reaaally simples then i think is not necesary use a framework.
I personally would never develop a site outside of a framework for anything more than a single page brocure-ware site. I work so much faster inside the framework.
I'm a Python/Django developer but here's my take.
I've done some small non-framework sites with PHP and I don't know how PHP frameworks compare to DJango, but if they're anything alike the fact remains that I'm far more proficient developing within a framework than to code something from scratch by hand.
It helps me stay organized if nothing more than giving me the VC of the MVC. Django provides me with a lot of built-in tools, like form handling, that make my life much easier even for small sites.
I'm going to presume PHP frameworks provide similar things, maybe not though.
You also can't anticipate how the site will grow over time. It's easier to maintain something built in a framework, and if you ever need to extend the site in the future it's nice to have some structure behind it.
Since I tend to either inherit bespoke frameworks, or write my own, I would peg it at about 3 pages: if it's more, then setting up a framework is worth it. And if it needs a DB, then odds are good you'll end up with more than 3 pages, anyway. :-)
I recommend Rapyd, a "minimalistic and rapid PHP framework".
How long is a piece of string?
I use CodeIgniter (specifically PyroCMS) for crappy 5 page brochure-ware but that is purely to let clients admin their own pages easily with a WYSIWYG.
Any client will say "Wow, news, contact form and I can get me some of that Twitter too?!" so I just dump it in there to save everyone time.
If you are developing from scratch there is no point if the content is static. Something like CodeIgniter helps with DB interaction, Form validation and the breaking down of multiple pages into logical chunks i.e Controller classes and methods.
If you have no db-content, don't handle forms and don't have many pages then there is litterally no point adding the overhead.
That said, try my Twiny framework for literally the smallest MVC framework around.
If you don't need a database, CMS and is just a simple static HTML/css/PHP page, I don't think you can go wrong creating a site without a framework. Plus, if you have been using frameworks for a long time, you can have a break and do "code for code" and have a feel what it's like to code from scratch :)
Site is never small if the client is there who may want to ask you to add more functionality at any time :)
For a simple site like that. why even use a framework why not use something like concrete5. Overkill? definitely. but hey it is easy and requires almost no coding so upkeep is a breeze.
The site would be up and running in less than an hour and it makes you look good in the eyes of your customer and that can't hurt.!
I don't think any project is too small for a framework, I think some frameworks are too big for small projects. Everyone hopes their website will grow. So no matter how small the site is now, growth will be easier to manage if you start with a framework.
The only case when framework would be an overkill is with a throw-away scripts, such as when you need to quickly automate something that you won't need to do again ever. For anything that will enter execution cycle more then few times framework is a probably would be better.
If it requires under several hours of work - then it is small. Anyway if you plan to devote more than "several hours" - definately use a framework AND a control revision system.
It depends. If you're positive this is all the site you're working on will ever be, or migrating when future needs arise, then I can't see why there would a reason for using a framework, unless you feel more comfortable working with one.
As a personal example, I recently worked on a semi-static website, for which I put together a minimal framework which worked as a caching preprocessor for static html, inserting common html-elements into preset places. This allowed for some dynamic content, yet still using only static html for content.
I'd say you're answer lies within a formula consisting of future development needs, your own working preference, and performance.