The contextual inline menu appears on inserted images with the same domain name. It doesn't appear on outside images.
For instance: http://fiddle.tinymce.com/k5faab/35 you will notice that I added imagetools_toolbar: "openlink link unlink", to the tinymce.init. Try to insert an image ( https://www.paintthemoon.org/wp-content/uploads/2015/02/250x250.gif ) you will notice that the contextual menu is missing.
I am using TinyMCE 4.7. The issue is present on all browsers.
What you are seeing is expected behavior due to how CORS works in the browser. You can create an image proxy to address this as documented here:
https://www.tiny.cloud/docs/plugins/imagetools/#imagetools_proxy
Another alternative is to build your own method to fetch the image:
https://www.tiny.cloud/docs/plugins/imagetools/#imagetools_fetch_image
...but note that you still have to abide by CORS restrictions so the image proxy may be the more robust solution.
Related
On my TYPO3 v10 website I have some SVG icons in use, no problem.
I also have a few more complex SVG Figures (created with Inkscape), that I want to include in TYPO3 website. Of course I can upload the .svg files to the fileadmin/ folder, and link to them with the Text+Image (or Text+Media) Content Elements.
In the Backend, TYPO3 generates some fine png-thumbnails for preview. So far so good.
The file can be downloaded directly, from its fileadmin/images ... location.
However, inside web pages, my SVGs are not displayed as they should.
A lot of styling information gets removed from the SVG and I don't know where.
Here is a screenshot of the original vs corrupted image (as displayed in the TYPO3 frontend).
Here is a graphical diff that shows the difference between the figures.
It turns out that at some time during the rendering process, TYPO3 removes the values from the style="...." SVG attributes. See reddish boxes.
All my more complex SVGs look like the one on the right when embedded in TYPO3.
Here is the SVG if you want to try yourself: image on SVGshare.com
On the right, many style attributes have been set to style="".
but why?
It's Firefox, not TYPO3, who removes the style="..." attribute values. This seems to be a longstanding Firefox Issue, solved.
See Bugzilla Issue 1262842: [CSP] Blocks the use of style attributes inside SVG without generating console errors.
Look for "triply confusing" in the first comment.
Inline CSS styles can be a security Problem, and therefore Firefox has a Content-Security-Policy (CSP) in place, in order to correct this.
An explainer for the mitigation strategies, written jointly by professional Security Engineers is given in this Google Doc and in Gihub Repo (Content Security Policy), Issue 45, Further granularity of unsafe-inline styles.
Script inline attributes are a difficult subject to approach when it
comes to CSP, they have the same amount of power as any other script
element but they don’t have ways to be whitelisted, for example, by a
nonce or hash. This means that the actual content of the attribute is
mostly the only deciding factor.
I don't understand everything mentioned in these docs and discussions. Inline-style Elements seem to be vulnerable to XSS attacks, and then attacker can put CSS url() in there for instance.
Quick-and-dirty solution
Use Inkscape and save as "optimized SVG", and check the option "Convert CSS Attributes to XML attributes". See attached screenshot of the Inkscape Dialog (Linux).
This solution was proposed by a web-developer from the GIMP devteam.
TYPO3 9 introduced an SVG Sanitizer, which automatically modifies SVG files during "fileadmin upload time", meaning it removes any <style ...> elements from the uploaded SVG file.
In TYPO3 10 and later versions, this SVG Sanitizer is by default automatically set up via Symfony dependency injection via core's Services.yaml.
You can remove the SVG Sanitizer via your own site extension's Services.yaml, e.g. for your myextension/Configuration/Services.yaml:
services:
_defaults:
autowire: true
autoconfigure: true
public: false
# ...
# remove TYPO3's default-autowired SvgSanitizer, which tampers with filadmin uploaded SVGs (e.g. removes necessary <style> information)'
TYPO3\CMS\Core\Resource\Security\SvgEventListener: ~
The tilde (~) removes/overwrites the definition previously set up by core's Services.yaml ( https://symfony.com/doc/current/service_container/service_decoration.html ).
This seems to be a problem of your individual TYPO3 installation. I've just tested your SVG image in a brand new TYPO3 v10 installation and the image is rendered properly in backend and frontend.
Maybe you have some 3rd party extensions installed who postprocess the HTML output of TYPO3, e.g EXT:sourceopt or EXT:scriptmerger.
I am using custom policies and all is working great except that I do not understand the following wierd behavior of the injected html. I am working on a password reset flow and adapted the starterpack.
In a ContentDefinition and indpendent from the layout version (here 2.1.2, but the problem occurs also for 2.1.0)
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:selfasserted:2.1.2</DataUri>
I get a different injected html based only on whether I use the default page
<LoadUri>~/tenant/templates/AzureBlue/selfAsserted.cshtml</LoadUri>
or my custom one,
<LoadUri>https://mytenant.blob.core.windows.net/b2cweb/selfasserted.html</LoadUri>
But this custom page contains excatly the same html as the AzureBlue one. Specifically,
I navigated to the page /tenant/templates/AzureBlue/selfAsserted.cshtml , copied the html content and pasted it in my custom file in blobstorage.
Expected result
I expect the html page where the id="api" div is injected to be exactly the same if I call the LoadUri one or two. Nothing else in the custom policy files is changed.
Result
If I use the default LoadUri, the cancel button is shown just below the div id="api", as expected for a proper html document format
If I use my custom page, which again contains the same html but lives in blobstorage, the cancel button appears below the continue button in the html (but is rendered on top via css absolute positioning)
Also notice the appeareance of an empty div with class="buttons" at the beginning of the div id="api".
I need to understand what is happening for the purpose of understanding and ideally I would like the generated cancel button to appear just like the default AzureBlue.
I checked out that the old, classic userflow puts the button at the bottom, so it is as if I am using version 1.2.0 but only for my custom page, whereas my content definition is always 2.1.2 or 2.1.1.
Thanks Octopus and please find the same response here.
This is expected because of policy engine and location of storage with predefined CORS server and corresponding linked metadata files for rendering. So please use as best practices provided in the document - https://learn.microsoft.com/en-us/azure/active-directory-b2c/page-layout
I've got a multilanguage ModX site. And noticed that when changing languages, it displays a different logo. WHat I need to do is to setup same logo for both languages. Basically:
English side showing: logo.png
Other language side showing: logo-new.png
I don't want to replace logo-new.png file with the correct image file on server in case another part of the site uses that file. So I'm left with actually editing the site header to show the correct logo.
When I go to ModX's site template, I see this code for the header:
<img src="[[++site_logo_img]]" itemprop="logo" class="site-logo">
So my question would be, where do I go to edit the ++site_logo_img value?
For web context try to look in system settings, for other contexts in context settings - https://rtfm.modx.com/revolution/2.x/administering-your-site/contexts
[[++site_logo_img]]
This is a MODX setting, these can be found in settings or in context settings.
Lets say you need a different logo for 2 MODX contexts, you can set a site_logo_img different setting in each context.
I have successfully loaded WFFM on my local Instance of Sitecore. I have successfully created a Form, I have tested it and everything works perfectly.
I have also successfully been able to render the form using an .ascx web control and placing it in my "main" placeholder. Very happy so far, with one exception.
when I enter the URL of the page where the form is being rendered, my top Navigaton, Left Navigation, Right Navigation, and footer is all a different font then the rest of
my site. I have been able to play with the font sizes of the form, but that does not have any impact on the other placeholders.
I don't know what to do to correct this issue. Any help would be appreciated.
Also the navbar-collapse didn't close in ipad in all page that has form.
Regards,
It might be that the Webform stylesheet is overriding some of your styles. You can view the webform stylesheet under: \sitecore modules\Shell\Web Forms for Marketers\Themes\
By default the default.css stylesheet is used. To start out you can try to remove any font stylings in that stylesheet, to see if that will give better results.
To fix it you might want to add identifiers to the default.css ensuring that it only points to styles inside your allowed placeholder.
I have a big SVG document here, containing a map of all the quests in a certain online game. Each quest node is inside a SVG <a> element, linking to a distinct named anchor in a big HTML document that loads in another tab, containing further details about that particular quest. This works exactly as desired in desktop Safari, and I'd expect it to work just as well in any browser that supports SVG at all since I'm using only the most basic form of linking, but it fails badly on Mobile Safari (iOS 6) - which is my single most important browser target, considering that the game in question is for the iPad. It only scrolls to the correct anchor on the initial load of the HTML page; clicking a different quest in the SVG tab will cause a switch to the HTML tab, and the hash (fragment ID) in the address bar changes, but the page doesn't auto-scroll.
This appears to be a known limitation in Mobile Safari - hash-only changes in the URL apparently used to force a page reload, and that got over-fixed such that nothing gets triggered at all now. The fixes I've found online all seem to be applicable only in cases where the URL change is being generated programatically, from within the same document, rather than static links from a different document.
Further details:
I've tried doing the named anchors in both the old <a name="..."> form, and the newer <h1 id="..."> form. No difference.
I've tried adding an onhashchange handler, to force the scrolling to take place, but the handler isn't being called at all (verified by putting an alert() in it).
I could presumably fix the problem by having each quest's details in a separate HTML file, but that would severely affect usability - with all the details in a single file, you can use your browser's Find feature to search through them all at once. (Also, deploying 1006 files to my web hosting after each update would be a bit of a pain...)
Anybody have an idea for a work-around?