As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am currently working on a legacy PHP application. To give you an idea what the application is like:
The backend is about 14,000 LOC. The frontend is is about 3,000 LOC.
Each url is a php script, no use of classes.
Each of those php scripts has a smarty template associated with it.
It makes heavy use of PEAR form generation plugins.
Frontend is offered in two languages. This done by duplicating the php scripts + templates.
It does not follow many best practices, like escaping all sql parameters, redirecting on a post request, putting php scripts out of web root, XSS protection, CRSF protection.
The app has two main developers, I am working on it temporarily to help out.
The app is used by several client. Each of them might have a slightly altered version.
Let's say you had two weeks, what would you do to fix this application? Is there there any framework you would recommend that work particularly well with this type of app and which can be introduced gradually?
I was thinking maybe start by introducing ORM, to get rid of sql injection and improve the spaghetti code to construct sql queries.
EDIT 1:: Since people seem to dwell on the SCM issue a lot. I do use git to keep track my own local changes. I am only working on this application temporarily, so I am not really in the position to tell the other developers which tools to use. Also, that was not really the question.
EDIT 2: The reason that I was considering a framework was a) the other developer brought it up b) it would give the project a more rigid structure, so mistakes (like CSFR) are more easily avoided in the future.
You should rewrite in very tiny bits of code, don't try to refactor the whole application at once. Do it while you implement fixes or something anyway. Always leave the code with improvements.
This is especially true if the application works just fine. Most users won't understand why you need to break their application to improve the code quality when the bad code worked perfectly fine for them.
If you rewrite an application you always loose all legacy knowledge that has been implemented in the application like old bugfixes. Maybe there is a bug and it already had been identified in the past you would probably need to tackle that again.
I wouldn't focus on implementing a framework in the beginning btw. You should try to focus on object oriented programming and implementing a design pattern where applicable. Implement a framework when your code is already somewhat clear and structured.
Let's say you had two weeks, what would you do to fix this application? (It's insecure and has spaghetti code.)
First of all get en ligne what needs fixes first.
You can't turn spaghetti code into modular one within two weeks if you haven't analyzed the application so far. Additionally to refactor the code you need to get it under test first which can be problematic with legacy code. There are books written about techniques for such, but not all apply well to legacy PHP applications (but have very useful information anyway if you haven't done maintenance for legacy applications so far).
So you probably want to move database related code into a module of it's own while taking care about SQL injections. If you choose an existing database layer for that you can specifically say by looking into the code which scripts have been ported and which not.
You already use a view component, I would stick with it for the moment as you really have a short time-frame only.
Pressing an existing framework onto your current code-base seems counter-productive to me. You are merely looking for lightweight, existing and tested components so that you can reduce the own-written application code by using third-party components.
there is no scm
From all what you've shared so far about the application, this is what needs a fix first. Put it under source control. Before that you don't need to discuss further.
I've given a more lengthy answer with this question: How to implement MVC style on my PHP/SQL/HTML/CSS code?.
I would recommend Symfony PHP Framework. Two weeks seems too short to migrate your application, especially if you don't already have Symfony skills.
Zend Framework is also a very good PHP framework.
Migrating/re-factoring this application part by part would cost too many man hours than rewriting it.
If you rewrite, its better to rewrite from scratch. That is rewrite it from the requirement.
When you rewrite maintain the old site. Use branching in your SCM. If there is no SCM, start using it from now and branch afterwords.
If it runs flawlessly (after lots of tesing) then it worths rethinking about migrating.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
For the past months I've been getting into Web Development, I tried both sides of the coin: ASP.NET and PHP, I quickly fell in love with the second, the documentation and the community was just very helpful.
I started out by reading PHP for Absolute Beginners, this gave me a decent grasp over the language.
Enter frameworks! After going around the web, it became clear that there was one framework that really suited beginners: Codeigniter. I absolutely love CI, through out my programming experience in college I've always relied on good books. CI didn't need a book. The documentation is so well written anyone with a little bit of PHP experience can get into it.
Learning CI led me to development websites (such as Stackoverflow) and I started reading things that kinda make me sad, "CI doesn't scale on big projects", "CI isn't even a framework", "CI is for newbies, get pro like me bro".
Ok, so maybe CI shouldn't be used for huge projects - at least that's what I got from the overall community. But I'm wondering here, where should I go from now? I feel like I should get some experience in at least a few MVC frameworks, but it's kinda confusing on where to go at this point, today Zend is best, tomorrow Symfony is, but damm, that Yii s looking good too! All of these frameworks are getting updated to 2.0 and the documentation is scarce, there's not many books going around (if any), the respective websites have a lot of information, but for someone coming from CI, it all just feels very intimidating to start out. Starting projects with Windows CMD? PHP accelerators?
I'm guess what I'm trying to ask here is, how do you professionals see the PHP framework world these days? Which Framework would you recommend? Should I hop into this 2.0 bubble or are these versions not stable yet? And if possible, could you point me in a general direction when it comes to documentation?
Thank you for your time.
A framework is merely a tool to achieve a purpose. For you, to get a grip on the language try continuing with CI. The things you will learn - the concepts - will translate to other frameworks, even if their implementation is slightly differnt.
I personally favour Yii, but I have dug up symfony, zend and CI as well as few others in the past. One is not better than the other for most apps; look into differnt things, see what you like and roll with it.
What framework isn't really the question. What you should be doing, IMO is, try to 'learn to learn' rather than just 'learn'.
What I mean is, you should try to learn php well rather than a specific framework X.
That way, when time comes, and you have to build a scalable[scalable isn't even on my browser's dictionary yet!] system, you can figure your way through, with the experience you would have accumulated. This is what I believe Steve Jobs refers to as connecting the dots in a famous speech.
I've used many frameworks in the past. I used CI to start and then moved over to Yii as I gained experience. Frameworks may provide the project with tools that you don't have to write yourself, saving time. However there may be performance issues. CI is great and I haven't had too much trouble with it. You can slim it down and remove functions that you are not using. With CI I have created full Web APIs with them with no problems.
I guess what I am trying to say is that it may be your preference or client preference on which framework to use.
Firstly, there web development isn’t a coin, and there’s more than two sides. There’s a plethora of web development languages: PHP, .NET, Python, Ruby and so on.
Secondly, I don’t think you should be looking at frameworks if you’re new to web development/PHP. Learn the language first. Frameworks instil framework-specific conventions only; so when it comes to working with another framework or even vanilla PHP, you’re going to be at a loss. A knowledge of PHP assists in choosing the right framework for the job. Investing in one framework this early will only make you reliant and dependant on that framework.
I speak of this from experience. I once worked for an agency that was hiring PHP developers. During the interview process, we got applicants that claimed to be PHP developers will knowledge in frameworks such as CodeIgniter. When given a simple programming task (take an all-uppercase phrase and make it title case) the majority failed. Why? Because they had built everything in frameworks and not learned PHP itself. So when they were put in a situation where their framework of choice wasn’t available, they stumbled.
Don’t make this mistake. Frameworks are good, but only when you know what you’re doing and definitely not as a language learning tool.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am about to begin development of a new website and have been doing research on PHP Frameworks. I'm not an advanced PHP developer, but I have been developing web sites and apps (in asp.net) for a few years now.
My website will primarily be AJAX-based (using jQuery) and making lots of calls to web services. After some research, here's what I came up with:
CakePHP: Originally started developing in this, but found it too complex. The fact that it forces you to use and learn all this new stuff just to use it was a bit daunting, so I put it aside for the time being.
Zend: The performance of the framework leaves me a bit skeptical, but I heard it has great support for creating web services. I also heard it was a bit complex.
CodeIgniter: No real reason for not using this one. Based on what I've read CodeIgniter and Yii are very similar, but Yii is a bit faster and doesn't have un-needed code for PHP4 (since I plan on developing exclusively in PHP5).
As far as Yii, the only things that scare me about it are that it is newer than the other frameworks so it has a smaller community. It also doesn't seem to have a ton of web service support (only SOAP, from my understanding) as opposed to Zend.
So my questions come down to:
Should these things worry me? (not as big of a community, poor web service support)
Is there anything else I should look into?
Is my choice of Yii over the other frameworks ok for a primarily AJAX-based web app?
Bara
You need to document the requirements of your project and the reasons behind why a framework is even required in the first place. Then look at the future of the site and associated functionality. Then choose the framework that provides the strongest functionality to satisfy those requirements. Don't get hung up on opinions. Read the documentation and identify the components you want to use, narrow your search from there and then experiment with them all.
Performing your due diligence will pay off not only for you, but for your client who is paying the bills.
To sum up:
Identify required components of site.
Research frameworks and identify matches for your requirements.
Experiment and learn which ones work best for this job.
Edit/Opinion Additions:
If this is merely a personal growth project, then I would look at using what's going to look the best on your resume. Zend has the biggest name and a solid product, so they win by default because it's the old "can't get fired for IBM argument." Some big players are using Symphony, but it's a big learning curve. Yii, Cake, Kohana all have pros and cons and are great in their own way.
I've used to be a developer of Symfony, CakePHP, Zend framework, Kohana and Code Igniter, but around 1 year ago I discovered Yii, My first (and second and third) impression was excellent:
Easy to learn
Easy to implement
Easy to use and extend
Very, very, very fast
Support of many languages
Support of many software, servers and accelerators
Support of MySQL, PostgreSQL, SQLite, and Oracle... Firebird support is beta.
Many other features that I don't remember right now.
Download it, use it and implement your project with it,... you'll be amazed.
Now I ask your questions:
Should these things worry me? The community is not as small as it seems, Currently, Yii has an active community. We are not a few.
Is there anything else I should look into? You should look your needs: Database you'll use, Web server, and others, as Randy said.
Is my choice of Yii over the other frameworks ok for a primarily AJAX-based web app? Yes, It is.
As a main developer of Yii, I'm maybe not totally fair (but want to!), however, for objectivity I should mention I tried both Zend and CodeIgniter before.
In the earlier releases of Yii, benchmark tests were very impressive, and because the leadership doesn't want to have this framework bloated, not all feature requests get implemented. This may sound a little disappointing, but if you're experienced enough in programming and design, you are already aware of its potential.
On the other hand, Yii still supports a really wide variety of practical and real-life solutions. This is somewhat subjective, but if you look at those often used classes, you will find out their power in real issues.
The documentation (especially the API) is serious-tuned and very specification-like, which you may find strange and cold in the first hours, but in the long run, it'll definitely ease your job (unlike those fashionable docbuddies, which would like to make friends in method signatures).
These all contribute to your development time. People are able to create serious applications within weeks!
In 1 1/2 year using Yii, I have about 15 sites online, all working flawlessly, fast, and Yii made very easy to create them. And most sites aren't trivial, they are large real world sites. I can provide links if requested.
So I can assure you that by choosing Yii you will certainly be able to do any kind of site you want, and it will be fast and safe.
Pretty much every modern web framework has excellent support for XHR/Ajax. It really just boils down to your personal preference based on your current knowledge of the language in which regards to framework you'll like the most.
I would also advise Kohana as it's pretty stable, mature, and has excellent support.
You won't really know until you play around with the framework, I suggest dipping your toes in a few of them.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
For those of you who have had the opportunity of writing web applications in PHP and then as an application server (eg. Python-based solutions like CherryPy or Pylons), in what context are application servers a better alternative to PHP?
I tend to favor PHP simply because it's available on just about any web server (especially shared host), but I'm looking for other good reasons to make an informed choice. Thank you.
I have a feeling that some of the responses didn't address the initial question directly, so I decided to post my own. I understand that the question was about the difference between the mod_php deployment model and the application server deployment model.
In simple words, PHP executes a given script on every request, and the application has no knowledge of what has happened before (unless it is emulated somehow). Moreover even the source code is being parsed on every request (unless you use a bytecode cache like APC). This process can be slow, especially if you have a framework with complex initialization.
In contrast to this, the application server has to be started once, and then it waits for a request to be processed. The application server should clean up resources after every requests (allocated memory, open descriptors, etc.), it can also pool certain resources (like database connections) that can be reused between requests for extra performance.
This later model (application server) is more efficient in most cases, but on the other hand more difficult to setup and maintain. It is also more demanding, as you have to pay more attention to the resources you utilize, in order to avoid resource leaks.
The advantage of deployment for PHP is a huge one. You will also have a large developer base, and sound like you already have considerable expertise. In general if you know how to use a programming language well, you are safer to stick with it.
The advantages of using a Python web framework like Pylons are that your code will be neater, and more maintainable. Of course this is possible with PHP, but seems much harder to achieve. Python is simply a nicer language than PHP, so that might affect your decision.
Personally, I would not describe either Pylons or CherryPy as an "application server", if you want a Python application server, try Zope. (They both do serve WSGI Applications, but that is a topic for another question.) There seem to be plenty of equivalent frameworks for PHP, and they have been listed in other answers.
There are several products in PHP which fill the same space as CherryPy or Pylons.
(except, of course, they don't run Python ;)
Have a look at -
CakePHP - http://www.cakephp.org/
Symfony - http://www.symfony-project.org/
Code Igniter - http://codeigniter.com/
Zend Framework - http://framework.zend.com/
Personally, I prefer Drupal, which works as a great framework and comes with a lot of CMS and community site features out of the box. The ones above are quite different in many ways, but any of these should offer you the best of both worlds if you want an app framework / appserver that runs on PHP.
Drupal - http://drupal.org/
Which one is the right choice is largely a matter of taste, although each has its various advantages and disadvantages.
There are many more - these are just the ones I've heard good things about from colleagues and collaborators. It's not a complete list.
Python web-apps tend to require more initial setup and development than the equivalent PHP site (particularly so for small sites). There also tend to be more reusable pieces for PHP (ie Wordpress as a blog). Configuring a server to run Python web-apps can be a difficult process, and not always well documented. PHP tends to be very easy to get running with Apache.
Also, as PHP is very widely used and is heavily used by beginners, there tends to be very good documentation for it.
However, Python is much more fun, and much more maintainable. It scales well (in development complexity terms, rather than traffic).
Personally, I would also say that using Python tends to train you to solve problems in a better way. I am definitely a better developer for having learned the Pythonic way of doing things.
Using application servers like Pylons, Django, etc. require much more work to setup and deploy then PHP applications which are generally supported out of the box. I run a few Django apps and had to learn a bit of configuring apache with mod_python in order to get things to work. I put forth the effort because coding in python is much more enjoyable to me than PHP and after you get the Apache config right once you never really have to mess with it again.
On another note, if you decide to go with a framework like Django, Rails, Pylons, .... they tend to solve a lot of small repetitive tasks that you would otherwise do on your own. But frameworks are their own huge topic of discussion.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for some quick thoughts about a business application I am looking to build. I'd like to separate the three layers of presentation, domain logic, and data using PHP, Python, and PostgreSQL, respectively. I would like to hear, possibly from other folks who have gone down this path before, if there are problems with this approach, if I am targeting the wrong tools, etc.
I'm looking at PHP because it is widely used, fairly mature, and I can find ample people with skills in PHP interface design.
I'm looking at Python because of the benefits of readable code, because I hear can find more Python programmers that also have subject-matter skills (in this case, finance), and it's an open source language. Plus, it seems easier to code with.
I'm looking at PostgreSQL for the transaction-level features. MySQL is also an option here, but I don't need to debate this aspect.
This is not a web application, although I would like to utilize a browser for the user interface. This is more of an Enterprise Application, but for a small business with moderate numbers of users (maybe 5-10) and a modest number of daily transactions.
What is important is that we are able to upgrade the database or domain logic or interface separate from the other layers in the future.
I'm NOT looking for a buy vs. build debate, as that's a different discussion.
Thanks for any insight
Look at Django.
Python code. A template language that permits some of the same features as PHP -- slightly different syntax.
Model is divorced from view functions ("business rules") and divorced from presentation. This is enforced throughout Django.
One of the common questions is "why can't I do -- some crazy PHP-like thing -- in the Django template?" The answer is that presentation is not processing. Do your processing in the Django view functions. Render the results as HTML in the template.
Also, Django has an ORM layer to divorce you from petty SQL considerations. MySQL or PostgreSQL are more-or-less equivalent from within Django.
Edit
"Maturity" means a lot of things. You specifically mentioned skilled people as a sign of maturity.
Django is pure Python. If you can find Python people, they can learn Django in a few days. They just have to do the tutorials.
A Django-powered site is usually Apache + some glue + Django. The glue can be mod_wsgi or mod_python or mod_fastcgi. You have to manage this configuration with some care because there are several moving parts. This, however, is the same Apache config problem you have with PHP -- nothing new here.
A Django site has one or more Django server instances, each with a settings file, a URL mapping and any number of applications. Pure Python at this point.
A Django application has URL mappings, model and views. All pure Python. Unit tested with the Django extensions to Python's own internal unittest framework.
The model uses an ORM layer. This may, perhaps, be the single most confusing thing in Django. People sometimes design very odd models because they think either too high-level-uber-generic or they think too much in SQL. Django is a middle ground of mostly object-orientation with some SQL consideration. Get this, and you're unstoppable.
A Django application may have templates, which are in their own template language. This would be about the only non-Python thing that's of much interest. You may want to add custom tags -- pure Python.
You'll probably have JavaScript (also true for PHP and every other web application framework). Nothing new here.
Since Django's admin application automatically handles basic CRUD processing, you don't have to write this. You are free to write all the transactional stuff you want. But you don't have to. This leads you to a very, very powerful hybrid.
You write a few complicated, critical transactions. Pure Python, BTW.
You don't write any of the dumb table-maintenance transactions. No code at all is superior to Python or PHP.
After you get your feet wet with the template engine and CSS's, you can tailor the admin interface to look like anything you want. This is HTML/CSS stuff, no Python or PHP.
Bottom line. Most of the skill set is Python. The ORM is -- syntactically -- Python, but requires some care in doing things simply and cleanly. The template is it's own language, but considerably simpler than PHP. The rest is SQL, Javascript, HTML, CSS, Apache and what-not.
Edit
Django Maturity
See http://www.djangoproject.com/community/ for the number of active projects.
Join http://groups.google.com/group/django-users for daily flood of emails from users.
The Django blog stretches back to '05, meaning they had years of solid experience before finally releasing 1.0 in September of '08. Development apparently began in '03.
I'm going to assume that by "business application" you mean a web application hosted in an intranet environment as opposed to some sort of SaaS application on the internet.
While you're in the process of architecting your application you need to consider the existing infrastructure and infrastructure support people of your employer/customer. Also, if the company is large enough to have things such as "approved software/hardware lists," you should be aware of those. Keep in mind that some elements of the list may be downright retarded. Don't let past mistakes dictate the architecture of your app, but in cases where they are reasonably sensible I would pick my battles and stick with your enterprise standard. This can be a real pain when you pick a development stack that really works best on Unix/Linux, and then someone tries to force onto a Windows server admined by someone who's never touched anything but ASP.NET applications.
Unless there is a particular PHP module that you intend to use that has no Python equivalent, I would drop PHP and use Django. If there is a compelling reason to use PHP, then I'd drop Python. I'm having difficulty imagining a scenario where you would want to use both at the same time.
As for PG versus MySQL, either works. Look at what you customer already has deployed, and if they have a bunch of one and little of another, pick that. If they have existing Oracle infrastructure you should consider using it. If they are an SQL Server shop...reconsider your stack and remember to pick your battles.
I can only repeat what other peoples here already said : if you choose Python for the domain layer, you won't gain anything (quite on the contrary) using PHP for the presentation layer. Others already advised Django, and that might be a pretty good choice, but there's no shortage of good Python web frameworks.
I personally agree with the second and the third points in your post. Speaking about PHP, in my opinion you can use Python also for presentation, there are many solutions (Zope, Plone ...) based on Python.
Just skip PHP and use Python (with Django, as already noticed while I typed). Django already separates the layers as you mentioned.
I have never used PgSQL myself, but I think it's mostly a matter of taste whether you prefer it over MySQL. It used to support more enterprise features than MySQL but I'm not sure if that's still true with MySQL 5.0 and 5.1. Transactions are supported in MySQL, anyway (you have to use the InnoDB table engine, however).
Just to address the MySQL vs PgSQL issues - it shouldn't matter. They're both more than capable of the task, and any reasonable framework should isolate you from the differences relatively well. I think it's down to what you use already, what people have most experience in, and if there's a feature in one or the other you think you'd benefit from.
If you have no preference, you might want to go with MySQL purely because it's more popular for web work. This translates to more examples, easier to find help, etc. I actually prefer the philosophy of PgSQL, but this isn't a good enough reason to blow against the wind.
Just to throw it out there... there are PHP frameworks utilizing MVC.
Codeigniter does simple and yet powerful things. You can definitely separate the template layer from the logic layer.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Drupal is very much a "Do Everything" CMS. There are modules that allow you to add almost any functionality, which is great. However, it feels like a lot of the features (v5 and v6) seem scattered around and unintuitive for the user. As a developer, I'm left with the feeling of having patched a site together using bubble gum and string.
For example, to add text to the default search box (that disappears when clicked), you have to either add some jQuery code OR override the theme. I've also found the menu system more complicated than it should be.
Am I the only one with this opinion? What things (if any) would you change about Drupal's core?
To me, the biggest shortcoming of Drupal is that large portions of a live Drupal site are stored in the database. Since there's no automated way to migrate content or configuration between systems, rolling out changes to a live site must either be done manually or dealt with by excessively complicated code.
One of Drupal's biggest shortcomings is that it dances on the line between a turnkey tool for nonprogrammer site builders, and a framework for developers building complex webapps. It has some cool stuff to offer both groups, but the concessions to one crowd always tend to trip up the other.
The growing trend in the Drupal community is to explicitly build developer APIs, then layer administration UI and end-user UI on top of the APIs. This is a good thing, but there's also still a lot of legacy architecture. The project turned 8 years old this week, and every site requires a mix of modules that are evolving at different paces.
If someone hasn't already built a module that does what you want, effectively leveraging the system without hacking core code requires grokking a lot of different internal APIs, a lot of unique-to-drupal data structures, and studying up on some occasionally funky workflows. A lot of terribly bad and impossible to maintain sites are floating around in the wake of people who needed to do tricky stuff and didn't have the expertise (or the time) to research the "right" way to do things.
(Disclaimer: I just co-authored a couple of chapters for a book about Drupal, and I do Drupal work full-time, so I'm about as far from 'unbiased' as you can get. But I do like to think that I keep perspective. I heart Django, too.)
Drupal will get you 80% of the way there out of the box, but that last 20% will take months and months.
The lack of true object oriented design means that you frequently have to rely on other developers' foresight to leave "hook" functions to let you alter a certain behavior.
Using Drupal 5 I've also run in to situations where the only way to complete a relatively simple design change is to patch Drupal itself (and then be sure to reapply patches with each new official Drupal release). But, to be fair, you should have seen how bad it was in Drupal 4.
I'm also annoyed that when I take the time to identify a bug or quirk in the current production version of Drupal, I submit a patch, and the patch is never committed because, basically only security bugs get fixed in the current stable release.
Drupal is an impressive system. It's surprisingly small for all it does, and it's module system is extremely powerful. But as Eli said, a lot of your tasks are going to rely on other developers doing something in a particular way.
There's a debate within the Drupal community over it's design. Drupal was around before PHP's OOP features were strong, but now that they are, there's frequent discussion about changing the system to use object-oriented data structures. Depending on your tastes, this could be a downside to you as a developer. I'm of two minds about it myself.
The system can also seem to be very "magical" to newcomers, in that somehow it does all this crazy stuff with little explanation. "I only just defined a function, how the deuce does Drupal know how to call it?!"
However, I must say that in general I'm a big fan of Drupal. It's a good system that gets loads better with each major version. I for one can't wait for 7.
Drupal is good to get started but you spend more time 'undoing' than actually getting things done. This has been changing especially with the release of Drupal 6 and to be fair it's more apparent in contributed modules.
Managing migrations is also a problem as Sean said. I still don't know of a good method of moving changes from a dev site to a live one.
I am not sure there is anything I would change in the current core and most of the deficiencies are being worked on. Image management needs work, the default admin interface is a little cluttered making more complicated layouts without getting views/panels, etc. involved could use some work.
i find it awfully complex. as a php developer im tearing my hair out on a daily basis over issues that have nothing to do with php but with drupal itself. how / why / when does it do X? its a big beast that needs to be tamed. documentation is limited to a few very good guides, a whole lot of shitty ones, and even more useless forums threads that always seem to pop up in google.
usability on the backend is crap. a custom theme will also alter the layout of the "admin" part of the package which can be extremely frustrating and results in less than pretty layouts.
if you're working with html slicers, its impossible to use html that has not been created specifically for drupal. it pretty much forces you to use drupal-html, with lots of divs, 5 verbose classes per div, etc. by nature, html/css guys can not be expected to know drupal at this level.
i dont like the way it relies on filenames (10 words long, with very subtle differences between them) to build a theme.
having said that, some of the stuff it can do is very cool and saves you days and days of custom php development
Drupal gives powerful tools to Non programmers ,They can easily build up a full featured site with less time. But the problem is that learning curve is too high for Drupal.
If a person is new to drupal and want to make something customized it will take lot of time if he wants to do it in proper way. There are lot of ways to do a single thing in drupal,Finding out which is he best or proper for a new comer is a head ache.
I think it's high learning curve is the only shortcoming as most companies struggle finding good Drupal talent. http://drupalize.me/ and http://buildamodule.com/ are doing very good job to reduce this high learning curve.
I find that the default admin interface isn't very intuitive compared to other cms' like modx or joomla/mambo
It's written in PHP4. This will change as of version 7. You can write your own modules in php5 of course. As a seasoned Drupal developer and I find my resume has suffered due to my limited exposure to php5.
It's not the best for running services like SOAP. Calling the whole Drupal stack to provide a web service is too much of a performance penalty. The services modules are still in development.
No database transaction support. This becomes an issue when you scale it up to extreme loads.
It would be good to run tests from the command line. This was possible with simpletest 1.x but the current version doesn't support it very well. Simpletest is not mature enough. A clean Drupal install can fail tests. Some of the default included tests force you to use content types and modules you may not need and you can't disable these without hacking the simpletest module.
It has a seemingly bad security record: http://secunia.com/advisories/search/?search=Drupal