Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
We're making a lot of websites for multiple clients and we always had some problems figuring out what to do with "Updates". We're starting building Wordpress sites and there's almost a plugin update every week. Since our sites use WPML and Woocommerce, there's a lot of conflicts happening with unreliable WPML updates and other plugin with security flaws (revolution slider in my case).
I've just received an email from my client's hosting and he wants us to make updates from WP 3.8.1 to 4.0 but I know there's an intensive conflict job coming up. I usually use the 'Disable all wordpress updates' plugin to hide 'em all from the wp-admin.
I wish my project had enough budget to build custom sites, but that's not the case here.
I just want to know how Wordpress agency are with that. It doesn't look that professional to tell a client that updates aren't necessary.
First of all, you of course bill them for the time you spend on your clients websites. Better yet, sign some kind of support support agreement where they pay you a monthly fee for having their websites kept up to date and maybe uptime monitoring. You can also include a few hours per customer for support and small development tasks per every month(it's usually nice for the clients to have even if they don't use it every month). This is a nice way to get some steady income and fill the time gaps when you have less to do.
You should also state in the agreement when you build the website that future updates and fixes is NOT included in price. You can give the clients a short period the report errors and bugs in the website and after that you will bill them for any extra time.
Secondly, get the right tools to optimize your time. I recommend ManageWP or InfiniteWP. ManageWP is slight better in my opinion and it is a hosted solution, but has a higher price if you have many clients(per client pricing model). InfiniteWP is a free self hosted solution(you set it up on your own server), where you only have to pay for the modules you use. You will need a few modules to get the functionality you need, but it's still much cheaper than ManageWP if you have many clients.
For uptime monitoring I recommend Uptime robot(simple and free for up to 30 websites) or Pingdom a better service with a lot of nice tools, for example performance monitoring, but also a much steeper price.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Today I have been given the requirement for new site to be developed in Drupal.
I have to learn from scratch within a week. I need any good links other than drupal.org to start with. I already have hands on experience in Wordpress and PHP.
Do you have any good links or tutorials for that?
Similar to the question "How do you eat an elephant" (answer: 1 byte at a time ...), I think you should try to have some plan (roadmap), which basically consists of 4 major phases:
What are the prereqs to start?
How could a training program look like?
How to gain more experience?
How to target the golden cradle?
(Many) More details on each of these phases are below ...
Part 1 - What are the prereqs to start?
0. HTML, PHP, JS, CSS knowledge
If you already know HTML, PHP, JS, CSS, etc it will for sure help to get you going with Drupal.
But in my experience those skills are not the most important ones to get up to speed with Drupal. You can learn about them "on the fly (on the job?)". Specific to PHP, in the context of Drupal, you only need to know a subset of all the things you can do with PHP.
1. Required Infrastructure
Obviously you need a computer, and (at least occasionally) a working internet connection and an eMail ID. At least to download Drupal, contributed modules, etc to your own computer.
Later on, when you have a website that is ready to be shown to the world, you'll also need:
some hosting provider to host that Drupal site.
a domain name (DNS registration).
To actually be able to use a Drupal website on your own computer, you'll need the typical softwares that are like pre-requisites for Drupal. Here is a list of those so called 'stacks' (often referred to as WAMP, MAMP or LAMP also):
an operating system for your computer (Windows, Mac or the free Linux).
a web server (like the free Apache, ...).
a DBMS (like the free MySQL).
PHP (no other languages here, but ... free).
Some typical utility programs, such as:
something to unpack files in an archive format such as a .tar or .zip, since Drupal and its contributed modules are downloaded in these formats.
an text editor (like notepad, notepad++, your favorite editor, etc).
an FTP client, such as FileZilla (to upload your site frm your local environment to a live server)
Setting up the required pre-requisites (as in the previous bullet) can be a bit of work (and/or a challenge). However there are some great packages available to reduce the required effort (and required skills) quite a lot, such as (pick whatever option you prefer and/or fits for you, incomplete list!):
VirtualBox combined with QuickStart (bonus: comes with GIT, Drush, etc pre-installed).
XAMPP.
Part 2 - How could a training program look like?
2. Climb the Drupal ladder
When I'm asked the question about how to get started with Drupal, I always point to Climbing the Drupal ladder (from famous Dries ...). It's only 1 diagram, but there is so much information and value in it (a picture is worth more then 1000 words ...).
It's a great outline to be used during a "Getting started with Drupal" session. Anybody who's a bit familiar with Drupal should be able to explain most of the items mentioned on it also.
There are also these variations of it:
The DrupalLadder.org website, which contains (or links to) lessons and materials to help people learn about Drupal and contribute to Drupal. The site helps Drupal user groups develop and share and develop materials for learn sprints and issue sprints.
Drupal Ladder installation profile (alfa version only, and missing some security updates ...).
3. Get familiar with contributed modules and themes
These days, there are around 17K contributed modules and/or themes. There are tons (thousands ...) of great modules/themes, and a lot of hidden gems. So think twice (or 3 times?) before diving into writing custom modules/themes. Ask yourself the question "Who will maintain them in say a few years from now?".
However, quite often you'll run into more then just 1 contributed module or theme. Here is a sample: Which contributed module should you use to create a chart in Drupal? ... Make your choice, e.g via the Comparison of charting modules. But which module would you go for if you are looking for:
an image gallery, as in this question: Advise a Drupal Image gallery module with an option to put text nearby the image (for medical atlas)
a slideshow, as in this question: Slide through nodes from the same content-type?
a responsive theme?
That's when you'll need to have some criteria in place for selecting the most appropriate one, as illustrated in the "Maintenance scorecards" also (you can use them for many other Drupal topics, so not only just for charts).
4. Views / Flag / Rules / Message
It's rare to find sites that don't use the (amazing) Views module, which however isn't obvious to get started with (there is so much to learn about it). I learned a lot about this module via the great, and free, set of 30 video tutorials about the Views module.
Combined with the Flag, Rules and Message modules, a lot of site functionality can be delivered already. To get started with Rules, checkout the 32 (!!!) great, and free, video tutorials Learn the Rules framework, organized in 7 chapters. There is a similar set of 8 video tutorials about the Flag module.
So make sure to have a good knowledge/understanding of all the amazing things you can do with only those "magic 4", in virtually any site. A few samples:
How can I allow anonymous visitors to submit content?
How to implement a nomination process for nodes?
How to change fields permission using some action in the Rules module?
Redirect after login for specific role on specific day using Rule.
How to publish nodes 3 times a day?
Content access based on the content author's role.
How to change my homepage based on the time of day?
5. Study available documentation
Documentation about Drupal and many of the contributed modules is available in various formats, such as:
The Readme.txt file that comes with contributed modules.
The Community documentation available for many modules, which can typically be found via the "Read documentation" link on a module's project page (not all modules have one however, though they should).
The Advanced Help documentation that comes with selected modules, and which you can access from within your site if you have the Advanced Help module installed.
The impressive set of (great) questions and (great) answers at Drupal Answers.
6. Learn to use the issue queue(s) on Drupal.org.
Each contributed module on Drupal.org has a "project page" located at something like https://www.drupal.org/project/issues/abc, whereas abc is the "namespace" of the module (not always exactly the same as the title of the project page). Multiple links to its corresponding "Issue queue" can be found on the project page, or just use an URL like https://www.drupal.org/project/issues/abc.
The issue queue (search results of issues) offers various search features and/or filters. Even if you're not "searching" for a specific issue, but just browsing around in these issues, you can learn a lot by reviewing these issues. Often times there is important (crucial) information contained in "some" issue that didn't make it (yet) to the documentation related to the module.
In my case, when I first started using Forena, I kept iterating over its issue queue, and occasionally posted new issues.
As a module (co-)maintainer, I try to point module users to such interesting issues, via a list of 'issues' mentioned (hyperlinked) in these Community documentation pages: Charts HowTos, Forena HowTos, Chart HowTos. Note: later on I started adding similar links to interesting question on Drupal.SE also ...
7. Learn from podcasts about Drupal
There are some interesting podcasts dedicated to Drupal, which also have a great website with all sorts of hyperlinks to topics covered in each of them. Though there are quite a few, here are my favorite ones (+ links to answers about topics I learned about via them):
Talking Drupal
Example: How can I make a gallery of “boxes” of content consisting of an image and some text?
Drupal Easy
Example: Can I move distribution profile modules from profile folder to sites/all/modules?
FYI: I "learn from these podcasts" (+ get ideas) while ... walking my dog. You could do so too while commuting, exercising, cutting the grass, preparing a meal, etc.
8. Learn about Drush
Learn to walk before you want to try to fly ... So start building / maintaining Drupal sites using the typical Admin interface (UI). Such as:
install/enable modules.
clearing the cache(s).
updating site information.
typical modules you keep using in most of the sites you build.
etc.
However, when you feel you have enough experience, and start to know and understand Drupal well enough, you should invest in learning about Drush. After you do, you'll wonder "How could I do work in Drupal without Drush?". For each of the bullets above (and many more bullets), there is a way to do it with Drush.
9. Learn about GIT
A Drupal site mostly consist of 2 major parts: a database (typically in MySQL), and code (mostly PHP, also JavaScript, CSS, etc). Drupal core, it's contributed modules, and also custom modules are all in "code". Git is used for the "Software Change Management" (SCM) part of that code.
It is highly recommended to start using GIT "as soon as you can" (after you do, you'll wonder "how would I do work in Drupal without it?"). Git is typically used for topics/tasks such as:
Building a Drupal site with Git.
Sharing code between developers, and for maintaining modules on Drupal.org.
Part 3 - How to gain more experience?
10. Pick an area to grow
Drupal is big, actually huge. Nobody (even not Dries) can do/know everything in Drupal. So try to find an area (or a few areas) you're interested in. If you can, look for something you also have experience with already in other (none-Drupal) domains already.
In my case it was (is) Software Change Management and also Business Intelligence (reporting). That's what explains the contributed modules I'm now 'involved' in (Charting, Reporting, etc) ... and my interest in the upcoming "Configuration Management Initiative".
11. Learn from experience ... and mistakes
Another important aspect to come up to speed with Drupal, is that you have time to learn "from experience", and "from making mistakes". Starting as a site builder seems the most obvious starting point.
From there you can move / evolve into roles like a Drupal Developer (back-end), Drupal Themer (front-end) or Drupal all rounder. That's also what seems to be compliant with recent Drupal certification programs.
Remark: how to get started in any of these roles, seems to be out-of-scope for this question.
12. Get in touch with other Drupal-fans
You must have seen this before: "Come for the software, stay for the community". If not, have you ever visited www.drupal.org? See it in the upper left of the homepage? If you're new to Drupal you probably wonder what that really means. Here are some suggestions to experience it:
Participate in Drupal Groups.
Join the Drupal community on IRC.
13. ...
This bullet is intentionally left blank ... because of its "number" ... Did you notice the numbering started at 0? ... to compensate for this missing number ...
14. Attend Drupal conferences and meetings
Meeting in person with other Drupal peers takes more effort (and is more expensive), but you will get a lot in return. Here are some options to pick from:
Attend Drupal Cons, these are big conferences, about 1 in every continent every year, relatively expensive (travel, hotel, registration). Common language is English (though there are exceptions like in Latin America I believe it's in Spanish). Next one coming up is in Barcelona, sept 21-25, 2015 (I'm registered ...). If you can't make it (or missed some of the sessions while there and busy doing networking, etc.), go find the videos about dozens of sessions.
Attend Drupal Camps, which are more local and (way) smaller. They are typically by country and/or state, in your own language.
Attend Drupal Sprints, where you wil not only be contributing (= giving back to the community), but where you will find others willing to help, guide and mentor you where needed.
Part 4 - How to target the golden cradle?
15. Don't wait for George, just be like George
George#Drupal.org was (at least to me) first introduced at DrupalCon 2014 in Amsterdam during the Keynote (from Dries) (on slide 76/198). Review those slides, and watch the movie to understand what that George is all about.
Then stop "waiting for George", and instead start acting like George. Even if it's something challenging (difficult, major effort, etc). When you're done, you'll for sure have learned something, and probably AlotMORE ...
If you're looking for inspiration about what could be good examples of this, then stop wondering "When will D8 be released?". And instead, "Get involved in contributing to the release of D8" .... And continu using D7 for building websites until D8 is ready (and mature enough).
16. Start contributing as a novice
Apart from what's detailed in the Novice code contribution guide (which is about creating patches to contribute "code" to Drupal), there is also a lot of community documentation that needs work, and can be done by novice users (typically tagged with "novice").
Same for modules that need better/more documentation. That's actually how I got 'promoted' from being a Drupal user/admin to becoming a module co-maintainer and module owner. Refer to HELP Reports reorganization (which is 'just' 1 issue ...) for an illustration of how I got started in doing so.
Such contributions will help to "Build your reputation", and might resolve the chicken/egg issue to get started with Drupal (most jobs in Drupal require knowledge / experience in specific Drupal areas).
17. Learn to manage Drupal configuration
Any Drupal site consist of 2 major parts:
Code downloaded from Drupal.org, such as Drupal core and contributed modules or custom modules.
Configuration which is stored in the Drupal database (typically anything you do using the Drupal administration screens).
Managing code (such as migrating or synching between 2 or more environments) is relatively easy. All sorts of tools (such as GIT, etc) are available to actually do so.
However you also need to manage the configuration of a Drupal site. A site without any configuration is like a site for which you have not even ran the install.php script. Here are some examples of what configuration is about:
As soon as you start running the install.php script, you start entering configuration data about your Drupal site (Site name, site slogan, etc.).
Anything to content types, permissions, roles, rules, users, taxonomies, filters, custom views, etc. (none of this is stored in "code", and you can't just download it from somewhere).
Modules and/or themes that are enabled (just unpacking a contributed module that you download from Drupal.org will not enable it).
Options to configure specific modules and/or themes.
So whenever something about such configuration items changes, or needs to be migrated to another site, you need to correctly manage (and secure?) all this. Otherwise there is a chance that (parts of) your site breaks.
That's why at first these kinds of contributed modules were introduced:
The Features module.
The Configuration management module.
Even though those modules add a lot of value in the area of managing configuration, they also have weaknesses. That's why the Configuration Management Initiative (=CMI) was introduced. CMI is planned to be released as part of Drupal 8.
Part 5 - Appendix
The above list is incomplete (still ...). Other topics that might be added here:
How could a training program look like?
Become familiar with other modules, at least with the ones with a
high ranking, but also search for hidden gems.
Learn about contributed modules to display content, such as Display Suite and/or Panels. Then check if you can answer questions such as "https://drupal.stackexchange.com/questions/22553/panels-mini-panels-vs-block-regions-vs-display-suite-vs-stylizer-vs-page-manager". A great resource for learning about Panels is the (free) video training about Learn Page manager. Panels uses 'Page manager', which is one of the sub-modules of Chaos tool suite (ctools).
Become familiar with building multilanguage sites (using i18n).
Learn about using "Base themes", such as Zen, Omega or Bootstrap (most of them support HTML5, are responsive, have a lot of configuration options, etc). And also explore the various "Sub-themes" related to them (also available for download from Drupal.org).
Increase some of your technical skills such as SQL and Regular Expressions.
Review and learn from dissecting Drupal distributions.
How to gain more experience?
Find a Drupal mentor (+ accept invites from others to become theirs ...).
Chat with the Drupal Community on IRC.
Participate in sprints.
Learn about Drupal deployments (dev, stage, QA, prod).
How to target the golden cradle?
Workflow automation.
Automated testing.
Apply software reuse (Features, drush make, installation profiles, etc).
Get ready for D8 (Symphony, Twig, OOP, CMI, server prereqs, ...).
Note: the above is what I posted before on https://drupal.stackexchange.com/questions/164463/how-to-answer-questions-about-getting-started-with-drupal/164475#164475. The actual question (https://drupal.stackexchange.com/questions/164463) is now marked as "hidden for anybody who has not at least 10K rep on drupal.SE" (aka deleted by moderators).
Try setting up a Drupal site first, then ask specific questions in http://drupal.stackexchange.com
Note: In my experience, Drupal has a steep learning curve compared to Wordpress.
Check out the following links:
http://training.acquia.com/hellodrupal
http://learnbythedrop.com/
http://drupalonlinetraining.com/
http://drupal.org/videocasts
http://drupal.org/handbooks (This one is probably the best place to say hi to Drupal!)
In addition to the great links fotuzlab has provided:
http://www.acquia.com/resources/recorded_webinars - recorded webinars from Acquia
http://drupal.org/project/examples - code examples for developers
http://api.drupal.org/api/drupal - API reference
also http://www.lullabot.com and http://www.lynda.com have great video courses, but they are not free.
But in general drupal.org is pretty enough to go with.
In addition to all other answers, consider to pick up a book (or a couple of them). See http://drupal.org/books/ for a list.
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.
One of my friend who is RIA developer and do action scripting. He started a blog and worked on it, after some time he saw that his blog is hacked that was developed in WP and some text was written in it so he just went to FTP and deleted all files.
So all this seems that a WP sites probability for being hacked is more than site built in RoR or Django or CakePHP or kohana e.tc. Is it true? What was actually the reason of hacking? Is there really some security vulnerabilities in WP?
I am a PHP developer and also have developed many custom sites, and also have worked in WP and joomla e.t.c. but never heard any thing like that. If it is problem there then can SSL solve this problem? Confused that how that happened...
Please tell me if you have any idea so that I can understand it and get out of curiosity.
Wordpress is moderately secure, but I just had two of my WP blogs hacked last week and had to rebuild. In the process I learned some helpful hints. Some of these hints are general for all sites, some specific to WP.
Always upgrade to the most current stable version of WP. Older versions may have known exploits.
There are several things you can do manually to secure your WP site, but instead use one or more of the established security plugins. Right now I am using both PBS (Bullet Proof Security) and WPD (Website Defender). Follow the guidance from these plugins; take some time to learn them well.
Run Akismet (or similar) to minimize rogue spam posts.
Turn off remote posting (ATOM and XML-RPC) unless you require it for your business model.
Harden your admin PW (and don't call your admin account ADMIN).
Don't install lots of experimental plugins onto your site to try them out. Create a sandbox site for this. Keep the installed plugins on your live site to a minimum.
Hope this helps.
Wordpress is a relatively secure product. However as with anything nothing is 100% fool-proof. Unfortunately with widely-used products such as Wordpress once an exploit is found it is widely available on 0-day exploit sites and a lot of hackers will trawl the web to take advantage of this exploit.
However staff at Wordpress are very quick to patch these errors which is a plus. Also the installation of plugins coded by the non Wordpress team can be open to exploits and is the most common way a hacker finds his way in. If there is an issue an SSL certificate will not stop the site being hacked. Will just mean that an form data will be passed between locations with better encryption. I hope this helps.
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.
Basically I need to choose one so that, I can get familiar with it quickly and then customize it to my needs.
I'm a .NET developer and know classic ASP too. But I think understanding PHP will not be a problem for me and also think that it won't be that difficult.
What will you like to recommend me?
UPDATE:-
Sorry that I'm adding this info late.
Right now I don't know what customization I will be doing. But I'm sure going forward I will have my own requirement and will need to customize. So I don't want to be in situation where I will have to say "This engine which I'm using will not allow me XYZ change or it will be too difficult for me to make XYZ change in this blogging software, so lets migrate to something else."
I will prefer a short learning curve.
Wordpress is nice, but if you're a .NET developer BlogEngine.NET is extremely easy to extend. The drawback is the much smaller community and resources, but if you're wanting to do some real customization and tweaking, BlogEngine will probably fit your tastes much better. There is a decent development community backing and supporting customization and plugins for BlogEngine, but you'll find that a lot of the information is outdated or maintenance has been forgotten.
If you're wanting something with tons of community widgets, plug-ins and tons of themes, Wordpress is your prime choice without a question. But that's if you're going with the canned solutions. There are a lot of them, and you can still customize them and tweak things, but that's dependent on how comfortable you feel about picking up a new paradigm. Wordpress customization isn't so much PHP development, as it is Wordpress development, since you'll be so deep in Wordpress' own world and API.
Both are available in MS's Web Platform Installer, check them out of your box and play around with them some. It's really going to come down to which one you feel just fits. I've used both for different projects, but I've fallen back on doing my own thing with BlogEngine more than Wordpress. But that's for my own personal stuff.
If you know .NET and C#, facing PHP and mySql is going to feel like you went back to 19th century and have to burn coal in your "car" instead of tanking your beamer at a local gas station :-)
One particularly interesting thing about BlogEngine.NET is that out of the box it will run without SQL Server - just with XML files as a storage. If you know your programming I don't have to tell you what kind of flexibility that provides. Not that I'd recommend actually running a web site for a long time without SQL Server but such dual backing opens some very interesting options.
Should I mention that it comes with Visual Studio sln and proj files? :-) That pretty much means zero learning curve.
Go with Wordpress. It's easily customisable, and there's masses and masses of information on customising it.
Digging into Wordpress
Wordpress docs
Thematic - a Wordpress theme designed to be easily customisable/extensible.
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.
What are the advantages and disadvantages of coding your own blogging engine from scratch, versus using an already existing engine (for example, but not necessarily, wordpress)?
The biggest reason for going with developed blogging applications today is
probably interoperability. Seasoned blogging applications of today include
plug-ins and fundamental development inertia that ensures that you will interface well
with things like Twitter, Flickr, and social networking sites. Only a
spectacular developer (with a lot of time) would be able to custom code a
solution for all the APIs and other bells and whistles that, in the course of a blog's lifetime, they will want to use or at least experiment with. To build a custom blogging application is to make its default state a basically isolated one. And isolation for many blogs doesn't work.
The biggest plus for using a custom blogging application anyway is that you retain a high degree of control over the application's core behavior, and, since you will likely host it on your own server, direct access to its statistical metrics. If you know well ahead of time that you will not care about interoperability beyond, say RSS, or one or 2 other channels, and have the time to invest in core development, a custom blog is a great way to maintain a look and feel that will positively startle visitors who are used to a constant WordPress or Blogspot layout. One major pitfall, it seems, is that off the shelf blogging applications require you to learn how to manipulate each of their various presentations. It's not hard if you want to simply adopt any thousands of "themes" that typically exist for them, but then, your presentation will not be unique. Sooner or later a visitor to your blog will encounter the same look and feel elsewhere, exactly. The solution there is to hire a custom developer but that of course costs $$$. Even if YOU are that developer who will wind up trading coding-for-core-functionality time, for learning and coding for presentational individuality. Expensive either way.
I am struggling with this question myself. As a proponent of "everything independent" on the web I hate the idea of giving up low level control of my blog. I've been online since the consumer web first took off and understand the ease by which a website can be created using nothing but notepad and an FTP client. To me, anything beyond these basic tools is very "AOLish", and yet, many blogging applications have now evolved into full content management frameworks that would rival the complexity of mastering that which it once took just to figure out basic HTML. I've finally taken to in-depth experimentation with some of the more popular blogging solutions (WordPress, Blogger), and am shocked to find out that after spending so much time maintaining my own solutions, how quickly (and much better) it is to compose and manage entries with them. Since most of my blogs are not profit projects, time to compose has not been a factor for me. However, this may change. If it comes down to where I need to manage and concern myself more with content than mechanics to get my messages out, I will probably swing to seasoned blogging app mode and hope I learn enough about my platform to make it truly a unique experience anyway. That would probably be the best outcome for anyone like us debating this.
Dave
I just set up my own blog and I had to answer this same question myself. Here are the main reasons I went with BlogEngine.Net
Coding the entire thing myself would have taken a long time
I saw that there were a lot of themes available (and that making/modifying themes is easy)
Why reinvent the wheel? (would you write something that the public engines don't already do?)
Advantages of writing your own
It's fun
You might learn new programming tricks or techniques
Using a software you wrote is more satisfying than using someone else's
It will be exactly as you want it
Disadvantages
It takes time
Security risks. A high profile open source engine such as Wordpress is less likely to have security vulnerabilities than your own, especially if you don't have experience in web development. (However there are many high profile programs full of vulnerabilities, such as the widely used Internet Explorer), so take this with a grain of salt.
Features. Wordpress/others will probably have more features (even though some people don't like software with too many features)
You must keep improving your engine over time. If you stop but decide to keep blogging, you will probably want to move to Wordpress, especially if some features you really want aren't implemented yet in yours. This can be problematic, especially if you didn't plan export features.
Actually I went through this path.
For fun and learning reasons I coded my own little content-management system which I used for rudimentary blogging. It had quite static content (no comments were allowed) but it was enough for me. One year later I decided to switch to wordpress and am really happy with it.
Today I would change my approach and would go for wordpress instantly.
Reasons from product perspective:
You won't be able to feature-compete with wordpress (including plugins)
You won't be able to have such a stable and secure app as wordpress
Responsive community (both documentation and patches)
Continous releases
Reasons from learning perspective:
You learn a lot by understanding and reading other's source code.
You can make the product better instead of reinventing the wheel (by providing own plugins or bug-fixes).
It is a far more realistic job-setup: You hardly build apps from scratch but rather extend, integrate and maintain them. Also you work in a team.
Nowadays I would start to build 'from-scatch' software only if:
There is no software which can suit you or you can't extend to your needs.
You need a custom software for business reasons (e.g. you are a startup with fresh ideas)
Building a new software is cheaper as maintaining/extending existing one