Read More Control

Please read all the following and the links provided as this is very important information about your CVS Application.

Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:Migrating from CVS Applications to (Git) Full Project Applications.

• If your application has been "needs work" (or "postponed (maintainer needs more info)"), your application will be marked as "closed (won't fix)". You can still reopen it, by reading the instructions above.
• if the status of this application is a different one, it will be changed to "postponed"; you will be able to reopen it by following the instructions in the above link.

I installed it from the sandbox, works fine (after fixing the .info file with the core version).
thanks!

Works great straight outta the box for me! Thanks!

Absolutely! Works great. Thank you VERY much!

I think "reviewed & tested by the community" was premature. This is reserved for status after a review following the guidelines for review.

I can see a need to run it through the coder module. It still has the un-needed LICENSE.txt. The Project page needs to be edited to describe the project similar to the way it would look if the project was contributed to the public. There is nothing there now, but the sandbox. After those are complete change your status to "needs review".

I assigned myself and will get back when your are ready and try to give you a review. Been tested by others so review should be easy, but I'll load it and give it a try too.

Subscribing.

Sorry, but as I pointed out on that issue, this is a bug in core that needs to be fixed. A workaround module is really not a good solution :/

Why is a workaround module that works not good -- while waiting for a fix to core?

and maybe this module has an approach that is different from the "fix"?

> while waiting for a fix to core?

What are you waiting for? Work on the patch, rather than this module!

This module works perfectly. Waiting for or applying a hypothetical patch to core makes management of client sites more complex.

If somebody writes a patch for Drupal core that would be then be applied, there would not be any waiting. In that case, would updating Drupal be that complex?

I don't think we should argue about this as a core patch or not. There is a need and this module serves it.

1. You need to remove the LICENSE.txt
2. One tiny thing is code style - false should be FALSE, true should be TRUE, comments should end in a period or other sentence punctionation, etc. Can you try running coder.module on this on the "minor" setting and see what it finds?

I didn't test the module and other than those two minor things I didn't see any problems with it.

Ideally someone else could test the module and do a second review before this gets approved.

> There is a need and this module serves it.

Only because core has a bug!

Can you explain how your proposed project differs with the existing community read more solution?
http://drupal.org/project/read_more (formerly http://drupal.org/project/ed_read_more)

This module works and serves the purpose. If patch is there so be it.. I hope it will be included in the core soon. But for the author of this module, lots of thanks for you and more power! :)

To Dave Reid:

The description of that module is "This module allows you to move the "Read more" link from the node's links area to the end of the teaser text." which is something this read more module does *not* do.

This module basically changes the behaviour of the read more link so it only shows up when there is actually more to read, and you can configure that completely. Right now d7 puts a read more link there regardless.

I could really use this module!

Q: How can you tell a Drupal site?
A: "Read more".

This text is way, way too hard for an average front-end developer to change. We have to either modify the core, hack the Locale, or both in order to change the text; if we want to actually make it translatable, then we're S.O.L. and god forbid if we want to use an image in place of the text or have a different content types display different link texts. If there's something easy that I've missed, then I apologize.

It would be great if Views could handle this.... i'm going to request that feature.

Great module. I have suggested at the core issue (link in opening post) that it should have been and should still be accepted as a module for full release, II am using it (though I have one problem with it, added to project issues).

This module works nicely, and gives you much more control than you ever had before you discovered this "issue". Even if the basic problem gets fixed in core, it probably won't let you ignore specific fields as this module wisely does!!!!

Lets get this out of project limbo, huh?

Thank you so much installed and played with it got it working great! Now I can set content types how I want with the Read more link. This should be a core part of drupal.

I've been happily using this module since March. Waiting for a change in core is not a good option.

Great module!
But this needs to get core...

Comments #14 and #15 remain to be answered before this can be approved. Moving to postponed (needs more info) until that happens.

If someone else wants to become a maintainer of this code I guess they could do that and take over the application process.

Here's my perspective: I found a problem that needed to be solved. I looked for a solution and found it here. It works as advertised. If the core is changed later, great. If there are competing features, great - options are good for the consumer and we have blogs and forums and wikis and other modules to compete with the core to prove it. If the new module needs to adapt to core changes, let's hope it gets the required changes, that's the game we play here.

What I don't understand is why there is so much reluctance to accept a new module that performs a valued function, pending a core update that may never occur and may never really resolve the same issues if it is ever implemented.

I will also point out to anyone suggesting "just patch the core" that from what I've seen that whole area is even more politically charged than this silly thread. I may have missed it but I don't even see an open action item for anyone to look at a change to core for this. The skills required to make a core change are also different from those required to create a module. The changes we see here may not make it into the core in the same form, or at all. But the module is already done! At some point if we have both core functionality and a module, people will eventually decide to turn off and remove the module. Until then, what's the problem?

Why is there an argument about this especially in a market where FOSS means we have the Freedom to make choices and the code is Open to modification. No one is asking for anything radical here.

The only thing I see that needs to be done is that the module must conform to standards in order to be properly accepted as a bonafide extension. OK, I hope that happens. If not, it doesn't earn it's place as a module. If it does however, I also hope that people will stop fighting this thing like it's an infectious corruption to the platform.

Thanks for your time.

I emailed the owner a couple of days ago, offered to help / take over. No reply so far. I am not sure how it works in this situation as I am new to contributing code to Drupal. It would make sense to accept it as a supported module as far as I can see, on balance, although I can also the logic of the objection.

@starbuck - the place for that kind of discussion is http://groups.drupal.org/code-review

@John_B - not sure either. I guess the first step would be to work on the patch that fixes your bug #1301060: Read More Link and Read More Module (sandbox) compatibility issue..

> I found a problem that needed to be solved. I looked for a solution and found it here. It works as advertised. If the core is changed later, great

It's not a change to core, it's a bugfix.

> I will also point out to anyone suggesting "just patch the core" that from what I've seen that whole area is even more politically charged than this silly thread.

No, it just needs people to work on finishing the patch.

> At some point if we have both core functionality and a module, people will eventually decide to turn off and remove the module. Until then, what's the problem?

IMO, it drains attention and energy away from core. Core's got a bug? Let's leave it there and just work around it! Does that sound like a good way to develop software to you?

> Why is there an argument about this especially in a market where FOSS means we have the Freedom to make choices and the code is Open to modification.

http://www.youtube.com/watch?v=6T2zUEiVQU4

@joachim, it's been 8 months since the solution was offered. If you know of a way to get a similar change in functionality accepted and integrated into core, please explain what specific steps are required. Many people who use Drupal are comfortable installing a contrib module, not learning how and where to change core.

The steps are explained on that issue: the tests associated with the read more link need to be fixed. A side-issue was filed where webchick stated that it's a fairly simple matter to fix them. It's just waiting for someone to do that.

@joachim : Yes putting energy into fixing core would be a better route, although this module does have some extra functionality. But now the core issue has been marked 'won't fix' http://drupal.org/node/823380#comment-5150526 maybe the case in favour of this module has got stronger?

@joachim: the problem is not that D7 core has a bug -- it is that fields have become first-class citizens and the impact on the "read more" feature was not fully understood. At this stage the attempt to fix it in core seems to be about what approach to take, and I could imagine it drifts into a D8-only extension. Meanwhile, for some reason I struggle to understand, this extremely useful and simple module is being banned from general availability.

There are a lot of contrib modules that change Drupal's behaviour in ways that some could --and do-- argue should really be "fixed" in core. To me it looks like a breakdown in the community when a very useful module is hidden in a sandbox instead of reaching a general release, just because a few people who don't happen to want or use the module decide that they don't want others to use it.

I've been using this module since March, and there is no way I can or could have waited for your hypothetical fix in core.

Core has a bug. It's a PITA to an awful lot of people. However, I doubt it's going to get much attention from core maintainers. I don't think they're going to mark it as 'wontfix', because several core committers and maintainers have now commented on it with words to the effect that it's a valid bug.

But it's not causing huge explosions, and more to the point, the 'read more' links, like a lot of vanilla Drupal, just aren't used any more by hardcore site builders (at least, that's my experience: because they do everything with Views). So the core committers and hardcore developers just don't have this bug on their radar.

That means that only real way this bug is going to get fixed is if the people who care about the problem it causes fix it.

And that's a breakdown in community: when the people who care about the bug are making the fix outside of core. Which leaves core buggy. Should you have to be aware (how?) that when you download Drupal core you also have to download a bunch of different 'fixup' modules? Does that sound like good software to you?

@joachim As mentioned before I am concerned with fragmentation in the community. There are Drupal gods, core developers and people like yourself who speak Drupal api. And people who skills are so low they should probably be using WP. But not many people have the time to learn enough to talk to more skilled people, and not many good developers have the time to help out those lower down the ladder. Also their ideas about what is important in Drupal differ, as you point out in this case.

There are a handful of us on the forums answering questions which sometimes are little more than 'how do I turn this thing on?' It is a way of contributing. I tried asking a question in module development forum, but no one answered, not even to say 'go read the api, you idiot!'

There are other problems, as anyone reading Panet Drupal will see. I don't think anyone is to blame, but the organization is not working well at its current size. IMHO if Drupal is being pushed as an upmarket alternative to Wordpress (as it is, I was at the last State of Drupal address), this module is a 'must' in the short term. If Drupal is being pushed as a powerful framework for developers, your approach to the problem is better. Doing a bit of both is tough and may need some retooling of the community's thinking.

How about we let this module reach the general public, and then some people can look at whether it should be integrated into core, or core grows a better solution?

Have to wake up the owner and get this converted to a full module - the original author is rather antisocial but on IRC, so what exactly needs to be done?

See posts #14 & #29. See also Joachim's objections in this thread which might lead to it being rejected for release as a contrib module. This has made me hesitant to work on it.

go on with this - to kick of an intelligent mechanism for teaser - body stuff is unbelievable ...
why drupal 7 final was released in a kind of beta - we are all testers - prosit!

Core bug should not hold this back! Remember how long it took to get the checkbox required validation error fixed!

Changed queues for #1301060: Read More Link and Read More Module (sandbox) compatibility issue.. It is not an issue with this module.

Code clean-up patch is here #1403640: Code clean-up and the zip is attached for review.

Anyways, this is very promising to provide an out of the box solution for this issue.

Updated the #1403640: Code clean-up to include hook_node_type_update() and hook_node_type_delete() to track the node type variables.

I'm too tired to read the whole issue, so if I'm wrong somewhere - forgive me ;-)

the project page is not very informative, please read about creating great project pages: http://drupal.org/node/997024

getting started with an automated review:

It appears you are working in the "master" branch in git. You should really be working in a version specific branch. The most direct documentation on this is Moving from a master branch to a version branch. For additional resources please see the documentation about release naming conventions and creating a branch in git.
Review of the master branch:

• Remove LICENSE.txt, it will be added by drupal.org packaging automatically.
• Remove all old CVS $Id tags, they are not needed anymore.
  

  README.txt:1:# $Id$
  readmorecontrol.admin.inc:2:// $Id$
  readmorecontrol.info:1:; $Id$
  readmorecontrol.install:2:// $Id$
  readmorecontrol.module:2:// $Id$
  readmorecontrol.node.inc:2:// $Id$
  

• Run coder to check your style, some issues were found (please check the Drupal coding standards). See link below.
• Drupal Code Sniffer has found some code style issues (please check the Drupal coding standards). See http://ventral.org/pareview/httpgitdrupalorgsandboxmonochrome1088582git.

This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. Get a review bonus and we will come back to your application sooner.

Two items:

(1) the January 13, 2012 zip file unzips into the current working directory, rather than creating its own directory;

(2) it failed to work as advertised on the 'When Required' setting, even after a drush cc All.

This is, so far, the ONLY non-core module installed on this site. I see no white space or any other characters in the body.
I placed the entire node into the Summary field.

-- Hugh

ths issue is only for project application purposes and has to be of task category,
if you want to create a bug report issue, please go ahead and create one in the project's issue queue.

setting back to task.

We are using this on a couple of sites, with modifications. And it is working fine (at least with the changes I have made). I wonder if Monochrome is still interested in this. (Last comment here was March 11, 2011. The last commit was 50 weeks ago.)

Being realistic, this is never going to be added to D7, and D8 is maybe 1 to 2 years off.

So I'm happy to help co-maintain and promote this to a full project (with changes from the zip in #41 and maybe others from field testing it for the last few months)

This thread has been idle, in the 'needs work' state with no activity for a month and more over there has been no activity of the maintainer for a year. Therefore, I am assuming that you are no longer persuing this application, and marking it as closed (won't fix).

If this is incorrect, and you are still pursuing this application, then please feel free to re-open the thred and set the issue status to "needs work" or "needs review", depending on the current status of your code.

@Alan D. please feel free to create an issue to take over maintainership or being co-maintainer of the module in its issue queue.
If there is no further reaction of the current maintainer, create an issue in the webmaster queue and request to take it over as abandoned project.

Monochrome has been contacted by email.

Marking as fixed so I get pinged in 2 weeks, then I'll apply for ownership if Monochrome has not responded.

As Monochrome application appears to be stalled and no response, I am willing to take over ownership of the module as it appears that this will be useful in most Drupal 7 sites.

it makes no sense putting the link into the title (damn thing can't be clicked)

No activity for months of the maintainer
No response after more then two weeks after I contacted him personally (See #47)

Therefore, congrats Alan you are now co-maintainer of Read more Control.

Let's continue the review process.

Updated the summary to reflect the new direction of the issue - from project application to ownership.

@Alan D.
As this project application is about giving you git vetted user rights because we know you got the skills to make good and secure drupal stuff, it would be great if you could add more functionality to this module and fix the issues mentioned in #43 so we can review code that was actually created by you.
thanks

Right an hour to address issues raised in this thread.

Need

So far, 100% of our Drupal 7 clients have raised this issue, so from our perspective there is a need for this.

Big cheer for joachim hard work on this in core. I have been following these closely. It will be interesting how this is handled in Drupal 8 (and maybe, just maybe, Drupal 7)

Testing

#4-6, 21-24, ..., and myself
Yes, it works. You can configure the read more link to disappear.

Contrary to my earlier comment, the only changes that I have made in the code to date are related to style:

-    if ($node->node_readmorecontrol === 'when_required' && $node->readmore_required != true) {
+    if ($node->node_readmorecontrol == 'when_required' && !$node->readmore_required) {

etc.

In relation to hesco in #44, I think that there is a UI issue here. I think that you need to manually set the existing instances before the widget kicks in.

Reflecting on this and the "Drupal 6" way, I guess that during installation / D6 upgrades, the node body field instance settings should be set to be considered as a Read more triggering field. The module currently defaults all new fields to be triggers, but maybe this should negated. For example, only default the body field as an enabled trigger when summary != full, all other fields would not be considered as triggers by default.

Coding styles

I created a sandbox for this: http://drupal.org/sandbox/aland/1502824

I would prefer the history from the original sandbox rather than creating a new one. Hopefully this will keep some form of acknowledgment to Monochrome for her great start on this, plus the other two issues.

Onto my own, I think that the variables should be set to constants, and "break 2" is never nice, but I'll leave that for the moment and get a review. (aka the API will be tidied up latter; stay true to the Drupal 6 api when applicable, "$node->readmore_required" "$node->readmore", etc.)

There is a related issue in the Read More issue queue. This blindly includes the read more in the teaser, but why should a full project change it's behavior for a sandbox project? I'll try and work with Dave on this once promoted.

@Additional functionality?

I missed this. What additional functionality would one want from this module? (Other than UI / workflow improvements)

[edit]
After going through the code and cleaning up the readme.txt, this is my @todo list.

Write tests
Use content type hooks to keep the variables table clean
Use field instance alter hooks to define the default settings
Make the defaults mimic Drupal 6 behaviour
Add a preprocessor to add a $readmore variable for node.tpl.php

@alan I added you as co-maintainer to monochromes sandbox, you don't have to work in your own one

Sorry, I didn't realise. Big deadline tonight, so I will clean this up tomorrow.

Transferred my code into monochromes sandbox and removed my own alternative sandbox project. This is purely a code clean up atm.

See the 7.x-1.x branch.

monochrome has submitted core patches example #1041906: Taxonomy term menu link title overrides term page title he gave up on his application after waiting a year.

Maybe he has been given credit as an author of a patch that got committed. See Adding a commit author, this is something that I just found out about and have started doing on my projects.

I have done the code clean up and a bug fix (#1504032: Remove content type settings during type updates and deletes). I do have the rights to promote this project now, but not sure on protocol here.

I have started to refactor / clean-up the logic in the code, just needing to find time to complete this. Any changes I am making will have an upgrade path to the existing sandbox project. This module will be integral in a massive Drupal Domain Access based multi-site that we are developing, so while it may not get the love it needs to achieve the requirements that everybody needs, it will be maintained.

@patrickd
I've developed this as far as I think is necessary to push out a beta release. What steps should be taken now?

We do really need more hands in the application queue and highly recommend to get a review bonus so we can come back to your application sooner.

Monochrome is still around and active (has some new sandbox projects since then but after this one none are in the new project queue, also has some not on d.o but on personal blog) but is *extremely* antisocial, so keep her as co-maintainer if possible.

Well, I think that she needs to finish applying for GIT access to be granted this. It is good that she still has other sandbox projects to continue with this. Some points about this:

The last time that she was involved in this thread was March 11, 2011.
I have contacted her personally, no reply
The webmaster has contacted her, no reply
I have posted a comment on her personal website, no reply

I have taken the base concepts and expanded these significantly. Still giving her credit - from the readme:

AUTHORS
-------
Alan D. - http://drupal.org/user/198838.

Alan took over the early sandbox prototype and developed this into the module it
is now.

Alexis Ryan (Monochrome) - http://drupal.org/user/1147898.

Alexis developed the initial version of this module and has full credit for the
concept and base implementation.

Thanks to everybody else who have helped test and contribute patches!

Before Alan got involved, I also contacted monocrhome offering to help with this module, via contact form on d.o. and via personal site. No reply.

1. I think it should still be able to install without field_ui for minimal site setups: dependencies[] = field_ui
2. .module, _help: '<p>' . t('.....</p>',..); put the p-tag either in or out the t(), but don't mix it up ;),
3. '%readmore' => t('Read More') if you just want to have it italic, this is kind of an overkill, just use em-tags instead (IMHO)
4. you got a configuration page -> add it with "configure =" to your .info file

After all, this module is now sitting here for about 13 months!
As I just found some minor issues (but warning I'm tired) - we should really get this thing through.

regards

Hi Patrick

1) Removed after doing a quick search, / \b[^\.\(]*\(/, I too didn't find any dependencies to that either. Nice find.

2 & 3) Moved the HTML out of t(). It is what core does. And removed the t() argument. I really should have looked at that function, sorry!

4) True. Added.

Thanks!

Monochrome is extremely antisocial. I do all the talking. Unfortunately d.o (and most places) aren't set up so you PM one person and someone else gets the message, and sandboxes don't show non-committing co-maintainers, not that I'm co-maintainer on this one, just some of the others.

Monochrome is and will stay the main-maintainer of the project, full permissions will be kept and locked to him.

I'm sorry but if monochrome is that "unsocial" that he does not answer issues and email - I mean - how the heck should he ever be able to seriously maintain a project on drupal.org?
that's simply not possible without communication.

@giraffian I hope you actually know monochrome personally, or these comments may be read these out of context, making it more unlikely for her to participate in the community.

In regards to "sandboxes don't show non-committing co-maintainers"

If you have a look at http://drupal.org/user/1314122 profile, you will see that he has a commit credited to him for Domain Fields . This was a 1 liner bug fix that I committed this morning that he reported. As per the page Adding a commit author.

And I have added this to the project page (which is already in the readme.txt).

Acknowledgements

The Read More Control module is now maintained by Alan D.

Alexis Ryan (Monochrome) developed the initial version of this module and has full credit for the concept and base implementation.

"Monochrome is and will stay the main-maintainer of the project, full permissions will be kept and locked to him."

If this is promoted to a full project, wouldn't that mean that she would need full VCS rights, something that she hasn't been willing to participate in? And if not, then she has bypassed this workflow "by proxy".

The only real advantage (imho) in being the project node author is that you get to see the project in the "my projects" tab too, making it easier to maintain.

BTW, I think that I have the "git vetted user" role already with my other projects, so why are we going through this? As per #48, this was initially about ownership rather than this role.

Monochrome will not be granted the git vetted user role even if this project gets promoted.
mono will just have the full access rights to this project like it was in sandbox and still has to go through this process personally.

oh, alan, your right, you already got the needed rights and it seems like we wasted a little time here xD

Sorry,
therefore closing this.

K. I will (try to) promote and let things settle down for a few months.

If any one like me came here looking how to remove 'Read more' links from Drupal 7, I've found that http://drupal.org/project/readmorecontrol is the way to go.

Thanks.

Notice