Two questions:
I have been reading docs and SO posts.. and know how to do it the long way (defining each and every element and attribute myself), but all I want to do is add 2 or 3 attributes to the default whitelist.. so that I do not have to constantly find and add more elements/attributes to, e.g., HTML.AllowedElements and/or HTML.AllowedAttributes.
Specifically, now, (for internal trusted users) I need to allow javascript attributes (input from tinymce). Question #1.) Is there a way to just add an attribute (to what HTMLpurifier allows) without causing the whole default sets of allowed elements/attributes to be effectively wiped out (overwritten by ONLY what is explicitly written in HTML.AllowedElements or HTML.AllowedAttributes)?
For what I need right now (the javascript attributes), I got excited when I saw in this thread:
Whitelist Forms in HTML Purifier Configuration
...where Edward Z. Yang says, "... [$config->set('HTML.Trusted', true);] allows JavaScript."
...but even after setting this: $config->set('HTML.Trusted', true);, HTMLpurifier 4.4.0 is still stripping e.g. any input onclick="dostuff();" attribute. Why? Question #2.) Is there a quick way to add just the javascript attributes to the allowed list?
You're losing onclick because HTML Purifier doesn't know about that attribute, and if HTML Purifier passed everything through when you turned on %HTML.Trusted you might as well just not use HTML Purifier at all.
HTML Purifier has attribute collections for just this case; 'Common' is probably the right one to insert them into.
But... why? The real name of %HTML.Trusted really should be %HTML.UnsafeMakeMyApplicationVulnerable
HTMLPurifier does not support onClick and similar java script related attributes to any HTML element as a default behaviour.So if you wish to allow such attribute any way, you may add such attribute to specific element in following way.
$config = HTMLPurifier_Config::createDefault();
$def = $config->maybeGetRawHTMLDefinition()
$def->addAttribute('a', 'onclick', 'Text');
But be careful, this may lead to xss attack as you are allowing any java script code to be there in that attribute.
Related
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
I'm new to Angular and trying to understand what the "x-" and "data-" prefixes mean. In the directives documentation (http://docs.angularjs.org/guide/directive) it says that these prefixes will make the directive "HTML validator compliant". What exactly does this mean?
The HTML5 spec allows for arbitrary attributes as long as they're prefixed with data- like so:
<div data-myattribute=""></div>
Whereas this would be invalid HTML5:
<div myattrbute=""></div>
For more information on data- attributes, have a look here.
As for "x-" attributes, I think you mean "x:" attributes and elements, which are specific to XHTML validation...
To expand on this, if you were to (for some reason) be using XHTML, you can define custom attributes with namespacing like so (and I'm just summarizing the gist here):
<html xmlns:x="http://sample.com/mynamespace">
<body>
<div x:whatever=""></div>
<x:mytag></x:mytag>
</body>
</html>
where the URL in xmlns is really just to prevent conflicts between like elements. Also, a DTD for the custom elements and attributes could be provided for validation purposes as a part of your DOCTYPE declaration.
*behavior in browsers is going to vary with this xmlns approach.
In summary, though: With most browsers released in the last three years, or IE8+ you're not going to have to worry about any of these things. Only in very specific situations will you really care.
From the HTML5 spec: http://www.w3.org/html/wg/drafts/html/master/single-page.html
Attribute names beginning with the two characters "x-" are reserved
for user agent use and are guaranteed to never be formally added to
the HTML language.
Also:
For markup-level features that are intended for use with the HTML syntax,
extensions should be limited to new attributes of the form "x-vendor-feature", where
vendor is a short
string that identifies the vendor responsible for the extension, and feature is the
name of the feature. New element names should not be created. Using attributes for such
extensions exclusively allows extensions from multiple vendors to co-exist on the same element,
which would not be possible with elements. Using the "x-vendor-feature" form allows
extensions to be made
without risk of conflicting with future additions to the specification.
we have different type of users on our site. For a particular type of users, we do not want to show URLs(links) posted by them. We want to remove them altogether.
How can I achieve this through HTML purifier config?
The most robust way to do this is to set %URI.Disable to true.
I have a requirement to perform an indexed search across content which must include a couple of tags in the result. The tags must be a random selection. The platform is Drupal 7.12
I have created a view that manages the results of a SOLR search through the search_api. The view returns the required content and seems to work as intended. I have included a couple of Global: custom text fields as placeholders for the tag entries.
I am now looking for a solution to manage the requirement to randomise the tag values. The randomisation is not the issue, the issue is how to include the random values into the view result.
My current approach is to write a views_pre_render hook to intercept the placeholders which appear as fields ([nothing] and [nothing_1]). The test code looks like the following
function MODULE_views_pre_render( &$view )
{
$view_display = $view->display['default'];
$display_option = $view_display->display_options;
$fields = $display_option['fields'];
foreach( $view->result as $result )
{
$fields['nothing']['alter']['text'] = sprintf("test %d", rand(1,9));
}
}
I am currently not seeing any change in the placeholder when the view is rendered.
Any pointers to approach, alternate solutions etc would be gratefully received as this is consuming a lot of scarce time at the moment. Calling print_r( $view ) from within the hook dumps over 46M into a log file for a result set of 2 items.
There are two possible solutions for your task.
First approach is do everything on the template level. Define a template for the view field you want to randomize. In advanced settings of your display go to Theme: Information. Make sure that the proper theme is selected and find the template suggestions for your field. They are listed starting from most general to the most specific and you can choose whatever suits you better.
I guess the most specific template suggestion for your field would be something like this: views-view-field--[YOR VIEW NAME]--[YOUR DISPLAY NAME]--nothing.tpl.php. Create the file with that name in the theme templates directory and in this template you can render what ever you want.
By default this template has only one line:
print $output;
you can change this to:
print sprintf("test %d", rand(1,9));
or to anything else, whatsoever :)
Second approach is to go with Views PHP module. WIth this module you can add a custom PHP field in which you can do whatever you want. Even though the module hasn't been released it seems to work quite well for the most of the tasks and most certainly for such a simple task as randomizing numbers it will work out for sure.
I stumbled upon this while searching for another issue and thought I would contribute.
Instead of adding another module or modifying a template, just add a views "sort criteria" of "Global: Random".
Is there any way only using CSS (no script) to check if an element such as a table contains another element such as with the target? I know that you can use the :target pseudo class for elements with the target, but I need the ability to select an element which contains the element with the target. If there's any way to using the :contains pseudo class to check if an element contains the target that'd be useful, however I've tried it a few different ways with no success. I know there isn't a parent selector which rules out looking for the parent of the element with the target URI. The only possible ways I can think of are using :contains and I don't think that'll even work with anything but text. If anyone knows some sort of trick or other selector that'd solve this issue, help would be appreciated.
First guess:
I'm having a hard time understanding your question, so my answer is offered on the assumption that your question is something like this:
Is there any way to style the parent of a targeted element?
And the answer is no, css works by cascading down the hierarchy, it can't cascade up; have a read of the following questions/answers for further details:
CSS Parent/Ancestor Selector
Is there a CSS parent selector?
Complex CSS selector for parent of active child
(There are others, if you search for 'css parent selectors')
Second guess:
If your question is:
can I find links that target other sections of the same page?
Then yes, you can (with css3 and/or using jQuery):
a[href*='#'] { /* css */ }
$("a[href*='#']") // jQuery selector
The href*='#' part is an attribute-selector, that searches the 'href' attribute for any occurrence1 of the quoted string '#' (the # being used to target same-page links).
If you're able to revise your question to make it more clear what you'd like us to help you with, then I'll be more than happy to try and be more use to you, but as it is I can only guess. Which is pretty much useless. =(
Footnotes:
Other options are:
starts with, eg: a[href^='http://'] which selects all links whose href begin with 'http://', and
ends with, eg: a[href$='.pdf'], which selects all links that end with the filetype .pdf.