Removing the format field breaks other modules

I can confirm I experience the same issue, and this seems like a good solution. I haven't look at the code in a while but I wonder if doing this would actually allow as savvy user to use javascript to change the value of the format and therefore use a format not intended for them?

In the code comments it is written that this is done "for cosmetic reasons" , so in this case 'hidden' does accomplish this. If the user actually didn't have access to the field, it wouldn't even get this far. So I'd say this is a good change.

Thanks @LittleRedHen this fix is appreciated, (to the maintainer, please see referenced by)

+1 for the patch, it fixes the problems I was having with the Media module.

I'm working on an update script to fix existing data, I'll post it soon.

Critical when we add up the related issues that depend on this.

Here's the set of update scripts, they'll need to be renamed as needed. It's rather elaborate. :) I'm sure someone could improve upon them, but they appear to work.

Here's the update scripts added to the main patch.

Improved update scripts that might work this time ;-)

Fixed the $limit so it's 10 instead of 2 ;-)

Further refinements to the update script.

I'm looking at this issue scratching my head not remembering what it was about or where to look to review it.

Is there a simple test case for this?

or perhaps a picture, couple of screenshots for a simple illustration that gives a visual representation of the issue.
Otherwise, someone else will have to review this as I'm confused.

The problem is that fields which only have one text format available have the 'format' option removed. This leads to this error being logged:

Notice: Undefined index: format in _text_sanitize() (line 349 of text.module).

(see #2825760: "Undefined index: format" error due to incomplete metadata saved via Media WYSIWYG for lots of gory details).
Changing the one single line in better_formats_filter_process_format() fixes the problem, then the other 14k of update scripts is for fixing existing data.

this issue dates back to commit 1a8499ff (dragonwize 2012-07-15 00:18:05 )
Damiens patch should be committed asap due to its affects on other modules.

The 7.x branch has no maintainer so someone will have to request maintainer access to get this in.

See https://www.drupal.org/project/better_formats/issues/3033228 for more details.

Please review this patch that allows using field formatter defaults combined with hiding field instance formatter default value to set defaults and only allow certain roles to change text formatters.

Keep in mind that changing field text formatters to restricted formats could cause issues with access to that field.

Setting the patch back to Needs Review.

After testing my patch fairly extensively, I found that paragraphs items throw an error because drupal does not register functions prefixed with underscores in the same way it does other functions.

Here is an updated patch removing the underscore.

Turns out the patch in #20 has a misspelled function name.

Calling correct function name from element.

trackleft2, I've got a question after an eye-ball comparison to your previous patch for the selector and its permissions.

Can you explain your reasoning for the extra condition? If there are no options and "Use field default" was set, it denies access to the field (the old method) instead of hiding it (the new method). Just curious what you found out in those 14 hours.

Posted Here:

if (!$show_selection) {
  $element['format']['format']['#access'] = FALSE;
  if (count($element['format']['format']['#options']) >= 1 && variable_get('better_formats_per_field_core', 0)) {
    $element['#element_validate'] = array('better_formats_only_allow_defaults_if_limited_by_permission');
    $element['format']['format']['#type'] = 'hidden';
  }
  else {
    $element['format']['format']['#access'] = FALSE;
  }
}

Posted There:

if (!$show_selection) {
  $element['format']['format']['#access'] = FALSE;
  $element['#element_validate'] = array('_better_formats_only_allow_default_if_limited_by_permission');
  $element['format']['format']['#type'] = 'hidden';
}

(And thank you for bringing your fix into this patch!)

https://www.drupal.org/project/better_formats/releases/7.x-1.0-beta4

And for those using PHP 8.0, PHP 8.1, PHP 8.2, use the latest 2.0 release (currently 7.x-2.0-beta2)

https://www.drupal.org/project/better_formats/releases/7.x-2.0-beta2

@joseph.olstad could you perhaps have a short look at the clear regression here and merge that?
#3340025: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal7.temp_fix_better_formats' doesn't exist Currently all updates are failing on our sites using table prefixes.

Thanks!

@Anybody , I had the same problem and just edited better_formats.install , adding the d7 prefix to the queries like "FROM temp_fix_better_formats" with "FROM d7_temp_fix_better_formats"

Whenever it uses the table name variable ($table_name = 'temp_fix_better_formats') , it works: the db_create_table already adds the prefix d7_ .

@b.rafael.oliveria: Thanks, but thats a hacky, manual workaround. Drupal has functionality to automatically add prefixes.
See #1

Just needs fresh releases.

@joseph.olstad sadly looks like this caused another major regression? See #3338558: HTML editor not loading since upgrade to 7.x-1.0-beta4