Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | ed_readmore-DRUPAL-6--5_inline_elements_setting_2.patch | 4.88 KB | todd nienkerk |
| #5 | ed_readmore-DRUPAL-6--5_inline_elements_setting.patch | 2.07 KB | dboulet |
| #3 | ed_readmore-HEAD_inline_elements_setting.patch | 2.08 KB | dboulet |
| ed_readmore-HEAD_regex.patch | 872 bytes | dboulet |
Comments
Comment #1
todd nienkerk commenteddboulet: 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.
Comment #2
dboulet commentedHa, 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.
Comment #3
dboulet commentedHere's a quick first draft of the previously mentioned admin setting.
Comment #4
todd nienkerk commenteddboulet: 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!)
Comment #5
dboulet commentedTry this one.
Comment #6
todd nienkerk commenteddboulet: 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.Comment #7
dboulet commented@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.Comment #8
todd nienkerk commenteddboulet: 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!
Comment #9
todd nienkerk commentedA slightly modified version of dboulet's patch was added and committed to 6.x-5.x-dev. Thanks!
Comment #10
todd nienkerk commented