I have tinymce inserting posts into a database where they'll be subsequently pulled and put into a webpage. The problem is that some of the elements are interfering with page elements.
eg. Maybe the HTML that's being copy / pasted will have a table HTML tag with an id that conflicts with another id already on the page. Or maybe in the style attribute there'll be a z-index so the post cover up certain elements of the page.
I don't really want to blacklist attributes because (XSS considerations aside) I'm thinking all should be considered fair game (well maybe not event handlers) and if it interferes with the layout I can disable those specific tags / attributes on a case by case basis.
Any ideas?
There are several ways to filter your content:
use the tinymce paste_preprocess parameter to filter pasted content before insertion
you may use the valid_elements, valid_children and extended_valid_elements setting to allow which elements and attributes tinymce accepts as valid html tags (this is something you don't want?)
you can filter your code before writing it to your database
You could filter it when putting the content from database into another web page
Related
Does anyone know of a ready-made plugin that allows adding input, textarea, select etc. on tinymce?
The tinymce.dom.Selection API (https://www.tiny.cloud/docs/api/tinymce.dom/tinymce.dom.selection/#select) allows you to select elements or set content in the TinyMCE editor. You can assign the API class to an action or an interaction element like a button or form, and any selected content will be replaced with the contents the API action passes in.
If that's not a good fit for what you need, is there an example of the type of adding input, a textarea, or a select you're looking for?
There are no official plugins that allow such interactive elements to be added. TinyMCE is a text editor that is built to create blog posts, articles, etc. By design, it is not a page builder. However, there may be some unofficial plugins on GitHub that may implement such features.
If you are going to insert forms and text areas that should not be edited or reconfigured afterward, you can use templates. They may come as any valid HTML. Thus, some fixed forms can be just saved as templates.
Another way is, of course, inserting HTML directly into the code.
i want to edit an existing Typo3 Backend configuration page.
I want to edit a configuration page like this here:
Where can i edit the extensions backend?
To be more clear: where can i change the edit page that an editor can use to change content.
Can someone give me a hint to the right directory or file in generall?
I'm using Typo3-7.6
Thanks
Sorry, can't manage to put all questions in an unformatted comment.
there are a lot of questions, as you are not clear what you want. Maybe that is a problem of the correct words, the vocabluary, but in TYPO3 we have some fix terms for specific object. And I think you do not handle these terms according to the TYPO3 community.
let's define some terms:
first the concept of TYPO3:
all data is stored in record of differnt database tables. All records are organized with some fields and teh main field is uid, the unique ID.
the main table is pages according to the folders of your disk. those folders can contain other records (like files). (nearly) each record in TYPO3 has a relation to a pagesrecord ina field named pid. even pagesrecords have this field and so they build a tree of pages and subpages.
There is one special page, which is no real page: the page with the ' uid' zero. As there is no real pagesrecord with the uidzero, there are other records with are stored in that page by having a pid zero. for example the start of your page tree is anchored in page zero, or global records like languages, user, storages.
Aside of being the anchor to other records, the pagesrecords have information themself. (page name, kind of page, a teaser image, SEO-information, visibility, accessibility, ...)
your screenshot looks like a content record (normaly in the table tt_content), in the lower right corner there you can see the table name and the uidthe the currently edited record.
'Backend': with backend we name the view to the data where an editor can change the content of the website. The real website is the frontend. This can be seen by everyone without the need to login in the backend (you might have access-restriccted areas of your website which need a login, but that still is 'frontend' as there is no option to edit content.
in the backend the editor might be restricted what he can access and what he can modify. An adminuser has no restriction (up until version 9 where the role of a maintainer occured to manage more general and basic options)
so we have not a single 'backend configuration page' but multiple places where we could configure special aspects of the website.
also there is no special 'extension backend'. we have global extension configuration and records belonging to an extension. (And an extension can enhance existing records with additional fields.)
Please be more specific what you want to change
In my custom TYPO3 Extbase extension, I created a backend module to manage person records. Now I need a content element to show the records in the frontend.
I see two ways to achieve this:
Use the CType "list" and a custom list_type. Provide a FlexForm for additional fields
Use a custom CType, a FSC DataProcessor and TCA for additional fields
What's the best, most future-proof way to achieve this in TYPO3 CMS 7.6? What's the (dis-)advantage from one over the other?
The short answer
It doesn't matter, both ways are valid and will be supported in the future as well.
The long answer
I would always differ between a content element and a plugin but I agree that sometimes the difference might be hard to get.
A content element holds all information it should show inside its own record. As an example you could take an image gallery where all images are saved in a relation with FAL. Processors can be used to add additional information like done with FAL records.
A plugin contains controllers and actions and shows data which are saved somewhere else, e.g. records or from an XML or any other source.
Both types could be enhanced by providing a configuration using flexforms or additional fields.
I have an embedded form collection in Symfony. Which is working nice. I am working with a manytomany assocation mapping.
Except i want to create (with javascript?) the form so that only unique values are available. In my example i have an Organisation which can exist of many users. When i add user "L" in this case and i want to add a second user i want to prevent that user "L" is available in the other dropdown.
The way i embedded the collection of forms is exactly like the documentation of Symfony has learned me. (http://symfony.com/doc/current/cookbook/form/form_collections.html)
Down below is an example of how it works now (in this example I want to prevent that in the dropdown the user "L" is available as an option.
Thank you very much!
Unfortunately, there's no way you can make the HTML form behave this way. HTML forms just do not have any composite (or dependent) <select> widgets. So, the right way to go here would be:
validating the form server-side, so that duplicate values in two select boxes are not allowed;
adding some JavaScript code to the view that renders form. Perhaps this code should listen to <select>s' onChange events, and once an event is received, the option selected in the first box should either receive a disabled attribute or get deleted.
I often face a problem when I need to encapsulate some far apart fields in one form, and the fields in between them in other forms. Or encapsulating first two rows of a table in form and other two in other forms and so on. But of-course this is not allowed in standard practice. My question is why such tags like form (and other non displaying tags) have to be treated as "displaying" tags, and they also are restricted to be used at some places. Is there any genuine reason.
PS: what I was thinking about form in particular, that I define as many forms as I want at a single place, and give their references (eg ids or names) to the corresponding fields. That way form tag does not have to interfere somehow with the location of fields?
Asking "why" questions of HTML behaviour is not normally a useful activity. Very often the answer is "because one of the browsers originally did it that way and we're stuck with it for backward-compatibility reasons".
Note also what #DanMan says about the displayability of <form>.
However, your description of declaring forms in one place and then having the controls associate with the forms by id, is very similar to what has been done with the HTML5 form attribute. The only difference is that the controls reference the forms, rather than the forms referencing the controls. All we need to do now is wait for implementations in the browsers.
How is a <form> a non-displaying element? You can apply all kinds of CSS on it, and they will show up. It's just that they usually have no default browser styles. It's a rookie mistake to wrap elements in <div>s and styling those, when the only thing inside them is a single element.
<div class="myform"><form>...</form></div>
<form><div class="myform">...</div></form>
Both equally superfluous. Just style the original element directly.
<form class="myform">...</form>
Now, before you jump on my back: I'm not saying you're doing that. Just a general advice.
About restricted usage: that's probably to make it easier for implementors (browser creators) and for backwards compatibility.