The deeper I get with Drupal the more I have to make changes to code within other people's modules. These are usually small changes, and so far it doesn't make sense to rewrite the module's functionality for my own needs.
I'm trying not to make any modifications to Drupal core since that just seems like asking for trouble.
But sooner than later, I'm going to need to update these modules with new releases and then repatch my changes back in. How do you stay organized when making these changes, upgrading modules, and re-applying your changes back?
I'm taking as many notes as I can but the spiderweb is growing around me!
Another key is to maintain explicit .patch files for any changes you make, and include documentation with them. If you have to upgrade to a new version of a module, install the clean copy and re-apply the patch. If it doesn't re-apply cleanly, you know you've got a problem.
That's where maintianing your own source tree in SVN/git/etc can be handy.
Do you change the module in a way other people may benefit?
Then send the patch to the module maintainer, so everybody benefits and you don't have the trouble to stay organised.
There is a good discussion in this question.
I particularly like Nick Sergeants article describing a method where you checkout the Drupal sources via CVS and then control your changes and the CVS records using SVN.
You only have the two already mentioned Options.
1.) If your changes can benefit the community then give back and hopefully it will become Part of the next release.
2.) If your changes are to specific and fit only your needs than your only chance to stay organized is setting up your own VCS (e.g. Subversion) and learn to use it properly.. ;)
There are some good infos on using Subversion with drupal on the Drupal.org site.
There is also a new Module available that allow you to capture some features into your own modules (e.g. features (http://drupal.org/project/features)). I have not much experience with it but maybe this is also a solution for you.
The way that Eaton describes above tends to be how we handle the situation for relatively large sites. If you keep a running log of patches, you can always re-create changes.
One of the aspects that seems to be missed in a lot of the "submit back to the community" posts is that just because you submit it back to the community doesn't mean it'll ever get applied. The way we handle this scenario is by keeping an explicit patch file with an indication of what D.O. issue it's related to. In the case where the patch is eventually integrated, you can remove your patch and pat yourself on the back. In the scenario where your patch is never accepted, at least you still have your log.
The book Leveraging Drupal: Getting Your Site Done Right (Wrox Programmer to Programmer) describes workflow and developing sites with cvs/svn from the beginning.
It's only $32 free shipping at amazon right now (as low as $24 used but remember $4 shipping you might as well get it new. I recommend checking your library for it, if they don't have it try inter-library loan. But this book describes exactly what you are seeking, step by step.
Related
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.
This is more or less related to project management and also with every developer. How you guys handle this situation when you have developed many features on development site and all are tested by client and ready to go live.
These features have some code in common files ie. One PHP file have the code for one feature as well as one other feature.
But client will ask you to upload only 2 feature out of 10 or 15. Files are common if you upload that file directly will leads to error problems because they have code for other features. If you upload all updated files then all feature will be live.
A possible way is go back and comment out that feature which is not needed live for now from common files. But there is possiblities to forgot to comment anywhere else.
This is also not a good way and at last client will say what happen everything was tested on development server and why these bugs and errors are introduced on live server.
This will reduce the faith on developers.
I faced this problem many times and could not found any good way to avoid these issues. So I am thinking that you guys also facing or faced this problem.
I am thinking versioning system can help here.
How you guys are handling this?
Could you share ideas?
The situation you are describing is impossible to manage sanely. I don't believe it would be possible to make this situation work, but the real question is why would you want to?
There are a number of issues with the scenario you describe, but the core issue is really this. You are testing one thing, and deploying another. You acknowledge in your question the interconnected nature of changes. In reality it is even more difficult than you describe. You simply cannot know how a system will behave when you try and deploy parts of a tested solution. Why test it at all?
The only sensible solution I can see is to have a sandbox environment where new features are demonstrated. However keep your test enviornment only for testing stuff that will go live. So in your example the one or two features are in test, ready to be signed off for prod, and the other featues are locked in the sandbox.
This leads to the next problem, which is managing your source code. I don't see any sane strategy for managing the arbirtrary inclusion of features from a code base. Even under the mostflexible system I know, Perforce, any branching straegy would require awful resolves on merges as you try to move stuff in and out.
I have seen this happen, and believe me it gets very ugly.
I suggest you come up with a better solution. Talk to your client and change the way things are done. It will be better for you, and in the long run better for them.
A solution could be to use cheap version branching as provided by VCS such as Git or Mercurial. The project would consist in many feature branches used to develop said features and build branches where feature branches would be merged and adhoc fixing would take place. When a build branch is ready for test, it is tested, fixed if needed and then the build branch is shipped to production platform.
When features have been validated, the build branch can be merged into remaining feature branches so the branches under development can integrate the "official" changes.
To sum up, the application is custom built from existing feature branches as needed.
One reasonably sane way to manage this on the code level is to isolate each feature into a plugin. Then you can add/remove features on-demand by simply enabling or disabling corresponding plugins.
But this solution has certain costs:
Time to develop and test plugin engine for your app
You need to test every plugin configuration (set of enabled plugins and their versions) that is going to be deployed. Otherwise there's a risk that this specific set is not compatible and end users would be first to see resulting crash, or data loss, or some other horror
Additional time to wirte plugins the way that they're minimally dependent on each other.
It's usually worth it only if you have many clients with different needs. In your case, I'd recommend explaining cost of separately enabling features to your client to see if they really need it this hard. Most likely, they don't
Thanks for your time.
I am new to Drupal. I am working on a website and lets assume I am testing 10 modules and select that "X" module suits me well. Now I configure this module to my requirements and then see that this suits the project really well. As you know some modules like profile module may have 10's of form fields which can be time taking to do.
So, is there any way that we transfer some file/s from developer machine to Production machine that will set these configuration settings and configured form fields which avoids re-doing the whole thing over again? Why I need this is, I am in East coast and there are couple of developers on west coast with whom I might have to collaborate. So, I am in desperate need of this kinda system.
Take a look at the Strongarm module. Lullabot recently had a blog post on a development workflow that included Strongarm, "Site Development Workflow: Keep it in Code."
The Drupal way is to keep installing modules on top of more modules until your application does what you want.
Strongarm might be the best solution. But you can also write an update hook that sets the values in your variables table. So this way your changes are captured in code.
You'll need to take a look at your variables tables and possibly the admin form in your module to see what values it stores. It kinda sucks that you have to do that.
Writing update hooks is good practice when you're collaborating. It's akin to Ruby on Rails migration technique. I can't remember using the word "akin" before!
See:
http://api.drupal.org/api/function/hook_update_N
http://api.drupal.org/api/function/variable_set
You should also encourage your team to regularly grab a copy of the database from one definitive location so, if you make changes to the schema, it's likely that your team will pick up those changes soon enough (after you've applied them). But that's not really a guarantee. Just a half decent form of risk management.
I've used Wordpress and Joomla to build a couple of small websites, and done some hacking about to get them running exactly as I want. But both of these, and probably many other PHP CMSs, are subject to a constant barrage of security fixes. I don't have to time to test the fixes, make sure my customizations are still working, and roll them out before anyone attacks the site, then do the same thing again a month later - I'll never get anything else done with that kind of overhead.
So my question is: Is there a (preferably PHP) content management system that somehow successfully avoids the constant barrage of security updates and resulting testing/sysadmin work? So I can just work on it when I have time, not keep racing to patch the latest attacks?
Bonus points for having a sane plugin model to make it easier to code against. More bonus points if it provides an easy method to import data from Joomla and/or wordpress.
Thanks
EDIT: As rightly pointed out, avoiding updates entirely is not a sensible goal. Rather, I want to minimize the pain of updates. So what I'm really looking for is:
Easy to adapt and theme in a way that is guaranteed not break during updates
Simple update process
there is no cms (no software, for that matter) so secure you never have to update. developers make mistakes, and new exploits appear. so every cms should be "subject to a constant barrage of security fixes". if it is not, you should ask yourself about the security policy of the project and the security of your site. see The Open Security Model, Drupal and ExpressionEngine on Security for a related read.
so unless you don't care about the security of your site, you are asking the wrong question. i think it should actually be: is there a cms that is customizable without modifying core files so that security updates don't break my customizations? or: how can i customize a cms so that security updates don't break my customizations? security updates usually don't break a (even customized) site - unless the customizations are done the wrong way.
my answer to that new question would be Drupal (including bonus points).
The last versions of WordPress (2.7 branch) have auto update for core and plugins making it really easy to upgrade when a fix is available. The api is also awesome - I've done quite a few WordPress based sites and rarely (if at all) needed to hack the core.
As long as you customize through plugins or themes, and use auto update when a new version is available, you shouldn't have any problem at all.
I like CMS Made Simple, which is written in PHP.
In term of security, stability & flexible maintenance I suggest Symfony framework
(see:http://www.symfony-project.org/). It has a lot of plugins, support towards wordpress, joomla and whatever you need.
See also PHPcake at http://cakephp.org
I really like ExpressionEngine, made by EllisLab, its based on their open source framework CodeIgniter, (which I think is one of the best PHP MVC frameworks).
There is a free version of ExpressionEngine for non-commercial use, which is all I've used, but the paid addons + modules look pretty slick.
As for actually really free, ModX is alright, but has a frankly wierd plugin system, that said, Ive built a couple of sites on it, and been happy with the results.
I am deciding on a framework to try out for PHP. I have narrowed it down to CakePHP and CodeIgniter. I have a couple of questions for any of you who have used or are familiar with both:
I like the fact that CakePHP keeps most of the code outside of the webroot by default. Especially since I may end up using a single framework install for multiple apps. I see CodeIgniter will do that too, but you have to configure it and move some stuff around. Is that workaround secure and reliable, or is it an afterthought hack?
Which (if not both) is easier to upgrade, and maintain over the long term? As new versions of the framework (and PHP itself) come out. I don't want to find my stuff either breaking, or becoming outdated.
Edit:
This is a very old post, but I thought I would update it with what I finally ended up doing, which was to use Kohana.
You should try both frameworks for a week or so, building something trivial (like a blog or wiki) in both, and see which you prefer using. Whatever makes the most sense to you will probably sustain you the longest through upgrades an deprecations.
CakePHP is in a bit of a volatile state right now, still unearthing bugs while pushing to release version 1.2 (which is not backward compatible). I wouldn't suggest building a critical application with it if you need something rock solid right now. If you can wait a month or two for things to settle, then it's probably a moot point.
To address your concerns:
1) Cake and CI do it the same way (iirc). They are equally secure, reliable, and hackish on this front.
2) Everything changes. If you need concrete, perpetual assurance of stability and backward compatibility, roll your own framework. There's not that much to it, and you're guaranteed that nothing changes unless you want it to.
I have deployed multiple applications on CakePHP and it's been a very, very, nice experience. You can't go wrong either way, as both are solid.
is a non-issue.
CodeIgniter has a sponsor behind it, so it's definately the one to choose for the long term. Also, it's faster.
This is a non issue. The app has a couple of lines which says where the core and your application code lies. You just need to change those lines.
You can never anticipate this one.
The state of PHP is a wildcard here. One app (CI) is built to be compatible with PHP4 the other requires PHP5. If you need to deal with the possibilty of a web host only supporting older versions of PHP then you need to go with CO.
Another issue is unit testing. If you require your framework to ship with tests, then CI is not the way to go.
Personally, I feel comfortable with CI because of the corporate backing. The company behind CI is making real profit from their efforts. Though CI is free, their paid product (ExpressionEngine) will eventually live on CI. The same could be said of the Zend Framework and even the birth of Rails (originally built for Basecamp.)
A minor correction to an above comment: both are compatible with PHP4, not just CI. Also, I don't think that having a sponsor makes CI and more or less upgradable or maintainable. Money doesn't solve those problems in the least.
I use CakePHP for a variety of applications and I've been happy with it thus far. 1.2 is a huge improvement over 1.1, and while the library source may change from RC3 to Final, I don't think any code you write will become obsolete. My only niggle is that the Manual isn't as comprehensive as it should be (in my opinion), and I end up in the API quite a bit. The trade-off there is that I now understand the code behind the scenes very well. In any case, I highly recommend it.
On the other hand, I've never played around with CI, so I can't recommend CakePHP over CI. I would take each for a spin and see which one grabs you. Whichever one you choose, study the hell out of its conventions and capabilities. When I started with Cake, I unwittingly wrote a bunch of code to do something Cake did "automagically" by having me set one variable in the controller.
CodeIgniter is very flexible as you would see once you try it. So how your application would be maintainable would fall you your hands.
I have also deployed multiple applications using the same installation. I usually create 2 applications for CMS projects (one for admin, one for the front-end).
To address both of your questions from a CodeIgniter perspective (I don't use Cake):
1) CodeIgniter doesn't keep itself outside the webroot by default, but it can do so with some very simple changes. The first part of my CI tutorial series explains how to do so, along with a walk through of the setup of a new CI instance. Once finished the only part of CI that needs to be in the webroot is a small index.php bootstrap file.
2) I've got an application which I originally developed in CI 1.4.x and I've sucessfully migrated to 1.5.x then 1.6.x. With each new release the CI dev's make available detailed upgrade instructions laying out what needs to be replaced so upgrades are fairly easy.
Jim.