Drupal 7 port

Would be really great if a 7.x version comes out!

Most of the features in BF are in Drupal 7 core now. I have not decided whether or not the leftovers are going to be ported.

If anyone has opinions on whether or not a feature you like should be ported, post them here please.

subscribing

I vote for a new D7 version, maybe even willing to do a patch.

It annoys me to no end that there is in core:

* Not an option to hide format tips (short of overriding it in template.php)
* Not an option to set a default format (at least that I can figure out)

Would appreciate seeing this module continue and thanks for all the past work on it.

The option to set the default format by role is in D7, though it is not extremely obvious.

In D7 as in D6 you can set permissions on which formats each role has access to. But in D7 you can now order the input formats on the input format settings page. By default the user entering content will be defaulted to the TOP format they have permission to use. So instead of ordering the roles by importance like you do in BF you order the formats by importance.

dragonwize, perhaps what others and I would find extremely useful would be a short writeup on how to mimic the behavior of better formats in D7 using its built in options. As I noted here: http://drupal.org/node/717176 it is not obvious at all how to setup this behavior the same way (even for someone like me who works 12 hours a day on Drupal). I could try and write it up, but I'd think you'd better understand how to word the instructions.

Thanks.

We still need the ability to hide the input format tips. If you are using a WYSIWYG editor, these are pretty meaningless and confusing. +1 for a D7 port for the missing features in Core.

I see no feature in D7 core to allow a default format by content type. (Or am I missing it?)

@JustMagicMaria

Like you I also did didn't see how to set the default format. It is not intuitive at all. I hope people will comment as such on the issue I mentioned above.

I believe the way you set the default format is by dragging and dropping the format you want to be default to the top. As I tried to explain to the people who made that change, that is the most unintuitive Drupal WTF I may have ever encountered. I mean how do you even do that if you are not a sighted user? Oh well.

I don't personally see the need for a D7 version. I don't really care if anons see the format tips when they will be using plain text (at least on my site)

@Josh the Geek: It's a bit annoying to quote from #4 which is from nearly a month ago. Dragonwize answered that the option was available and everything past that has been a discussion of how to show users this option is available.

It's not intuitive to me, and 2 others users have said the same. I know that easily, out of the dozen site admins I work with, at least 11/12 will not understand this behavior intuitively. Just because one set of users on your site uses one behavior does not cover the wide range of Drupal expertise from novice to expert, as well as the range of site installs and options that will be had in the wild. I run nearly 100 sites, so to me this is a much more important issue.

Again though, it's not completely necessary that better formats get a D7 release if we can have better documentation in D7 itself as well as in the docs on how to set the default format. Unfortunately, at this point, getting the change in D7 is probably not going to be possible outside of a point release.

Sorry to repeat my post at #7, but I think it still holds true unless I'm missing something - we still can not hide the input format tips with D7 core - a port of this module is needed for that alone if nothing else.

@tsvenson Great list. I look forward to dragonwize's comments on whether or not these will be ported.

I am all for a D7 port. D7 doesn't provide enough functionality when it comes to text formats. I refer you to. http://drupal.org/node/972720 as to way

@dragonwize Considering the need for a D7 port is fairly certain at this point among at least a decent sample of users, could you please comment on whether or not you will accept a patch for D7? I'm willing to work on a patch over the holiday if you will accept it.

@nowarninglabel Yes a patch will be accepted. From the response here a D7 version will definitely be created. What features it will have out of the box or in later versions is yet undecided. It will probably be whatever I or anyone else has time to program.

Ok, I'll see if I can create a patch this weekend and then get @tsvenson to test it. Thanks.

Subscribing.

I'm definitely working on a patch as I have time (though of course others are welcome to contribute patches as well and we can combine forces or review each others). I'll post it up here when it's ready for review.

We should focus on a core set of features to start with for the patch and then move from there. I am going to be working off of your comments in #13, but if you think you can trim that down even further for the absolute features needed for an initial patch then that would be good too. Either way, I'd like to leave off further features until we have a patch up and a 7.x release.

This may be outside the scope of this module or not.
A feature I need is the following:

Under "Text processing " the curretn D7 has:
- Plain text
- Filtered text (user selects text format)

I need an additional option like
- Filtered text (user DOES NOT select text format)

I have need to have fields that users can select input format and fields where they cannot.

If this is within the scope of this module, can you please support this feature in D7?

#23 Do we not have this func. in the current 6.x branch? You create a new input format that you use on the fields where the users are not supposed to be able to change them? If this not work are you able to remove the format selector in the form api.

BTW: Subscribing :)

Unless I am mistaken, the 6.x version provides it on a node type level not on an individual field level.
The need I have is there may be two text fields, one that accepts plain text only and second separate that accepts Filtered HTML, both of which are on the same form.

My scenario is that I have given specific non-admin privileged users to create content types.
They can add as many text areas as they like for whatever reason.
The text areas provided may accept different forms of input.
In particular, I have recently come across a case where somebody wants to input javascript only in one field and then html only in another.
The javascript would be its own input format and so would the html.
Both would be different fields and both must not allow the user to change the format.

In case there is confusion, the "user" who is not to be allowed to change input formats is the user who is filling out the form and not the user who is creating the form.

In D7 as in D6 you can set permissions on which formats each role has access to. But in D7 you can now order the input formats on the input format settings page. By default the user entering content will be defaulted to the TOP format they have permission to use. So instead of ordering the roles by importance like you do in BF you order the formats by importance.

Took me a while to figure out that this is how you can set a default input format for a role... intuitive, but hidden, and takes some getting used to.

@27 Yes, that is what initially brought me to this conversation, I would say it is not intuitive. That said, focus is on what is outlined in #13 and I hope to have a patch up this weekend and then we will go from there (unless someone beats me to the patch first.

Important this patch is not ready to be used yet
Ok so here is a patch for converting d6 to d7. The module will enable in D7 now however you will get an unsupported operand types when trying to go to the permissions page, as there is still some work separating out the permissions sql queries into some separate ones since "permission" table has been changed quite a bit with its move to "role_permission". I have converted some of the queries though to the new d7 format. That said, I'm posting this up in hopes that some others will join in on the coding. If not, then expect some more from me on this next weekend.

It's based off of 1.2. I believe it is better/easier to upgrade modules based off the stable version. I'm changing the version issue to indicate that, but hey if someone wants to build a patch off of 6.x-2.x-dev then go for it.

@tsvenson No worries, if you don't mind waiting a few days I should get some time to finish it up by the coming weekend.

Just sub'ing. Right now the *only* feature I need in D7 that isn't there is hiding the silly input format tips when only one input format is available to anonymous users. A bit weird that I have to give some basic HTML tags to "Plain text", but whatever.

Rather than a port, I'd almost rather see the D7 version be a clean start. There's so much not necessary for D7 that I'd prefer Better Formats not introduce a lot of largely-unnecessary UI.

I can't find the founction in Drupal7.

I'd like to keep this on focus.

The list of features that will go into the D7 version, at least as far as I am going to work towards patching, are listed in #13.

Also, the current patch is against 6.x-1.2 because we want to work off a stable branch.

Finally, the current patch needs work, feel free to jump in, otherwise I will probably work on it this weekend (maybe on the plane tonight, but more likely this coming weekend).

On a side note,
@dragonwize If you want to give me commit access I can go ahead and commit a 7.x-dev release with the working patch when it is done. That should make it a bit easier to get this moving.

I've created a 7.x-dev branch and committed most of the changes from the patch in #29 (Thanks nowarninglabel).

I will be working on the port today and as much as I can over the next week at least.

While there are a huge assortment of features to possibly add, the below list is what I will be focusing on for the initial release.

• Seperate defaults for comments. First on the global level and possibly at the content type level.
• Control over the display of the format selection output.

All other features will be worked on and fitted in on a time and effort available basis.

One thing to note is that I will not be just doing straight 100% porting from 6 to 7. I will be building the 7 module with the features and options in D7 in mind. So while the features will be similar in function it will be more like a rewrite then a port from a code perspective.

Any devs wanting to help out can work on the 7-1 branch in CVS and post patches. (as usual, good work and communication will get CVS access granted, if wanted)

All non-devs that want to help, I will be posting a 7.x-dev release when there is something to test. Until then please continue to talk in this thread about any ideas or requests you have to the 7.x version of this module, the conversation really helps me out by hearing others opinions.

@dragonwize Excellent. Thanks for taking this on. I'll take a look at the CVS this weekend and see if there is any work I can do some patches for. Cheers.

Here is a big question I could use some more user input on.

For the D7 format defaults, do we:

1. Go with the D7 method of weighting the formats and allowing the top format that the user has permission to use be the default.
2. Stick with the D6 way of weighting roles and assigning formats.

To be more consistent with D7 I would like to go with #1 but I am not fully convinced that methodology will allow enough flexibility and it is not as usable because you have to think through 2 steps.

What are your thoughts?

I vote #2. #1 is a usability fail for the reasons already mentioned back in this thread. If it takes more reasoning to convince people of this, I will try rolling this into the D7 usability study I am attempting to commission with our accessibility department.

@tsvenson: This is not a question of changing what is already in core, but a question of what workflow show the features added by BF use?

subscribing
D7 port is needed

subscribe

D7 port is needed!

subscribe

+7 (will write sth more soon), thanks!

The one feature from this module that I need is to force a user to use a particular format per content type.

For example, people might want to include heading tags in blog posts or articles but I don't want them to do that in blog posts.

This may have been requested already, but I would like the ability to disable "plain text".

Also as soon as there is a 7.x-dev release I would also like to contribute to testing and patches, as I found the D6 version extremely useful when it came to restricting clients ability in CCK field areas.

Thank you!

Sorry about that didn't mean to change category, but at this point if you are not looking for any more insight you should just close the issue..

sub

I agree with #46. That limitation of Drupal is one of the biggest banes of all times, because of it's incredible flexibility, but lack of fine grained control.

I don't want content that is meant for documentation to use the same kinds of filters used in forum postings on the same website. That would be just ridiculous in many cases. Per content type text filters should be something built-in to Drupal, but if it's provided through Better Formats instead, I would still be at least satisfied.

Subscribing too, you have no choice now ;)

subscribe

Subscribing.

Subscribing!

Subscribing!

Subscribing.

Subscribing

+1 for "Default Formats by Field"

I'd love it if this would outweight the Role-based formats. Specifically, so a particular field could override a users permissions, allowing Full HTML for one particular field, or JavaScript, or whatever, whether the user has that permission or not.

I completely agree with what psi-jack said above:

I don't want content that is meant for documentation to use the same kinds of filters used in forum postings on the same website. That would be just ridiculous in many cases.

I'm having this same issue with my D7 sites.

Is there any update on the D7 port?

+7 and subscribing

Subscribe

Please don't let a great project die... D7 needs you ;-)

+1, very important

For the really adventurous, you can find the 7.x. pre-alpha version at http://drupal.org/node/342318/cvs-instructions/DRUPAL-7--1

I guess this week I need to figure out what needs to happen on that before a dev release can be made.

subscribe

Subscribe

subscribe

subscribe

Doesn't work yet. No settings in administrator. Keep up the good work

Hello,

Just installed the 7.x-1.x-dev version and can't see how to use this. As konov said it doesn't seem to have any settings when logged in as administrator. Is it ready for testing?

Thanks for reading,
-Tim

Currently the only thing that is ported is the display options that are controlled through the permission system. No default format features have yet been committed.

+1 default by field
subscribe

Subscribing

Subscribe!
Vote for filters by FIELD

Can we maybe change the title to "Drupal 7 port - Better Formats"? This keeps popping up in my tracker... along with 10 other 'Drupal 7 port' issues.

+1 to previous commentor

Sorry, I am full against that. There are many ways to get the project information other than putting the name of the project in every single issue title. That is bad form and bad data. Next it will be the version, component, category, priority, status, etc, etc. I feel strongly that the title is the title, and we have other places for all the other data.

@last post

Kind of makes the dashboard useless then.

This is not the issue queue for fixing problems with the dashboard.

There are many ways to get the project information other than putting the name of the project in every single issue title.

Short of writing up a greasemonkey script to have my tracker look up the project associated with a particular issue, is there any way at-a-glance that I could identify that this is for 'Better Formats' as opposed to some other issue, then? Please be more specific.

That is bad form and bad data.

I agree that it'd be unnecessary if there weren't 100 other 'Drupal 7 port' or 'Drupal 7 upgrade' issues on drupal.org right now, of which I'm probably tracking 20.

Next it will be the version, component, category, priority, status, etc, etc. I feel strongly that the title is the title, and we have other places for all the other data.

I don't think so—this has only really been an issue for me with drupal 7 version ports... Very few issues (besides maybe the dreaded 'HTTP Error 0' issue) have the same or extremely similar titles across hundreds of different projects... but, as you're this module's maintainer, I'll have to defer to you. I think, until we have a better issue tracking/subscription system on drupal.org, and for these specific issues, the only sensible way to show them is by adding the project name to the title... but I digress.

I do not want to hijack this issue anymore for this purpose but here is my quick response.

I don't know where you are viewing this issue from but lets look at an example that a great many people use that works, email. The email responses to this issue come across with a subject line of "[better_formats] [task] Drupal 7 port" and the rest of the vital information is included in the body.

If whatever method you are using to view this issue or it's updates does not provide such basic information then please file an issue with whatever software you are using or with in the Drupal.org infrastructure issue queue to request that they correct the problem.

The whole point is to have _anything_ referring to which module it is about in the Title.
Even just "Drupal 7 port of BF".
It makes the list of "recent updates" more usable when I can see which of the MANY titles belongs to which module. Right now I cannot distinguish between them as most are titled "Drupal 7 port".

Is this a big issue? Why can we not throw in a practical word there if several of us see it as useful? This is a community, right?

Here is an example that greggles just made in the chatroom module queue:
http://drupal.org/node/904006#comment-4279058
(added the module name to the title, most likely for just the above mentioned reason)

Subscribing

Subscribing!

sub

+!

There is a D7 branch, we should close this issue and open new issues for any bugs & feature requests, per normal practice.

Just because there is a branch does not mean the module has been ported. Only some work has been done. I do not want to get bug reports on something that has not been done and it is not a feature request. It is the fact that this issue of porting the module to D7 is not in any way complete yet.

@dragonwize: fair enough :)

@dragonwize Are all your changes commited into the dev branch? If so, I can do a fresh checkout and try working further on it.

All changes that matter. Patches appreciated. I can merge when needed.

A feature to modify format tips...
I wish to display some custom format tips on a Wiki Custom Filter (which i have created for Wiki Content Type)

subscribe

subscribe

I was just testing the latest dev release (is there an newer version?) with the latest WYSIWYG dev. It looks like setting #access to FALSE on the format fieldset gets in the way of the wysiwyg module from attaching editors properly. I tried just setting it to collapsible/collapsed for the hell of it, but that also breaks things somehow (which is odd).

The only thing that really seemed to work was adding a 'hidden' class and hiding the fieldset that way. This combined with unsetting format options in the select that aren't accessible works with WYSIWYG.

The odd thing is that the WYSIWYG module attempts to add a hidden input when the format fieldset has #access = FALSE, but their JS doesn't seem to actually be able to handle that. Maybe this is more a bug in the WYSIWYG module that an implementation issue that this module needs to worry about.

subscribing

subscribe

Subscribing, as I too am interested in setting default input format per content type (or even per field/field-type).

subscribe +1

subscribe

changed title for better tracking

sub

I installed the DEV version today and it works as far as I need it. THANKS!

Reverting the title to the improved version.

Thank you for the title change, Damien.

Stop changing the title. See #92 if you need explanation.

Oy. @dragonwize, I know you're the developer and all, but I cannot fathom why you care about the title this way. I see it in the "Your Posts" section of my Dashboard, where it appears without any context. Yes, maybe DO could fix that. But a simple name change fixes it, too. I have read what you've said on the topic. It seems like you are spending a lot of cycles on what should be a trivial issue. And numerous other issue queues have in fact adopted the convention that you are bothering to reject here. I do truly respect your contribution in working on this module, but when you do this you just look petty.

yeesh.

And that's the last I'll say about this.

@David D. You say you have read my reasons but can not fathom them, you call my opinion trivial and and me petty, then you give the bandwagon fallacy as your primary and only reasoning. Please consider showing the respect you say you have in the future.

I value your opinion that you would like to have the title changed so that you can read it better in that block. It is a completely valid cause. However, so is my opinion of not cluttering up the pages and emails that I read with extraneous information that makes everything hard to read as well. I am not trying to force you live without your way. I am providing the proper solution that gets us both what we desire instead of just one of us. We live and work as a community so if you would like that changed, start or join an issue about it to get it changed.

#34496: [meta] Add Flag module to allow users to subscribe/unsubscribe without posting a comment - related...

@dragonwise / #121:
With all due respect, I must admit that am getting slightly curious here...

a) Lets assume that we are all aware that this is a community and not anyones personal playground.

b) With a) in mind, do you think that the developer opinion counts more than _several_ others, who might be developers themselves here? If not, is it not just fair and good practise to accept what several people suggest? In this post alone there are around 4 individuals who indicate that they prefer having the module name in the title (specifically for "ports" issues, so we can keep them separate from each other on our dashboard. Do you regard yourself as the only one whose opinion counts in even smallish matters just because you are the maintainer here?

c) This is a community where we should try to be as agreable as possible, IMHO. This is not something any of us should spend time on, why bother correcting this in the first place? Lets focus on what we are here for...

It is quite common practise for many projects here on D.O. to include the project name in issues related to porting, especially right when we are in a transformation between two major versions.

(I will not post or answer any follow-ups about this after this comment, even if the title gets changed 100 times over again)

For the modules I maintain I get emails for all issues, so it's easy to keep track of things. However, for modules, like this one, that I don't maintain I have to rely on something like the 'Your Posts' block in the dashboard. The reality is that it's currently damn near impossible to track things in that block unless the module name is in the title. Could the DO fix it? Yes. Do you know how long it takes to get fixes out fo the DO team?

Please reconsider your position on the title issue. You are one of the few holdouts in the developer community. You are making it easier on you, and making it harder on everyone else (ie. the community).

OT: I won't change any titles, but as almost everyone else I would prefer the full title since the page I'm using for tracking is "My recent post" and I'm subscribed to a lot of Drupal 7 port issues. I understand that it's not that elegant, but as d.o. works right now it's the best solution.

Is this some kind of joke! 2 weeks of updates on this post - not one of them with any substance at all (including this one). What happened to the community spirit?

the joke's on you, we were all hiding behind the couch, surprise!

Subscribing... lots of noise on this thread. Read through comments, but still confused about whether 7.x-1.x-dev is somewhat functional or note.

--Ben

+1

Subscribing. (but still confused if we're working on porting the module or the title here :P)

Subscribing. The main feature I'm interested in is per-field restrictions on available input formats, as that would allow me to kill filter_by_node_type, which I've wanted to do for a while. Is that in the dev branch yet or no?

@crell oh! i was working on a d7 port for filter by node type. let's see what happens here then.

@Crell, per-field level restrictions is not in the current build. I just committed a core level per-field default system but restrictions are not included.

I looked at filterbynodetype and did not see a per-field solution there. It seems straight forward. There is per-node type restrictions in D6 of BF. The biggest question I have is where would be the best place to store the restriction data? on the field instance itself is my first reaction but I have not looked into it yet. Any thoughts on best place for storage?

FBNT only works on body fields, sadly. I never got CCK working. I'm hoping you would. :-)

On the field instance would be ideal, but I don't know that the field instance data structure supports arbitrary new properties. If not, then it probably needs to be a separate table that gets saved to manually with form alters. Well, actually with a proper mini-API that form alters leverage.

Unsubscribe... dangit! Death to subscribe comments.

This is an annoying issue that will simply not die, and rears its head in my issue tracker like a nameless hydra. Can we please just close this issue (restating request #98 by @DamienMcKenna)? There is a D7 branch—if there are specific D7 issues, they could be (and would be better off) discussed in their own issues.

Agreeing with #140. Since there is now a D7 branch, this issue per its original focus is "fixed", so we can continue in specific issues for this branch. Closing this one.