As a relatively new Site Builder, I understand some of what is going on under the hood. But when things go wrong .…

Without an intimate knowledge of module code and inner workings, the error messages often simply tell me something went wrong.

Furthermore, I don’t know if a particular message occurred from the action I just executed, or if I have simply not been to a specific page in a while (or never before), in which case any number of actions could have broken it.

In any case, I have no idea what messages like this one mean:

'Notice: Undefined index: var_name in _some_method_some_where() (line 35 .…'

This are the steps I typically perform (my workflow) to resolve an error:

  1. Check the module's issue queue for known bugs – Occasionally I find a known problem.
  2. Google the error – Normally this doesn’t help as the same error could happen for so many reasons, but occasionally it leads me to a fix.
  3. Ask a developer if possible – They often have no idea about my problems …
  4. Ignore the error and keep working.
  5. If my site is really broken, I try to reset (ugh) or give up on the module altogether and do something else (sigh).

As a site builder, I really don't want to dive into the code every time.

How can I improve my workflow? Like what other steps, resources, approaches, etc would you recommend to a site builder when such kind of things go wrong?

  • 1
    One more thing to do: Learn to use Drush to access the error log and variables etc in case you get a WSOD. – J. Reynolds Jan 10 '15 at 5:16
  • 1
    A site builder shouldn't be dealing with errors related to code; that's a developer's job. The only sensible way to answer this is to say "learn the skills of a developer" – Clive Jan 10 '15 at 11:54
  • Interesting question, +1 ! I'd like to add another (relevant) answer to it, which is why I tried to enhance your question (feel free to correct where needed), and voted for it to be re-opened ... Fingers crossed! – Pierre.Vriens Jun 18 '15 at 21:28

I'm not really aware of a way to improve your workflow. In general I would recommend limiting your usage to modules that have hundreds or thousands of Downloads by site builders, but that is not a silver bullet. And, sometimes you need to use that -dev module that has only 5 downloads because it will save you tons of time in development work on your project.

Everyone typically builds up a listing modules they are familiar with, comfortable with and trust -- build that list for yourself.

Something you didnt mention and I think is a larger problem than what you've outlined is testing module updates to an existing site that is using tried/tested modules previously. I'm more scared of things breaking during a large update (even amongst stable modules) -- then of experimenting with modules earlier in my site building process.

| improve this answer | |
  • In the end, there are no shortcuts for experience. – digitgopher Jan 13 '15 at 0:35

I think the key is in bullet number one:

Check module issue queue for known bug

You need to get to know the quirks of the module. Study the issue queue of the module the error is occurring in (as well as the module description and documentation, obviously). If your problem isn't there at all, file a bug report and help out the community.

| improve this answer | |
  • Bullet "1." is indeed an important one, but I think there are others to consider as well. I'd like to add (bullet 0.) "learn how to pick your modules, how to recognize the good ones and the less-good ones"). After the request to re-open the question I'll be able to elaborate on that ("add comment" only allows a few hundreds of chars ...). – Pierre.Vriens Jun 18 '15 at 21:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.