I'm a PHP developer who uses drupal whenever the job looks like it could benefit from a CMS. I was having a discussion with a colleague who said that it helps him a lot with clients that he knows multiple content management systems. To me, this sounds like dividing one's efforts, and I'm not sure if it's worth it to invest the time learning another content management system.
Is it often that jobs lend themselves better to one content management system over another? or can most content management systems handle most jobs?
I'd say that a thorough knowledge of one CMS is more important, you're just so much efficient if you really know what you're doing. Drupal is also very flexible, you can do just about everything with it, even though it sometimes is quite complicated.
I don't think you gain much by learning a similar CMS, but it could prove usefule to know a CMS that is very different from Drupal. For example a very simple CMS that you can use if you just don't need all the complexity Drupal brings in.
I'd say a bit of superficial knowledge of a wider range of CMSes won't hurt you. You don't have to become an expert right away, but knowing their particular strengths and weaknesses and the mindset they come with might prove handy. When you decide you need one of them, there's usually still enough time to dive into the documentation and make it work.
If you're a PHP developer, you might find your development skills can stagnate if you only code in Drupal all the time. You're not exposing yourself to different methods of software development. For example: Developing in Drupal 6 doesn't give you much experience in Object Orientated Programing. It's largely procedural (with the exception of Views).
While Drupal is a quality product, there's definitely a misconception that it is flexible enough for everything. I've been developing high profile sites in Drupal for some years and I've seen quite a few projects developed in Drupal that should have been done in another framework or language. Some of them have. I would diversify. You'll be able to make better decisions.
I'm currently branching into Ruby on Rails and I'm finding it's giving me some valuable perspective. It's also an excellent framework for those projects where a CMS may not be appropriate. Also: Some of the best practices in RoR I am incorporating back into Drupal.
I use only the two most popular open source, Drupal & Joomla. Knowing more than the two most popular programs when it comes to web design is overkill IMHO. As already mentioned I'd focus on one a little more just to be more adapt at it.
Plus you may get a client who just wants you do develop a ready made template they like but who doesn't have the experience to use the CMS.
Lastly I personally don't consider Wordpress to be a full CMS but it's also a good idea to learn WP mostly because it's so popular but also because it's great for quick 3-6 page basic sites.
It depends on the kind of work you're doing. If you're always building sites from scratch, and have full say in which CMS you use, it makes sense to stick with what you know and learn it inside-out. If, on the other hand, you're ever brought into a project to modify an existing site, or you might be hired by a client that already uses an existing CMS for something else, it will help if you know more than just Drupal.
Related
Here's the thing. I love Ruby and I've been using it for the past couple of years. I love everything about the language and the community.
But I have this soon-to-be-large WordPress site, where I have to implement a lot of additional functinality. The problem is, I really hate customizing WordPress beyond simple theme design.
Examples of things I need to do:
add some additional information to profiles, like karma/points/reputation system
offer users to create their own page after they're allowed to do it
pulling data from some external API and displaying it on the user's profile
I got really used to the whole agile BDD workflow, where I go from Cucumber features to RSpec to implementing the stuff, and the whole WordPress architecture looks to me like ok I'm just gonna have to pray this works.
I'm not sure if it's even wise to try to write some part of the app in Ruby and try to make it work together with WordPress, or if I should just take WordPress as the only thing I've got and make the most of it's strenghts and weaknesses.
The main issue for me is that everything I'm going to write in PHP will take about 5 times as long than if I do it in Ruby, and it will probably also be more secure and robust, since I don't have as much experience with complex PHP stuff. I mean I've done a lot of PHP in the past, but I always felt like the whole thing is going to fall apart at one point.
I know there is probably no definite answer on how to approach this, but any suggestions are welcome.
We've integrated a Rails app into a TYPO3 installation. It worked out pretty well. The key point is to use Rails' support for adapting models to tables of a legacy app. An important point is to handle authentication which we handle by passing the TYPO3 session key to the Rails app in a hidden way (using PHP as the web-client and passing appropriate headers) and looking it up in the session table (respecting the session timeouts). The Rails app itself is mapped into a sub directory using passenger. Performance is very good, it's even amazing compared to our previous implementation trying to use Extbase.
So, in conclusion: If you do it right and the interfaces between the two apps are well planned such an approach can offer great benefits and the best of two worlds. If not done right or you don't understand some implications of Wordpress (like security) you will create a big mess prone to security breaches.
BTW: We reached feature parity with the Extbase (MVC framework in TYPO3) solution after 4 days of using Rails. The Extbase solution took 6 weeeks and caused a lot of headache and trouble. So your time factor may be even better than 5:1.
Why not learn how to to Behavior Driven Development in PHP for WordPress? In fact, this is one of the great opportunities for developers in 2017. We now how full blown BDD frameworks in WP-Codeception, so that you can even automate Gherkin feature files, just like in Cucumber. Check out WordPress-BDD.com for some usefull info.
I'm thinking about rebuilding my website from scratch, but this time, using a CMS. Everywhere I turn people tell me to use a cms, but it's only now I'm really considering it. My site isn't too complicated. Is this a good idea in terms of workflow? I'm the only person who will edit the site, so if it's just a matter of workflow and efficiency, should I just convert now before it gets really big?
Sure, a few come to mind.
Deployment complexity. Many CMSes require a database, which means running a database process somewhere, and backing that up, as well as the rest of the code and assets for the site.
More space will be required to hold the CMS code for the manager, framework, libraries, etc.
Bloat could come into play, the CMS may, and likely would, implement features you have no use for.
Additionally any CMS will have some kind of limitations, some things will be more tricky to do than others when compared to a mostly static site.
Just read the code. That's often all the arguments you need. (If your needs are really simple and you don't need plugins and you don't need to write any code yourself I'd still use a CMS, though)
If your site is mainly a design showcase, and doesn't have real content in it, then a CMS will only get in your way and make things harder.
Otherwise, it will mostly be of help.
Along with everyone else's statements. If it's just a small site you don't necessarily need a CMS, but if you are wanting to use a CMS for client projects in the future, why not start now.
Deployment. If you're doing some big changes to your site or testing something, you'll probably want to try it out locally with a development copy of the database. Once you're done, how do you get everything to the live site without overwriting, say, comments that were made on the live site since you created a development copy?
Specialization. CMS's are great for some things, but they're bad at others. What if you want to add more complex functionality to your site? It might be a plugin or module at first, but soon you're writing all this code and you realize you should have just used a framework and built the CMS part yourself.
If it's a simple static site with a single editor and without any aspirations of using complicated functionality and you feel confident enough in your web language of choice, then go for it. Even if you don't feel confident enough, it should be a good challenge.
Write some minor templating so that you can separate your code from your design, have some simple way of adding articles or blog posts or whatever - it could be as simple as including text files from a directory.
Using a CMS, even in their modern and quite usable state will require more resources, hardware-wise. and will probably have a steep learning curve. It will also require maintenance and dilligent security patch application as new vulnerabilities appear. On the other hand a CMS can get you up and running with a basic site quickly, and grow with your needs if you feel like enriching it, as you get to use its large variety of ready made plugins and extensions. You want blog comments with users logging in via OAuth? No problem. RSS? There's an extension for that.
Bottom line is, if this is a simple static site with a single editor as you describe it, it should be trivial to set up some code to run it. You'll spend as much time on its template design as you would on customizing a CMS's template, avoid the initial learning curve a CMS requires, and not worry too much about the resources and maintenance a modern CMS requires. You will, however, be limited in functionality and future ideas by what you can write or integrate yourself.
It depends somewhat on the purpose of the site.
If it is a means to an end of getting information posted on the web, then adopting something like WordPress will quickly get you going, and provide lots of extra functionality that would take a fair amount of time to build in - e.g. stats, feeds, remote publishing etc. There are a few basic steps you'll need to go through setting up self-hosting on a shared web-hosting package e.g. creating the DB and unzipping the files etc but fairly straightforward really. And the time you save administering your website can be focussed on other things where you're making a difference or doing something different to everyone else.
However if your purpose is in part the learning experience of developing the functionality or you have unusual requirements that aren't in a standard CMS, then there is an argument for developing your own.
I want to learn and use Drupal or Django for the following:
dynamic web sites, medium database, multi-level users, paypal integration, content managment, speed (developing), security
I like MVC, ORM and object-oriented prg.
Which is better to jump into ? Which one is more mature, powerful, understandable, object-oriented and easier to use by the time ?
What about Python Spring ...
Also, which of these 3 are better documented, are better for a cv and have more extensions?
Known languages: php, java, mysql
Thank you !
I've built several sites on Drupal and Django, my conclusion is: if you need to create something similar to the standard drupal (or Ubercart) feature-set, you don't have much time for development, and you don't expect hight load pressure on a site - you should pick Drupal.
But if you do need to create something more or less custom (no drupal modules already available) you should go with Django - it is quicker and more pleasurable to implement custom complex features using Django. For example if my goal is to implement a second stackoverflow, I'll prefer Django because it will be extremely complicated to implement this badge-based rating system with Drupal.
P.S.
Studying Python (and Django) is an investment in your future, I think. You'll never be able to implement something similar to DropBox using drupal and php, although it could be implemented with java - but java is not so good from development speed perspective.
I'm primarily a (happy) Drupal developer these days, but a friend whose dev skills surpass mine has switched happily from Drupal to Django. Here's his set of reasons.
Drupal and Django doesn't make for a good comparison, as they are quite different.
If all you need is a simple website with a CMS and Paypal, I would go for Drupal. Drupal's strength compared Django is it's many modules (modular system), which most of the time can get you where you want. Drupal is also extremely flexible, and you can change almost anything from within your own code, and there is a huge demand for Drupal developers. You can also let site builders create content, display content and much from from within the AI.
Django on the other hand, is more simple and structured. It's based a lot more on code, making it fast and easy to develop something, but hard for non coders to change certain things. For sites that require a lot of custom coding, I usually prefer working with Django. Python is also a more structured programming language than PHP (IMO), and it's easier to make more maintainable code.
Jump into what you like or what attracts you most after getting a little overview of the capabilities and constraints. I never worked with drupal, but I can recommend django.
Consider your deployment. Pretty much every host will support Drupal. If you go with Django, you will need to select a host that supports fast_cgi or wsgi
You already know php, so just for that you might want to stick with Drupal. However, I prefer Django over Drupal for many reasons.
http://www.reddit.com/r/django/comments/bhvhz/the_onion_uses_django_and_why_it_matters_to_us/ provides some excellent background.
Basically if want things done properly with lots of flexibility, go with Django. If you're very familiar with php, don't feel like learning python, and your site requirements are basic, go with Drupal.
Something to keep in mind is that Django is a bona fide web framework, whereas Drupal is more of a web platform. That is, sometimes you have to hack Drupal to get what you want or that it doesn't fit all situations.
I had never heard of Spring Python but based on the fact that their own site is powered by Drupal, I wouldn't recommend it. Especially if you know Java already, why not consider the original Spring platform?
I've been developing with Django for more than 2 years and have built a couple of Drupal sites in the meantime (per client's specific request to use Drupal). My conclusions are the following:
Even for a smaller site I would have done it quicker building it from scratch with django (or maybe even PHP) for a simple reason, writing code for me is faster than hunting through drupal's unorganized mess of menus and options, or hunting on the web for a module that implements hack X to enable feature Y.
Migrating a site from development to production with Drupal is a big PITA. You can forget about using a VCS tool. All your work is in in the MySQL dump (including configurations, programming logic, views etc.), a few hacked up modules and the uploaded files.
I'm interested in using a CMS instead of building a website from scratch. However, as a software engineer, if I'm going to be using open-source tools, I'm going to use them to their full extent, including the possibility of developing plugins/extensions/modules and maybe even contributing core code.
I'm currently looking at WordPress, Drupal, and Joomla!. They all appear to have the features I need, either as core features or plugins. However, I'm curious how hard it is to learn the system and then develop for it.
Does anyone have experience with this? When using and developing WordPress, Drupal, and/or Joomla!, what were your experiences like?
I avoid Joomla like the plague. It is highly difficult to extend, especially if your use case isn't one of the ones their devs specifically designed the CMS for. Great if you want to do a small business brochure site, but if you're looking to heavily customise... ditch it. The pay-to-play nature of much of the dev community is a turnoff, too.
WordPress is very heavily specialised in the blogging direction. If that fits your needs, go for it - it's a slick, well supported, system. If you're looking for something that's a bit more complex in a CMS, though, go with...
Drupal. My favourite PHP CMS, hands down, with the exception of blogging. Functions like hook_nodeapi, hook_user, hook_form_alter, etc. make it essentially effortless to heavily tweak the function of nearly everything in the system. If I want to replace the password field in the user login form with an upload field and MD5() the uploaded file to verify the user, I can do that - without hacking core code, and in a few lines of form alteration and validation code. Pretty astounding the first couple times you do something slightly nutty like that.
I haven't used Joomla much and have never really needed to tweak Wordpress outside the design but have used Drupal quite extensively. Drupal seems to be becoming the standard for PHP CMS' which I think is quite a shame given how much is wrong with it. I won't try to tell you why you should use it, or shouldn't, but here's a few things that I find really annoying with it.
Complete lack of OOP. Ok, in Drupal 7 they're finally doing some OOP with the Abstraction Layer but the community as a whole still shuns the entire concept of OOP as it applies to the CMS as a whole. And given their dependence on modules and third party code doing a decent OOP setup would help keep the code more organized. Currently to avoid naming conflicts you need to prefix all functions and constants with your module name which can lead to some very long function names which can lead to some very long lines of code which can make things a little less readable than doing something like $node->parent()->parent()->title;
Drupal content is completely unorganized. When doing an information heavy site it's imperative that you have well organized content and Drupal simply doesn't allow this. Drupal's content management is just one large list of nodes with a few filters you can apply. There are ways you can use Drupal's taxonomy system and other modules to setup relationships but I've never found any that actually make the interface easier to navigate and make it easy to manage the content on the templates. At work I've created a module that allows this but it's required dumping weeks worth of development time into it a simple feature that any good CMS should come with out of the box.
The admin interface is absolutely rancid. This one pretty much speaks for its self but install a copy of Drupal and click around. Then take a look at say, the Radiant interface (Radiant is Rails I know, but we're talking UI here). Another example of a good UI for the admin would be FrogCMS, a PHP port of Radiant.
No ORM, and absolutely no attempt to have one, means you better like writing lots of SQL to get the data you need. While I generally have no problems with writing my own SQL it's starting to get a bit old when most good frameworks and CMS' built on them have at least some kind of ORM for you to use. Even if it's a botched one.
Drupal loves to use non-standard file extensions (.module, .info, .install, .inc, etc) so you better make sure your htaccess and/or virtual host is setup to not allow direct access to these files or all your source code will be wide open for the world to see.
Personally I think FrogCMS looks like it's off to a good start to be an up-and-comer if the maintainers allow the community to contribute to it and allow it to grow. You'll need to do more coding as it doesn't have a big feature set out of the box and doesn't have a plugin repository like Drupal or Joomla but from a coding standpoint it's setup with a pretty well done, albeit basic, MVC implementation that will help your code be more organized and easier to maintain.
I've only developed for Joomla! and have been a user of wordpress, but Joomla! development is too clumsy if you want to completely change the layout. Writing a plugin or 'component' is fairly easy if you know the way around the code, but getting it to do exactly what you want isn't so easy because it likes to force you to use it's MVC design pattern which I find too clumsy.
I've seen both the Joomla! and Drupal code base, and I'd say that Joomla!'s code is much cleaner and better documented. It also heavily uses the MVC design pattern which can be good or bad depending on your preference and what you want to use it for. It has the most extensive use of OO programming in any php project I've seen.
I haven't developed for wordpress, but as a user, automatic updates are a godsend! plugins and themes can be found and installed through an interface in wordpress itself, so as a developer you save a bit of time in trying to promote your plugin because it gets made available to everyone right away. Heavy modifications might break some of of this though, so I wouldn't recommend it if you want to modify it a lot.
Joomla!'s plugin community is heavily monotized, but there is a huge community of plugin developers. I don't know about Drupal, and most wordpress plugins are free. So that's something to consider as well if you plan on using third party plugins.
over the years, i began hating PHP, since i had to work a lot with it until i found good alternatives, so the first question i ask you is: does it have to be PHP?
but staying with PHP i'd add the following:
most people like Drupal a lot because of it's extensibility ... that's fine, but it still has some design problems ... it's is very potent and flexible and has a huge user base -> lot of plugins, big community to ask for advice etc.
when it comes to Joomla, one has to say, that in the past, this has been a really a complete mess ... but in version 1.5 the whole thing was redesigned and is now very clean ... i always laughed down at joomla, but recently i had a talk with some other developer i had worked with on several occasion, who quite conviced me, that it has become a developer friendly software ... plus, it is soooooooo damn easy to administrate ... i know no other CMS that is so easy to use (and is a "real" CMS, not a forum or blogging engine)
you might wanna have a look at Vanilla CMS ... very sexy, still slick and powerful ...
use a CMS based on a good PHP framework ... typo3 (Flow3 (IMHO really the most funky PHP framework)), something based on symfony (can't find anything, but this should be a good start), mambo (CakePHP) or maybe something based on code igniter ... you will always need to get familiar with the framework, but a) this is always good, b) if the framework is good, the app is likely to be good and extensible, c) you yourself will have a high productivity when building extensions since the framework will do a lot for you ...
finally, you might wanna have a look at opensourcecms ... always helpful ...
good luck with your choice then ... ;)
greetz
back2dos
We have been going back and forth a lot around our office lately about abandoning a proprietary framework that was developed here a couple of years ago and move to something that is larger and community supported.
Our current solution was built to include only the things we need and is very flexible, by flexible i mean that it is loose and the developers that have built sites with it over the years have take liberty in that, so a lot of sites we manage and have built and not to any standard at all. Here at the office I use the framework somewhat but prefer to use other tools. Over the years I have used a lot of PHP frameworks ranging from Code Igniter to CakePHP and have been a big fan of Zend Framework for all my personal projects so I am heavily biased and that is why i am asking here for advice from people who may be able to give me a more objective opinion. In the office a lot of work has been done on our framework so I can understand why some people might be hesitant to abandon it but the way i see it is this:
We don't currently spend a lot of time keeping our framework current and checking it over and over for bugs, we fix them as we find them. Which we should be doing
Any work done to improve our framework is directly put into our overhead column
We have a application built on top of our framework that is subscription based and closed source that we sell and I feel could be better if built to a better standard using a popular, community driven, framework that would require or encourage these things.
I searched and found this thread, Why do I need to use a popular framework?, that was similar to what I am asking but not quite. What i am asking for are opinions on as to why you would do one thing or the other, i don't really want to start a conversation about which framework is better, that will be the next step for us if we chose to switch.
Here are some of the reasons i see switching to a supported, open source framework as helping us in the long run:
As PHP puts out new versions the core of the framework will be updated to take advantage of those things without us having to do the work.
Security concerns with the libraries will be found by the community and patched without our involvement other than updating our code base with the current version.
Lots of information on the internet and exisitng code that can be used as reference
Ability to hire outside programmers that know the framework already, instead of hiring people and expecting them to have to learn how to use our proprietary one.
Ability to give back to the community through patches, plugins, helpers, and support.
Here are the negatives that I have come up with:
We will have to port all the existing code we have in our custom application to the new system
Our employees will have to be allowed a certain amount of time to learn a new framework and it's ins and outs
Our current framework is very flexible and loose which allows us to build things how ever we want and this keep our developers from having to follow and obey and conventions, which some developers seem to hate. I personally like conventions
Again it is probably obvious that I am biased and this is the reason I am asking here, I am open minded to what anyone might have to say.
Your question is really devilishly biased, because all pro's are long-term and all con's short-term development pains. :) But if the situation is even half as much as you describe, switching is the right thing and will save a lot of money in the long run.
My company is in the same sort of situation. We have a custom developed framework in Perl that never seems to get quite as much attention paid to developing new features and fixing bugs as the open source frameworks do. I and most other developers would love to switch to something open source for the benefits you mention, but nobody has the budget to spend the time porting code over. Our current plan is to use an open source framework if we have any small, new projects come up, and if that's successful consider moving older apps over.
I've mostly worked with Perl and Ruby, but a trend I'm seeing more of these days is frameworks allowing you to mix and match framework core components. For example, we're considering integrating parts of our custom framework into Catalyst. That way we can still use some of our custom developed code components (our own DBI class and some Mason templates) and porting our applications won't be as difficult. Ruby on Rails is also moving in the direction of being more modular.
Perhaps there's a PHP framework that might allow you to use some of your code, or at least make it easier to shoehorn some of your code into the framework instead of starting from scratch. Googling I see most of the PHP frameworks claim to be modular, but some appear to just allow you to develop add-ons, not swap out core components.
Sounds like you're doing some good analysis and I wish you luck in your search.
I think the most important points you highlighted here. The decision now, should be based, on numbers. Technically your analysis is perfect. What i would ask now is: How much it would cost for your company,to:
* keep your app to take advantage of new php improvements without break your old code (it means: architecture analysis, development and test, test, test).
* Do you have any developer/analyst focused in security development? (it means: security development life cycle, test, test, test).
* Do you have a development methodology? Normally those frameworks are kept under a good distributed development methodology.
I had the same question than you sometime ago, and my company decided to choose a framework, migrate our code, allocate 2 developers 1 day per week to work on the framework. To put our team to work with the framework development team was good, because we learned more about the framework, we helped the community (demagogy :-)) and we could add some business requirements in the framework features road map ;-)
I and my team are nearing completion of porting an existing application across to run on Zend Framework and it's gone quite well.
The old application had a lot of issues that were going to be big problems to fix and we decided to take the plunge and rebuilt it in ZF.
It has however taken a long time to port, I would estimate for our application it's taken us a good 4-5 months of dev to port everything across (we have taken the opportunity to rejigg the database and other areas of the system).
If you do go for it then be prepared to explain to your bosses why you need to spend a good chunk of time porting rather than working on income generating work. We were lucky to be able to use a new project as the impetus to carrying out all this work.
I see a couple of cons of switching over.
First, of course, there's:
We will have to port all the existing
code we have in our custom application
to the new system
Followed by:
We will have to port all the existing
code we have in our custom application
to the new system
and, last, but, not least:
We will have to port all the existing
code we have in our custom application
to the new system
You were talking about "money in the overhead column", and rewriting working tested code in to new working tested code doesn't add a whole lot of value.
If you're talking about introducing a new framework for a brand new, unrelated project, or one that uses little of the existing code base, then, sure, knock yourself out. That's a fine opportunity to switch frameworks, platforms, languages, etc.
But an existing, shipping, mature code base with existing knowledgeable folks working on it?
That's a hard pill to swallow, personally.
If you want folks to follow standards and conventions, then ... follow standards and conventions. Since you have a system that allows folks the "freedom to what they want", make "following standards and conventions" something they want to do.
It's always better to transition a system incrementally that throw the whole baby, bathwater, soap, basin and towels out the window just to go back and redo the exact same thing again.
Everyone wants to rewrite code, I want to do it. Our framework needs a "do over" here. But then we go "yea, but..." and what do we get in the end? N Months of effort to get back to where we are now. That doesn't do much in a world where time to market matters.