Seeking Guidance on Extending Functionality in Concrete CMS Development

Developing with Concrete
1

I hope you’re all doing well. I’m currently engaged in developing with Concrete CMS and have reached a point where I could use some insights and advice from the community.

Here are the specifics of my development query:

  1. Extending Core Functionality: I’m interested in extending the core functionality of Concrete CMS for a specific project. Are there recommended practices or resources you can share for developers looking to add custom features to Concrete CMS?
  2. Third-Party Integrations: In the realm of developing with Concrete, have you had success integrating third-party tools or services? Any tips on ensuring seamless integration and avoiding potential pitfalls?
  3. Community Best Practices: For those experienced in Concrete CMS development, are there any best practices or coding conventions that you find particularly beneficial? Sharing your insights could greatly assist developers at various skill levels.
  4. Debugging and Troubleshooting: When facing challenges or bugs in Concrete CMS development, what are your preferred methods for debugging and troubleshooting? Any tools or strategies you recommend?

I believe that discussing these development aspects will not only help me in my current project but also contribute to the knowledge base of the broader Concrete CMS community.

2

That is an enormous question and various developers will have their own views on the answers.

A general rule that I expect all will agree on is: Never mess with core files directly. If you mess with a core file directly, any changes made will be lost or need to be made again next time the core is upgraded. If you need to mess with core functionality to facilitate your own extensions, do it by overriding and extending core classes.

Before overriding anything in the core, see if is there is a suitable event you can hook into. Where available, events can reduce tight coupling and simplify maintenance of your extension functionality.

For coding style, follow the core. But make sure you follow the more recent parts of the core. Some of the older parts of the core contain code that would not pass current review.

My preference for development is to do everything in packages, even if a package is for a single use. (You will find some who, for single use applications, do the opposite and code everything in /application.)

Everyone uses an IDE. Favourites amongst developers here are Php Storm, Visual Studio and Eclipse. For debug we tend to split between those of us who reach for Xdebug first and insert variable dumps or logging second, and those of us who start with variable dumps and logging and only use Xdebug whan variable dumps don’t help.

Personally I start with variable dumps. Concrete has a lot of objects in objects in objects. the var_dump_safe() function comes in useful for avoiding infinitely recursive dumps. I also build debug options into my more complex packages, to dump or trace to the site log, page or browser.

There are some good developer addons in the marketplace that help create boilerplate packages and themes, add internal info or analysis to a page or show it in the dashboard, help edit custom script and css. Many of these are free or cheap and are often overlooked. There are also some good resources on GitHub.

Concrete is a pretty good platform for third party integrations as a client. V9.latest also has an API which 3rd parties can integrate as a service.

Before you code anything, look in the marketplace. Even if you end up not using an addon and doing your own thing, a free or few tens of $ on a marketplace addon can show you how others have attacked a similar problem. Depending on how you value your time, a time vs $ perspective usually means that looking at a marketplace addon or theme will save your project money.

There are many third party integrations in the marketplace, from very specific integrations to more general utilities for all kinds of integration (from my own addons, Universal Content Puller - Concrete CMS and Form Reform - Concrete CMS )

3

Well done John. This aligns almost exactly to my approach as well. Please consider submitting this to be added to the developer documentation under main concepts and vocabulary of a Concrete5 site.

Dave

4

Thank you so much for taking the time to share your extensive insights and experiences with Concrete CMS development. Your advice on not modifying core files directly and instead leveraging overrides and events resonates well with best practices in maintaining code integrity.

I particularly appreciate your emphasis on following the more recent parts of the core for coding style, as well as the practical tip on using packages even for single-use applications. The mention of debugging strategies and the recommendation of tools like Php Storm, Visual Studio, and Eclipse, along with the split between Xdebug and variable dumps, provides a helpful perspective for troubleshooting.

Your mention of the var_dump_safe() function for handling nested objects and the inclusion of debug options in more complex packages are excellent practical tips. Also, your suggestion to explore the marketplace for addons before starting coding aligns with the idea of leveraging existing solutions and learning from others’ approaches.

I’ll definitely explore the developer addons in the marketplace and consider your advice on third-party integrations. The examples you provided from your professional developments of own addons, Universal Content Puller and Form Reform.

Once again, thank you for your generosity in sharing your knowledge.

5

Somehow the end of the above post had been modified with what looked like spam - edited to remove the spam.