Identifying module contribution oportunities for Drupal 8 while leveraging the PHP community with a practical example
Please give us a detailed overview of your session and why attendees will be excited to hear about it.
In this session, I will share my experience with attendees about a very common situation most of us encounter while performing our daily tasks on our jobs: Adding custom functionality for a Drupal 8 project.
I was recently in this predicament, where you can just add the specific functionality for your client, or go the contribution path: Making the use case more universal, so other people can benefit from the code that you are about to write.
The requirement was the following: One of our clients wanted to allow his users to create support tickets using the JIRA platform using a form seamlessly integrated within the website.
Expectation: Go to D.O. and search for a module that already does exactly that, install it, and voilá!
Reality: There is currently no solution that provides this functionality...
Next steps:
- Take a look at the Atlassian API to understand what can I get and put from/into a JIRA project or a JIRA HelpDesk project.
- Search the PHP community for a base library to handle the API requests, so I don't need to write this from scratch.
- Found a library but also found a couple of bugs, send Pull Requests, but the maintainer says he is too busy and can't merge/review them in the near future:(
- Fork that library so you can modify and maintain it yourself and also upload your work to packagist so you can integrate it well with your custom module. (You could also just download the library and modify/integrate it without forking and maintaing it, but, really?)
This next step is the real crossroad:
5a. Code your module to specifically address the feature request, meaning: Create just a form with only the fields that your client is requesting, and send the values of that form to the API on the submit function, and you are pretty much done.
OR
5b. Architect your module in such a way that you provide more options for a wider audience of potential users, this requires a little bit more of work so start thingking about:
- What other feautures might be needed (For this case I thought options to select project/issues and even fields from JIRA)
- Create an admin page/form
- Think of basic UX for your config form since this form will have several dynamically generated options
- Allow site builders to configure their credentials for JIRA (and try to manage this as securely as you can)
- Allow site builders to customize the fields for the form depending on what is available for that project issue type combination
- Aditional features: custom url to access the form page itself and maybe display the form in a block
- Use code sniffers to comply with PSR Drupal Standards
- Refactor your code to make it as DRY as possible and as legible as possible
- Write tests for it
- Ask co-workers or fellow Drupalers to take a look
- Send it
- Wait for community reviews and comments, and adapt your code accordingly
- Release it!
What level of knowledge should attendees have before walking into your session
I would say basic understanding about how Drupal and custom module development work
What will your session accomplish and what will attendees walk away having learned
I believe the main thing would be ignigting the sharing light bulb that we all as Drupal developers have, and providing tools and approaches that can be used in most situations when we are developing custom code, this greatly helps the Drupal community by having more contributed modules, and also helps enormously professionally with all the learning and best practices involved when we contribute back to the Drupal project.
This is a very long title. Are you sure there isn't a character-length limit? Could do with a comma at least.
The 'expectation', 'reality', 'steps' structure you've used works well, but this is very long and detailed isn't it? Is that what they wanted? It's not an abstract so much as as notes for the full talk.