Allow read more link to be inserted into wider range of elements
dboulet - August 21, 2009 - 18:40
| Project: | Read More link (Drupal 6 and earlier) |
| Version: | 6.x-5.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Todd Nienkerk |
| Status: | closed |
Description
As far as I can tell, this module tries to insert the read more link inline by searching for a closing paragraph tag that is located at the end of the teaser text string. This means that the link will not be inserted at the end of a paragraph tag which is wrapped in some other element, such as a div. The modifications in this patch serve as an attempt to improve the regular expression used, by having it match a closing paragraph tag which can be followed by any number of closing HTML tags.
| Attachment | Size |
|---|---|
| ed_readmore-HEAD_regex.patch | 872 bytes |
#1
dboulet: You're exactly right when you note that this module only inserts code after a closing
<p>element. Deviating from this raises a difficult question: Inside which elements should the link be inserted? What if adding the link inside the<div>that wraps the<p>results in displaying the link in a non-contextual way?Consider, for example,
<blockquote>. Adding a link inside a blockquote isn't contextual: It implies that the "Read more" link was originally part of the quote. Quite a pickle, eh? :)It just occurred to me that we should add a an option that allows users to choose the elements in which the link will be inserted. Instead of trying to come up with use cases for all -- an impossible task -- we should simply let site admins choose for themselves.
#2
Ha, I should've known that it wasn't going to be that simple ;).
An option to allow admins to choose into which elements the link will be inserted sounds like a good option to me.
#3
Here's a quick first draft of the previously mentioned admin setting.
#4
dboulet: Would you mind re-rolling this patch against the latest commit in 6.x-5.x? I've made some changes today that conflict with your patch, and I'd like to get your opinion on how to resolve them.
(HEAD is out-of-date. Avoid it!)
#5
Try this one.
#6
dboulet: This looks great. Thanks!
Instead of allowing the user to add these elements directly, how do you feel about providing a list of candidate elements that the user can check off? I've attached a patch.
Also, I'm curious to know why you omitted
?:from the $block_tags var in your diff. I'm not too familiar with regex, so forgive my ignorance.#7
@Todd, I guess your method is a little more foolproof, though less versatile. That's probably fine—I'm guessing that 99% of people are only going to choose p and div elements anyway.
As to the omission of
?:from the group of elements, I just didn't see why it was needed, so I left if out.#8
dboulet: As your regex skills are sharper than mine, I'll take your word that the removal of
?:won't be detrimental.I'll commit this change later today. Thanks for your input!
#9
A slightly modified version of dboulet's patch was added and committed to 6.x-5.x-dev. Thanks!
#10
#11
Automatically closed -- issue fixed for 2 weeks with no activity.