But enforcing it through code is the way to go. I frankly didn't see it as evident at all. What I saw was that I added hook_block and everything just went haywire without a warning or an error. Really didn't have the slightest idea the theme was involved. After I found that out it was simply intuitive of course. On 4/26/07, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Ashraf Amayreh wrote:
I ran into a very awkward bug today. I created a module and a theme for a client, and naturally, this module contained customizations and the theme was a custom made theme. I named the module and the theme with the client's name. Let's say the client was named abc so I created an abc module and an abc theme. When I implemented the abc_block hook I was surprised to find that all blocks disappeared on all pages. Further investigation into the core and I found that the culprit was the call to theme('block') which mistakingly called abc_block thinking it was a theme override function (rather than the hook it was).
I was wondering if this issue has been addressed before. I can think of three possible solutions: 1. Make it a standard that no theme and module should be named the same (weak solution) 2. Change all theme('block') calls to something else so no chance of conflict could occur 3. Change the hook name so that it won't conflict with the theme call 4. Any suggestions???
Either 2 or 3 seem good enough to solve the problem. But I thought I'd gouge some opinions before wasting time on a less-than-optimal patch.
I did face the same module name and theme name problem a few years back with Drupal (I still prefer PHP based themes with that .theme extension, no PHPTemplate themes), so namespace clashing was evident. The solution is not to have the same named module and theme. :)
Gabor