Hi, I suggest a compromise, a variable for the break -- without an interface. To use best, this will need a contrib module to be written but jadwigo already said that such a module could be reused for multipagecontent breaks etc. I believe that such a module would be quite simple. Please give your *thoughtful* review and test http://drupal.org/node/87145#comment-173683 Regards NK
On 1/4/07, Karoly Negyesi <karoly@negyesi.net> wrote:
To use best, this will need a contrib module to be written
Curious...why? The patch is simple enough and would put the compromise into effect. People who use wysiwyg editors can just configure their install to use the comment-styled tag such a module could be reused for multipagecontent
breaks etc. I believe that such a module would be quite simple.
That asked, the whatever module would be simple. Multipage content is so simple I thought it was left out intentionally, and there's a pretty decent looking module to handle it already.
I've posted a different and more interesting compromise here: http://drupal.org/node/107061 :) Steven Wittens
Steven Wittens wrote:
I've posted a different and more interesting compromise here: http://drupal.org/node/107061
I have been staying out of the conversation since I did not notice the original patch go in and don't want to get involved in a messy discussion. I have not fully read up on the plentiful discussions. Steven's new UI element is good functionality, but isn't something I like see happening in release candidate phase. The new variable which chx proposed is a hidden setting. By default, hidden settings are not good since they increase debugging load and code obscurity. The approach does accomplish the stated goals. I think the two simplest options are the best- either roll the patch back, or keep <break />. Rollback is a good option because <!--break--> has been happily working previously. Keeping <break /> is good because it is being tested now. Either of these changes should of course come with any necessary associated cleanup. -- Neil Drumm http://delocalizedham.com/
At 4:13 AM -0800 1/5/07, Neil Drumm wrote:
Steven Wittens wrote:
I've posted a different and more interesting compromise here: http://drupal.org/node/107061
I have been staying out of the conversation since I did not notice the original patch go in and don't want to get involved in a messy discussion. I have not fully read up on the plentiful discussions.
Steven's new UI element is good functionality, but isn't something I like see happening in release candidate phase.
The new variable which chx proposed is a hidden setting. By default, hidden settings are not good since they increase debugging load and code obscurity. The approach does accomplish the stated goals.
I think the two simplest options are the best- either roll the patch back, or keep <break />. Rollback is a good option because <!--break--> has been happily working previously. Keeping <break /> is good because it is being tested now. Either of these changes should of course come with any necessary associated cleanup.
I agree that rollback is a good option. We should roll this back to the way it has always worked and take the time to carefully address all the issues that have been raised about this change. Trying to address such a controversial issue within the context of people working hard to get drupal 5 out the door is bad process. Let's slow down, and find a solution that actually addresses the issue. I guess this is why major changes like this are not supposed to be made at this point in a development cycle. (personally, I've built and therefor do long-term hand holding/support for more drupal sites than I can really count, please don't force me to spend days on the phone re-training all those users) --Eric -- ------------------------------------------- Openflows Community Technology Lab, Inc. New York | Toronto | Montreal | Vienna http://openflows.com People are intelligent. Machines are tools.
On Fri, 2007-01-05 at 09:37 -0500, Eric Goldhagen wrote:
I agree that rollback is a good option. We should roll this back to the way it has always worked and take the time to carefully address all the issues that have been raised about this change.
Trying to address such a controversial issue within the context of people working hard to get drupal 5 out the door is bad process. Let's slow down, and find a solution that actually addresses the issue.
I guess this is why major changes like this are not supposed to be made at this point in a development cycle.
(personally, I've built and therefor do long-term hand holding/support for more drupal sites than I can really count, please don't force me to spend days on the phone re-training all those users)
--Eric
I'm in agreement on a rollback.
participants (7)
-
adrian rossouw -
Darrel O'Pry -
Earl Dunovant -
Eric Goldhagen -
Karoly Negyesi -
Neil Drumm -
Steven Wittens