1. Our Questions
- What is the rate for 1h of development?
- How easy is it to find developers?
- What level of expertise does source customization require?
- Is there good and easy to find documentation about it?
- How does framework extension work?
2. What do developers cost?
Independent contractors can be found in the US for $50-$100/hr
Typical Plone consulting companies charge between $100-$185/hr
There is not as much distinction between freelancers and shops in the Drupal market.
Both can be found domestically for $50-$200/hr
The low end exists because the demand is high and some have really low budgets.
The high end exists because demand is high and some have bigger budgets.
The cost of doing Drupal is whatever the market will bare and consultants know this and take advantage of it.
3. Development Environment
Like with many things in life, there are always more than one way to do something. Plone and Drupal have different ways of organizing your code for local development and then deploying to various environments such as Testing or Production.
Plone deployments typically use Buildout to coordinate the bringing together the pieces needed to build a site. You will typically have a buildout that consists of target environment profiles so you can specify different settings and tools to be used in each environment. For example, you will typically want certain add-ons in your local plone buildout like PDBDebugMode or PrintingMailhost, but you would never want to deploy these in a production environment.
Buildout easily manages each of these parts and their dependencies to make sure you always have the right packages in the right environments. It also manages the specific versions of each package you have installed to make reproducing the environment consistent even if is on a fresh server years later.
Your source code repository will typically consist of just these buildout profiles and any custom code for this project.
This is one areas where Drupal has many different ways to do something. You are typically going to want to use tools that are not included OOTB for assisting with this process. Getting started on a project can take a few forms, but here are some common ones:
Download the Drupal source and check it into your own source control repository
Install Drush and the Drush make extension and use a YAML file to define what version of Drupal you would like. Then run drush make to pull down your code. The approach allows you to only check in the YAML make file and your customizations.
Utilize a service such as Pantheon to create your project structure and host your code repository. This is basically like option 1, but they do all the setting up of the initial structure and give you the dev, test and live environments out of the box.
See the Upgrade section for how this affects the overall upgrade process later on for each platform.
4. Custom Content Type Creation Process
Plone and Drupal both have ways to create content types TTW. Each of them includes a way to export these content types to the filesystem so you can check it into source control and do releases to other environments.
Plone uses includes the Dexterity content type framework for building your own custom content types. In Plone, this is the canonical way to create new content types. It has the benefit of being able to round trip changes from the TTW to the filesystem and back again. This method of exporting the type uses the XML model based schemas. If you require more flexibility in your content type, you may want to look into the other method of creating types on the filesystem via Python code and schemas.
Dexterity python file based schemas will feel very familiar with anyone that has done Django models.
Dexterity XML models can be exported and used in filesystem based add-on products via plone.supermodel. This allows you to then provide an implementation for the new Interface to customize things such as vocabulary and default values for fields. My only objection to this method is that it is XML.
Drupal developers typically start their content types TTW using core modules in the GUI. Then they can move them to another environment by exporting them via YAM.
The Drupal UI mechanism is very very capable. 99.9% of all IA can be accomplished here AND exported as YAML file for deployment.
Sophisticated IA can be accomplished through the GUI. E.g.: a profile for a user where favorite is collected
The Field_Collection module allows for Developers to add not a single field to a content type, but a collection of fields.
Install and enable the field_collection module
Add a new field to user and give it title “Favorite Book” and select field_collection
Then go to the abstracted section of the UI “Structure → field collection → find the field collection you just defined, and add the fields as you wish in the same UX as you used in adding fields to the content type, but this time we are abstracted.
Devs would create content types via TTW (album, song, band, concert, musician, etc) config is stored in database and written to the file structure as YAML
Finally, the Drupal Console https://drupalconsole.com/ allows for the creation of many Drupal configs via CLI. Developers can create content types, add fields, and perform a growing number of other IA config via the CLI.