I'm building a website using brython and I came by a problem that has nothign to do with it.
My problem is with Mezzanine or TinyMCE editor (I'm not sure which). To make brython work I need the script tag to be "text/python". But the editor filters it automatically to "text/javascript".
I disabled the filtering already, both in the admin panel and in the actual source code, I tried adding "text/python" to the RICHTEXT_ALLOWED defaults in the mezzanine configuration too.
Just to be clear, security is not an issue, this particular feature won't go online in the final version of the website.
Although the HTML specification does allow one to put any value other than "text/javascript" in script's type attribute, few projects do that, and Brython is one of those few. It is likely the "text/javascript" value is simply hardcoded in the editor and it won't allow you to change that.
(There is probably a big chance of having an issue closed as "won't fix/not a bug" or equivalent if you try to report this to the editor's issue tracker).
I think the workaround in this case is to write some javascript to change the text on the attribute on the relevant script tags to "text/python" prior to calling Brython. i.e., instead of triggering Brython on your page with
<body onload="brython()" >
Do something along
<body onload="function (){var x = document.getElementsByName("python"); for(var i=0; i < x.length; x++){x.type="text/python"};brython()}()" >
(and of course, add the attribute name='python' to all your python script tags)
Related
I’m using the new TYPO3\CMS\Core\Mail\FluidEmail feature of TYPO3 v10.3 to send HTML system e-mails. Unfortunately, I’m experiencing a weird behavior with Viewhelpers in the e-mail Templates. Calling the regular Viewhelper notation like e.g. <f:uri.resource extensionName="backend" path="Images/typo3_orange.svg"/> works as expected. But inline notations of the same Viewhelper (like {f:uri.resource(extensionName: 'backend', path: 'Images/typo3_orange.svg')}) don’t get processed at all.
Surprisingly, when I call the regular notation first and the inline notation afterwards in the same template, both notations get resolved.
I also experienced that no fluid variables are accessible in the template, e.g. {normalizedParams}, which should be available when you set the request like $message->setRequest($GLOBALS['TYPO3_REQUEST']);
Did anyone experience a similar behavior and has a hint for me?
Here's my implementation in my Controller Action:
$message = GeneralUtility::makeInstance(FluidEmail::class);
$message
->to($email)
->format(FluidEmail::FORMAT_HTML)
->setTemplate('MyTemplate')
->assign('pages', $pages);
if ($GLOBALS['TYPO3_REQUEST'] instanceof ServerRequestInterface) {
$message->setRequest($GLOBALS['TYPO3_REQUEST']);
}
GeneralUtility::makeInstance(Mailer::class)->send($message);
Reference: https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/10.3/Feature-90266-Fluid-basedTemplatedEmails.html
Sounds like a fluid parsing problem. Do you have any { or } flying around in your template that could mess up fluids parsing?
Just run into the same problem with one of my in-house plugins after switching from php7.2 to php7.4 (when switching back to php7.2 the resource path was resolved again correctly).
It turned out that some inline javascript using curly brackets further down the page was to blame (thank you Daniel). Putting it in a separate file solved the issue. It would appear that the use of inline JS is tolerated to different degrees depending on the php version being used.
First, here is the Typoscript :
20 = TEXT
20 {
value {
field = field_title
wrap = |.txt
}
filelink {
stdWrap.wrap = <li>|</li>
path = fileadmin/txt-files/
}
}
The result I get is :
<li>
<a href="/fileadmin/txt-files/Title.txt">
<img src="typo3/sysext/frontend/Resources/Public/Icons/FileIcons/txt.png">
</a>
</li>
And what I need is :
<li>
<a href="/fileadmin/force_download_script.php?filepath=/fileadmin/txt-files/Title.txt">
<img src="typo3/sysext/frontend/Resources/Public/Icons/FileIcons/txt.png">
</a>
</li>
I need to make the link downloadable, rather than opening the file in the browser. For that I have a force_download_script.php, but when I do that :
wrap = fileadmin/force_download_script.php?filepath=|txt
instead of the current wrap, filelink doesn't find the file anymore.
I have tried using ATagBeforeWrap.wrap but it doesn't look like it's made for that purpose. I also tried typolinkConfiguration.wrap without any success.
Any idea of how to achieve that ? Using a COA maybe ?
Thank you !
I would not do this with a script, but with server configuration. If you use Apache and have .htaccess enabled, you can add the configuration to a .htaccess file in the directory where the files are located. See https://css-tricks.com/snippets/htaccess/force-files-to-download-not-open-in-browser/
Alternatively you can also use the HTML5 download attribute. This is not supported by Internet Explorer however (it is supported by Edge though).
The issue can get quite a bit complicated, but step by step:
your code above might be wrong if it's not just a copy & paste fault:
wrap = fileadmin/force_download_script.php?filepath=|.txt
The dot before txt was missing.
Nevertheless it is still interesting if the php-script is triggered.
It's possible that the script is not triggered due to some settings in typo3conf/LocalConfiguration.php respectively some settings in the install-tool.
Depending on the TYPO3-Version it's also possible that the script is not triggered at all because all scripts are being required now in an extension. That means you might need to create an extension for that script.
Also simple wrapping of the result with the script-path might not be enough, but you have to call it explicitly by TypoScript perhaps by including the script as user-function or lib.
The admin-panel might be useful to debug some things about your script but if not you've to include some debug-output first in your own code, if that's not enough in the core (temporary).
So you've to find out if your script is triggered and if not, the reason for it.
Are you sure .filelink is what you are looking for?
.filelink is for a set of files. For all files in the folder given by .path a link will be generated. see manual
From your description you want a text wrapped with a link to one single file. That would be more a problem for .typolink where you specify the link in .parameter.
if you really want a link list of multiple files, each wrapped with your script you need to modify .typolinkConfiguration.parameter which will be used internaly by .filelink.
Anyway it might be possible to do a wrap which then would be:
.typolinkConfiguration.parameter.wrap = /fileadmin/force_download_script.php?|
Maybe it is easier to build your list with .stdWrap.filelist, where you can use the filenames in any way to wrap your own href parameter for an A-tag.
To use the TYPO3 core solution with file links you can use this guide:
Create a file storage where you want your "secured" files in TYPO3 backend
Do not set the checkbox "Is public?" in the storage record
The links will be rendered with eID and file parameters
You can look into the FileDumpController handling these links: https://github.com/TYPO3/TYPO3.CMS/blob/2348992f8e3045610636666af096911436fa1c89/typo3/sysext/core/Classes/Controller/FileDumpController.php
You can use the included hook to extend this controller with your logic.
Unfortunately I can't find any official documentation for this feature, but will post it when I find something or wrote it myself. ;)
Maybe this can help you, too: https://extensions.typo3.org/extension/fal_securedownload/
Here is the official part, but it's not much: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Fal/Administration/Storages.html?highlight=filedumpcontroller
I really like how Visual Studio html editor updates the matching tag. Example:
<h2>Header</h2>
If we replace <h2> opening tag with <h3>, then the closing tag should change automatically to </h3>. This should happen as we type.
I'm trying to implement this on my own, but no luck so far. I thought that matchtags addon would be a good starting point, but it stops working if tag names do not match.
Also, I noticed that xml mode marks closing tag as error on tag name mismatch, but I'm not sure how to use this to update the closing tags.
I would appreciate any help from more experienced CodeMirror users.
Thanks
So once the edit has been done, you no longer have the information needed to find the matching tag (which is why the matchtag addon can't help anymore). A good solution might be to track the current matching tag when editing starts (when the cursor is in a tag name) by using the CodeMirror.findMatchingTag function exported by the addon/fold/xml-fold.js file. Then, on "change" events that look like local editing inside the tag name (i.e. their start and end are inside the tag name), immediately follow up by modifying the matching tag.
add matchtags.js, xml-fold.js
config : matchTags: {bothTags: true}
I found in typo3 admin side(/typo3), you can have two ways to set up TS,
you can set up through template->root, I think TS here will affect the whole site.
you can set up through template->certain page, it will only affect this page.
So my question is:
If I want to find where(which page) has TS setting such as : code = LIST, how could I do?
Use Web > Template module it has tools, you can for an example use Template Analyzer for the search
Try querying the database in phpMyAdmin or similar. The following looks in Template Setup:
SELECT pid, config, constants
FROM sys_template
WHERE config LIKE '%code = LIST%'
Replace config with constants to look in Template Constants. pid is the page ID.
If it is not set in the TypoScript, it perhaps has been set in the plugin itself. Just check the plugin content element itself.
In the Template module, go to the page where the setting is in effect.
Use the TSOB (Typo Script Object Browser) to search for "list":
This must show you all TS for this page that contains "list".
If you don't see the setting you can run a cmd/ctrl-F Search over the entire results.
You would have to search for "[code] = LIST".
Which will lead you to the following entry:
Hovering over the label will produce the above tooltip. Copy the line number.
Now change to the Template Analyzer. Here, you can click through all cascading templates and search for the line number:
This is definitely the line that sets that value.
From the "Template hierarchy" tree you will easily find the template that contains the setting.
I'm using a transmorgrifier recipe to import some data from drupal into a Plone 4.1 based buildout. The buildout is based on https://github.com/claytron/drupal-plone-transmogrifier, (mostly I updated it to use plone 4.1 instead of 4.0). The import works, I successfully imported data from a drupal site into my plone site. The only issue is that the html tags from the imported html show as the literal tags.
If, after the successful import, I manually go to each item and select 'edit' then click 'save' then the html is interpreted properly, but that would be a lot of editing and saving in order to fix my problem.
see screenshot of freshly imported content with html tags showing.
The blueprint doing the actual import of the field is (I believe) the one shown below:
[text_mimetype]
blueprint = collective.transmogrifier.sections.inserter
key = string:_text_mimetype
value = string:text/html
I experimented with using text/structured instead of text/html in the blueprint but that gave the same result:
What I need is either an additional blueprint that causes the html to be interpreted or a hints on how to ensure that my html gets interpreted at import.
The full list of blueprints used in my pipeline are shown here:
https://github.com/claytron/drupal-plone-transmogrifier/blob/master/src/my.migration/my/migration/config/base.cfg
Ran into the same problem when migrating content using wsapi4plone.core.
Solution: Pin zope.contenttype to version 3.5.5 (the default in the upcoming 4.1.1)
Cause: PLIP #9938 - http://dev.plone.org/plone/ticket/9938 as per esteele.
If it works under Plone 4.0 but not under Plone 4.1, then I'm guessing it has to do with the "factor custom output transformations out of the editors" PLIP that was merged as a part of the Plone 4.1. I would look into the changes from that PLIP and see how the pipeline needs to be adjusted.
Actually that section only insert a value "text/html" in the key "_text_mimetype"
The real encapsulation is done here:
[mimetype_encapsulator]
data-key = text
mimetype = python:item.get('_%s_mimetype' % key)
# replace the data in-place
field = key
condition = mimetype
more info: http://pypi.python.org/pypi/plone.app.transmogrifier#mime-encapsulator-section
Anyway i've experimented that it's not strictly mandatory to encapsulate the html text, it works also with a simple string.
Bye, Giacomo