+1 on this. I actually had to hack this for the CivicSpace site, and it's still buggy, but much better than having it hidden down with the node links.

I've attached my code for doing in this in PHPTemplate.

if you prefer, this could be done with nodeapi('view') in a module instead opf in the theme.

But is there an easy way to remove the link from node->links once we've added it in somewhere else?

I like the quick fix in #1. What kind of bug does it suffer from?

The bug might be simple to fix, but I'm not sure how to do it... Basically you get an extra divider character in the node links. See the attached screenshot (there's an extra dot next to "Add new comment").

I agree with this feature request also.

To make it easier to notice that a story was continued, this is the change I made in version 4.5.2:

The preg_replace is there to attempt to move the "[...]" inside the last paragraph.

Updating applicable version to see if there is still interests in this.

The paging.module(5.x release) has example of overriding "Read more" link. http://drupal.org/project/paging

The ed_readmore.module gives you this feature. But this is on feature wish list for 6.x too.

Though I really like this proposal, we unfortunately won't get it into D6...
For D7 we might think about rehauling the whole links system, as it is not flexible enough at present.

Hey Pancho, I'm really interested in this feature as I think it's a huge usability improvement for Drupal. Hae there been any issues posted for the potential links overhaul? I couldn't find one.

*subscribe*

I support this as well. I rolled MerlinOfChaos read more hack into a module (ed_readmore) which I use on every site I operate. I've found that the standard read more link placement is one of the most confusing things for site users who aren't 'Drupal aware'.

Anyway, there's an issue filed against the ed_readmore module : #290905: Should "Read More" tweak be in core for Drupal 7. I'd really rather have this functionality in core for a variety of reasons. So, how may I contribute to this effort?

Some goals or features I'd like to suggest:

• Read more link HTML generation should be 'themeable' (rendered in a theme function). This would allow changing the "Read more" text on a per-site basis without resorting to core hacking or using the locale module.
• The default theme function should render the read more link HTML wrapped in a stable, easily-selected CSS class (class="read-more" or similar) to simplify CSS-only appearance tweaks.

Hey inactivist,
As the maintainer of ed_readmore did you want to role a patch against core, I was just looking at Pancho's post and noticed it was 8 months ago so there hasn't been much activity around this lately, I'd be happy to help you with a core patch.

+1 to this feature!

@all:
1. is it your opinion to include all features of ed_readmore.module into core (e.g. inline on/off, GUI for editing 'read more' string)?
2. And do we need to leave the original behavior intact, and thus putting an on/off button on ?q=admin/content/node-settings?

My opinion is:
1: no, the inline should be the only behavior because that has the best effect. The GUI is not necessary if we use a theme-function.
2: I'm not entirely sure, in my eyes the current behavior is not good enough to stay, but it's not a big problem to make it optional.

I would like to mention that since d7 has dropped support for PHP4, and with it the need of providing our own strripos() function. :)

BTW. I'm almost finished creating a patch. I only need to implement the theme function.

I've added a patch with the following features:
- the logic to place it at the inline location. Doing this in core is way, way simpler than doing it via hook_nodeapi!
- option at admin/content/node-settings to influence the position of the 'Read more' link (either inline or with the other links)
- themeable (when positioned inline)

What still has to be done.
- catch other block-type tags
- improve wording of admin/content/node-settings
- add tests to node.test

I'll wait with the above improvements until I've had some response.

i agree with maartenvg. Great patch.

Only a PS: in my installation of ed_readmore.module, if i put "break" tag after a ul/li list, the "read more" link appeared before it and not after the list.

Will test patch soon,
I agree there's no need for a GUI. Moving the Read More link just makes sense.

subscribe and +1 to get it out of node->links

#19: To get this into core it has to be tested by as many people as possible.
Please test this patch. More information about patching (if necessary) see http://drupal.org/patch and http://drupal.org/patch/review.

Patch applied and worked as desired, but I had a few problems after looking at the code:
1. I don't agree with the logic re-write in node_links(). It should be combined like the pre-patch condition. If down the road the node.module needs to add another link, we'd have to re-arrange this back the way it was.
2. Why is str_replace(' ', ' ', t('Read more')) needed in theme_node_read_more_link()? We don't do the same thing in node_link(). Spaces in nodes teasers or bodies are not replace with &nbsp, so why should we do it here?
3. Do we need to implement "TODO: Need to look for any tag allowed by the current filter." from _node_read_more_link()?
4. Do we really need constants for a simple 0/1 setting? If there's a possibility that there will be future placements for the "Read more" link I'm for it, but is that something foreseeable?

Overall, this is a nice usability feature for normal readers. Node readability is improved when the link is inline. I know before I started using the ed_readmore module that people had a very hard time understand there was more to a post since the "Read more" link in the nodes. I literally had to write at the end of the posts, "Hey if you want to see the rest, click the 'Read more' down below!" Not very friendly. +1 for getting this in.

I've attached a patch that addresses issues #1 and #2.

ad 1) I agree, your solution is more elegant.

ad 2) The text "Read more" or a translated version of that, shouldn't break onto multiple lines, because that influences the recognizability and readability of the "Read more" link, decreasing its usability. By using non-breaking spaces, we prevent the link to break. This restriction is not necessary for the links provided by node_link().

ad 3) Yes. It's a annoying bug that it doesn't work properly when the teaser ends in a non-

block like a div, list or blockquote.

ad 4) It's not really necessary, I think. I do not think there will be another placement method, but if so, we can add the constants then. I vote to remove them.

So I'd like to see the above patch improved by restoring 2), fixing 3) and removing the constants per 4). If I can find the time, I'll work on that today.

New patch with some changes ready for some testing.

1. maartenvg, thanks for your explanation of str_replace(' ', ' ', t('Read more')) and did my own tests to confirm this. I added a short documentation that describes why that needs to happen.
2. Found a list of block-level tags from _filter_autop and now instead of just searching for </p>, it searches for the last, ending block level tag. I think this completes the TODO feature.
3. Removed constants.

Looks great, but let's make some tests for this, because it has a history of breaking over unexpected content. I'm working on that now.

Hmm. I've look a bit at how the block level tags are performing, and it seems that it just isn't quite what we're looking.
For example, a teaser ending in:

The next topic

becomes

The next topic Read more

(there's a link in there)

Which definitely isn't what we want. Also, there are some tags in there where we don't want to use, like <hr /> and <thead>

Before we can proceed, we need to discuss which tags we need, and what behavior should be connected to that. For example: a blockquote is always of the form <blockquote><p>CONTENT</p></blockquote> if "Convert line breaks" is turned on, so we need to look for that explicitly. Some of these are also dependent of the "Correct broken HTML" setting of the input formats.
I'll start:
Ending in ...</p>: append before end tag
Ending in ...</h1-6>: append after end tag (on next line)
Ending in ...</p></blockquote>: append before end tag
Ending in ...</blockquote>: append before end tag
Ending in ...: append after end tag (this is the seldom case where the teaser ends without a tag, when all input formats are turned off)
Ending in </div>: before
Ending in </p></div>: before
Ending in </pre>: after
Ending in </address>: before (will alter the style of the tag, but probably not too much)

How to handle lists, tables and forms?

Just wanted to keep this going because we really need this in Drupal 7. It seems that Drupals usability often lacks a lot but in very simple ways and this is a step in the right direction.

I'm just trying to get my head around your last post maartenvg, I'm not quite sure what the problem is, could you explain it a bit more in detail so I can brainstorm it.

The problem is that a teaser not always ends neatly with a </p> or </div>. Sometimes it's a </h1>, </ul> or </pre> or no tag at all, et cetera. The current implementation will place the Read more link before almost all known block elements, making the look and placement of unpredictable and sometimes even will produce non-valid HTML, like </li><a href="#">Read more</a></ul>. For example, the latest patch will transform a teaser which ends in <h1>This is a heading</h1> into <h1>This is a heading <a href="#">Read more</a></h1> which looks like this

This is a heading Read more

Not quite what we had in mind?

So we need to determine which block level tags need which behavior: before or after the last tag(s).

Ok, I see. Thanks for clarifying, I hadn't quite got my head around it.

I agree with the tags you mentioned. For tables and forms we'll just have to append after and it will need to sit on the next line.

Here's a list of all HTML 4 Elements that we will need to think about http://www.w3.org/TR/REC-html40/index/elements.html
Maybe we should setup a Wiki page so we can work together on the list???? I presume using one of the Drupal Groups, any suggestions?

Finding the appropriate place to insert the inline teaser is definitely a challenge (see ed_readmore module's issue queue, if you have any doubts.)

See: #190948: Tweak confused by <ul>, <ol>, etc, #164343: Read More link needs to insert itself before more tags that could end a teaser

Does the output format (input filter) being used on a node have an impact? I think it might.

Perhaps the core implementation should have an admin-defined list (with a default), or perhaps a set of regular expressions, so that no core-level hacking is necessary in order to address breakage in the field.

Also, should the administrator have the option of disabling/enabling this for RSS feeds?

I support this, too. Although for me the main issue is not so much the placement of 'read more' but the text itself. It is a vague phrase. An action verb is better. See: http://www.copyblogger.com/click-here/

Click through rates:

"Read more": 1.8%

"Continue to article": 3.3%

"Click to continue": 8.5%

So as long as this patch allows people to customize the teaser text, too, that would be great.

Until then, we are using the ed_readmore module which allows changing this text.

how do i implement this in 6x? how do i do this patch thingie?

Please do add this feature! It's an excellent one and should be in core.

+1 Subscribe!

This should definitely be in core. Almost ALL CMS systems handle "read more" like this.

I am using ed_readmore and I noticed a two issues with it that I hope doesn't happen if this gets into core.

1. If the <!--pagebreak--> happens to be just after a heading tag,(i.e paragraph, heading, pagebreak, paragraph) the 'read more' link will attach itself to the last <p> tag. It looks unnatural.

2. When used with the feedburner module, the path doesn't follow correctly. When you hover over the "read more" link, the path will be correct except the base URL. The base URL changes to http://feedburner.google.com/. So if you have a node at: http://www.example.com/content/test it will show up on feedburner as http://feedburner.google.com/content/test. Obviously not the desired result.

Simply agreeing with dugh - we should have the text be customizable; I like to use "Continue Reading »" for some situations, "Read more" for situations when a posting shoots the user off to another site, and "Full Article »" for magazine-style sites.

Subscribing!

+1

+1

+1

+1
when the end tag issues are resolved

+1. Excellent!

+1

Please note that Read More is again under active development for inclusion in the Drupal.org upgrade and retheming. Changes are afoot!

+ 1

Regarding the patches added by Dave Reid and inactivist's comment #29, please see #164343: Read More link needs to insert itself before more tags that could end a teaser for the red flags associated with inserting links into most elements. For example, the link cannot be added in the midst of <ul>, <ol>, and <li> elements because it results in invalid markup.

This looks like a really good patch in the works.

A couple things:

1. It sort of "feels" to me like the decision of where to put the read more link belongs in the theme layer - for example, see http://api.drupal.org/api/function/template_preprocess_node/7 and how it splits off the taxonomy links. I wonder if there's a way to do this one similarly?

2. Does it really have to be the job of this patch to figure out how to deal with HTML that gets cut off between tags? I'm not sure it does. Drupal has an HTML Corrector filter that serves this purpose, and the "read more" link should append perfectly fine to any content that is rendered using that filter. If someone is using a text format that doesn't contain that filter, by contrast, then they are already going to have all sorts of problems with HTML getting chopped off and rendered in weird ways, regardless of whether the read more link is in there or not.

3. Check out #372743: Upgrade docs for body and teaser as fields for an interesting issue that might be related to this one. If the node body just becomes a regular old field, and if any textfield in Drupal can be "teaser-enabled", then maybe the 'read more' link is something that gets appended on a field-by-field basis? That's probably thinking a bit ahead, though :)

+1

Too many +++s there. I counted, they are 13. Someone should now fold their sleeves and sit with a cup of coffee.

*subscribe*
not interested in the technical details (i´ll leave this to the experts), but from the users point of view, the current default "read more" system is simply nuts.

@David_Rothstein: I'm marking this issue as a duplicate of #164343: Read More link needs to insert itself before more tags that could end a teaser and have copied your comment (#47) there.

That's a useful link, and seems worth coordinating efforts with that, but since this issue is about moving the feature into D7 core and that issue is about the D6 module, it seems this one shouldn't be marked as a duplicate?

Yes, this should be left separately since it applies to getting the module functionality into Drupal core.

David_Rothstein and Dave Reid: Yikes! Sorry about that. I totally forgot the scope of this issue is not the Read More module. Must've been half-asleep.

+1. (Still no coffee.)

+

I know this issue also from another cms and several users have complained about that.

+1 yup

I support this request, kind of must-have enhancement for Drupal.

+1

yes, should be a Drupal7 feature

I also would appreciate more flexibility for the "read more" link. Thanks for considering it.

Yes! Agreed... cant live without Read More...

May I add that maybe... I am ok with just Read More...
Would love it if it worked with the common "Comments" also... If you have a Comment, you also have more to see, so therefor should "Read More..." be displayed..

I guess more control over these fundamentals would be nice.

I use this module and I find it vital but I think the correct approach would be to address this as an integrated part of the D7 teaser content control (see http://drupal.org/node/274947) AND make the "footer" much more configurable in general.

all for it
+1

+1

+1 this is always one of the first things I have to fix on a new install

subscribing

In case anybody is curious, there's a release candidate for Read More link 6.x-5.0. It's a major overhaul that includes many new features and customizations.

+1

+2 (my wife thinks so too)

Please avoid all kind of string parsing. That's ugly and fragile. It should be easy, fast and robust to do that using DOM manipulation.

I'd like to see this in Drupal 7. Is much more intuitive and far easier than workarounds.

+1 definitely

+1! absolutely yes! and great thanks to developers who implement it!

+1

It must be a feature in Drupal 7...

+1

THANK YOU +1

Don't know why its not already in!

Because people keep posting totally unhelpful things like "+1" and "Don't know why its not already in" rather than actually working on the patch.

@ webchick - lol, the last patch attempt was way back in #23. Since then there are at least three people complaining about the lack of effort, but plethora of +1's. I don't have time to figure out much for a patch right now, but I would be more than glad to test one if someone else makes it.

Should be in core

+1 should be in core. this is one of the modules I *always* install.

OK. Obviously no one here is serious about seeing this issue fixed. Feel free to set back to "needs review" when you have a patch attached.

webchick, +1.

@webchick

I know the frustration you feel about everyone wanting something, but no one providing it. I have had to deal with the issue in the Doc Queue, and it can be quite irritating. At times I want to get into my car, drive to the Airport, fly to the individuals home city, rent a Cab, and then take a bag of dog poo and light it on fire on their door step.

So instead of continuing to frustrate you (or anyone) I will offer a trade. I can not write the patch, I am simple not the person to have the ability to work with other peoples code. I barely know the API, little less the core... My solution... I will TRADE anyone willing to work on this with a task I can perform. Be it support or documentation for a project that is important to the individual who has the ability to write this code.

Sorry, forgot to add the following XML tags

<sarcasm>first paragraph</sarcasm>
<unusualsolution>Second Paragraph </unusualsolution>

Note Proper use of XML is important :-p

+1 this has to be in core.

I think the reason people keep +1'ing this, even though they don't want to help, is because the 'Read more link' project page tells them to do so... http://drupal.org/project/ed_readmore

Is Todd Nienkerk around? Can he maybe try to get this thing tied off? It'd be nice to have it in core, but it ain't gonna happen by typing +1.

Edited beyond original post.

There are a ton of people who COULD work on this patch (around 8X or so). I feel that the question no one wants to bring up is: Why do 80 some odd people feel uncomfortable or unable to contribute a patch for core?

Ohh and one simple but not complete answer to this question is probably the "wont fix" status. It was set to "wont fix" because a person with significant Drupal Clout got angry and basically closed the issue. I think many people who may be interested in working on this issue will see this status and simply move on. I think attitude for contributing to Drupal Core is a key aspect to this discussion.

Example: I know that Mikey_P published a module that I wanted from his sand box. I was to maintain this module (and have been). While working on the modules main page, an individual came in and basically told us that the module was crap (BTW, I maintain this module without acknowledgment on my profile). This individual is another one of those Drupal "Leet". Sorry, but I will contribute where I do not have to take heat for my work. I want to help out, but I am backed up into a corner. My situation is complex (to complex to get into it here), so if you really care to change things, then lets put aside pride, ownership and feelings and have an open (separate) discussion addressing the issue.