Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | filter.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
In past the input filter PHP code have had the FID=2. Now in D6 it have FID=3 or something else (on new installations)... hardly depends when you enable the PHP code filter. If module developers build views based on PHP code they specify FID=3 now and all sites that have a history need to change their module views by hand. Other modules may define format 2 for Full HTML, but get PHP code mode now. This could also result in security issues.
For e.g. OG have this defined, but my upgraded D5 box uses a value of 2 for historical reasons.
$handler->override_option('header_format', '3');
$handler->override_option('footer_format', '3');How can we solved this without telling everyone - edit all your views on every module update by hand and clear the cache to re-read the view files? More and more modules depend on views... I think this needs to be solved in a resonable way.
Comments
#1
This is a follow up of #345857: "My groups" at path og/my show raw code after upgrade.
#2
#3
subscribing
#4
I think this is really a core problem. Formats ought to have string keys IMO. We can't currently refer to the php input format in a cross site way since it has a site specific integer primary key.
#5
Do you think we should add a "filter_formats.type" column like we have in node_type to allow filtering for unique names? This might change the filter API and therefore it would be difficult to get committed to D6...
#6
I don't think this is fixable at all, at least not within Views. Moshe is right, by using a numeric index, Core has guaranteed that filters are not translateable across sites, and the 'built-in' PHP code filter now changes ID.
#7
How about adding a machine readable name in "filter_formats.type" with a value of the module name that defines a filter and a name the module developer like to use? A filter name like [module]_[name] could become "filter_php" that is unique and can be used by other modules!?
Should we move this case to core and provide a patch for this?
#8
Open a new issue if none exists already
#9
It would be much easier to move as we don't need to explain everything again + linking to cases with this issues. All is in the case. So I'm moving now to not waste more time on explainations.
#10
You are mistakenly mixing input filters with input formats.
Yes, PHP module inserts a new input format. But in reality, it provides an input filter. Input filters can be applied to all input formats.
To find the input formats that have the PHP filter enabled, you need to iterate over them. The result may be one, multiple, or no input format with PHP filter enabled.
That's nothing new, so your code was already broken in D5.
#11
Maybe I mixed up something, but it doesn't change that there is a need for an unique key on the filter_formats table to select for specific named filter formats
#12
A machine readable name/string key for filter formats does not help you any further. The format is a dumb container for arbitrary filters. The PHP code format inserted by PHP module may exist, may not exist, or may exist, but without the PHP filter enabled, because the PHP filter may have been moved to another format or may have been disabled in all formats.
#13
a name does not depend on the order in which formats are created on a site. the name does help things. a format can ship and have hook_requirements that all its dependant filter modules are enabled.
#14
You don't need a name (instead of an id) for a format to implement hook_form_alter() to inject a form validation function that verifies that a format contains a certain filter. That would be the only way to require a filter, but it's completely against the purpose of the text format configuration. The user is free to create, delete, and alter text formats, and your input filter might make more sense to the user in a different text format, which may or may not already exist. Therefore, the user is able to enable and configure an input filter in any format. And, the user is also free to delete the text format that some module created (aside from the site's default text format).
#15
I am trying to find solid ways for Features to be distributed in the drupal ecosystem. Features (and Views) depend on input formats and there is no good way to refer to a format in any definitive way. Thats what I want to solve. I think we are talking across each other. Hope this explains my motivations.
#16
ok, that clarifies.
Did you already look into the existing FilterSystemRevamp issues to see whether something like that is already tackled elsewhere?
http://drupal.org/project/issues/search/drupal?issue_tags=FilterSystemRe...