hack to rely on nodeapi() causes tags to only be prepared but not processed in many cases
| Project: | Drupal Markup Engine |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | dww |
| Status: | needs review |
Jump to:
I've been making heavy use of DME on a test site that will be launching soon. Today we ran into some serious DME problems where in many cases, DME tags were only prepared (converted into [] to avoid the HTML filter), but never processed (converted into their replacement content). :( I tracked it down to some weird hacks in DME regarding hook_nodeapi() to process the text. The comment says:
// What we're doing here is trying to bypass the problem with filters. If we've got a nid that we can scavenge from the url, then we work at filtering with it so that we can get the advantage of the caching. If not, then we skip this and continue on, with the hope that dme_nodeapi can then pick up and handle the text changeI must admit, I don't fully understand the intention here, but this definitely doesn't work. First of all, the filter cache means that whatever "advantage of caching" you're talking about probably isn't really an advantage. ;) Secondly, this means that DME can't possibly work on non-node text, for example, DME tags embedded in blocks. Thirdly, it doesn't work at all for CCK-defined fields, only the teaser and body, and the custom work-around in the code for RSS feeds.
This seems like a source of many bugs and limitations, for highly dubious "caching advantages". I propose to completely remove this code, which simplifies things, and makes DME much more useful in general. See attached patch, which is running on my site and working beautifully.
In related news, I'd be happy to give this module some loving if you wanted to give me CVS access. There are a bunch of commented-out debugging lines that should be purged. The files are all using DOS line endings and some tab vs. spaces code style issues. Since we're going to be making heavy use of DME, I've now got a keen interest in making sure the code is clean and working nicely, and it'd probably be easier to just do that directly via CVS than lots of patches and issues. I certainly won't do any major structural changes (like this issue) without a patch and an issue for discussion/reviews. Just thought I'd offer. ;)
Thanks,
-Derek
| Attachment | Size |
|---|---|
| dme_no_nodeapi_hacks.patch | 2.22 KB |
#1
Hey there, I'd be happy to take a look at this when I've got some time.
Your request for CVS access sounds like a possibility as well. Can you catch me on #drupal sometime and we can discuss the module's future?
Thanks.
#2
Sorry - still haven't had the time to look at this - life got wierd.
That said, are you still interested in helping out with this module?
#3
I'm still using it for http://socialistworker.org and I'll be taking care of that site for the indefinite future. Therefore, a healthy DME is in my interests, and I'm more than happy to help ensure that. ;)
That said, I know all about "life getting weird", and I've had plenty of that myself in the recent past. So, I can't guarantee I'll always be 100% available for DME work. But, yes, I'm still willing and able to keep an eye on things, fix problems as I find them, help out in the issue queue, etc, etc.
Cheers,
-Derek
#4
I'm glad I found this issue. We've implemented some functionality based on DME and yes, we had exactly that issue that it only prepares, but doesn't process - which would be fine if it would do so all the time...simply broken. But it could behave for days and then just choke without any clue why.
Are you guys still up for working on this? I'd be happy getting involved as well, the basic idea is great...however, there's a lot of filter-based modules out there that might achieve the same thing.
#5
This patch works fine for me. Any indication whether this will be considered?
#6
It probably will be considered - it's just that life's been highly busy for me, and I just haven't had the brain cycles free to work on more drupal-related items. I'm hoping that I'll be able to get some work in on this sometime, but I've now got Drupal Camp Colorado this weekend, and I've got to prep for that.
#7
Thanks muchly. I'm surprised this problem hasn't appeared on the PopSci site...