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
Related
When I export the xml file of a multiple choice question, it contains the following lines:
<idnumber>arbitrary_id_set_by_user</idnumber>
<answernumbering>ABCD</answernumbering>
<tag></tag>
Is there a way to add idnumber, answernumbering and tag to the metainformation section of the question so that r-exams can export to moodle XML as <idnumber>idnumber</idnumber>,<answernumbering>ABCD</answernumbering>, <tag>tag1</tag>, and <tag>tag2</tag> etc?
The <answernumbering> tag can be set in exams2moodle() via the answernumbering= argument, see ?exams2moodle. The reason for this is that this is set in the same way for all exercises in a quiz. This is more consistent than setting it individually and potentially inconsistently in the meta-information of the different exercises.
The <idnumber> tag appears to be used by Moodle only for internal purposes. It is also not mentioned in the official Moodle XML documentation at https://docs.moodle.org/311/en/Moodle_XML_format. Hence we did not implement it in exams2moodle().
The <tag> is currently not supported in exams2moodle() because we felt that it would be more important to have tags in the Rmd (or Rnw) exercise itself and not the Moodle version of the exercise. For structuring the content on the Moodle side the exsection meta-information can be used, see boxhist for a worked example.
Finally, you can add arbitrary metainformation by using the exextra tag. This is used, for example, in the essayreg exercise template. However, there is no general way of using this extra metainformation to insert additional XML code in the exams2moodle() output. To do that, the source code underlying exams2moodle() would have to be adapted correspondingly.
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.
In TYPO3 (7.2.0) using the standard template engine, is there a way to add a placeholder attribute to the standard mail form text input?
At the moment I am using JavaScript to convert the labels into placeholders, but I am open to suggestions on a better way to do this...
The suggested solution of #biesior does only work for EXT:form 7.4 and higher (see changelog). The supplied picture shows the form wizard of TYPO3 7.5 or 7.6. In 7.2 you won't find any placeholder attribute in the wizard.
I recommend updating to TYPO3 7.6 since this version includes a major rewrite of EXT:form. You will be able to use fluid templates to customize your forms. Furthermore HTML5 attributes are possible. Before the rewrite the set of allowed attributes was quite limited. Now you are able to add all attributes you can think of (for example "data-"). See changelog.
If you have any questions regarding EXT:form join the channel on Slack. If you don't know Slack yet, check out the invite function.
During form fields editing you have many properties, also Placeholder
in text version it will be:
10 = TEXTLINE
10 {
type = text
class = foo-class
id = foo-id
name = foo
placeholder = Hmmm?
required = required
label {
value = My Field
}
}
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)
Since updating from Flux 6.0.2 to the newest Flux TER-Release (7.0.0) I have the problem that all my defined flux:field.select items are switched. I have them defined as an array like this items="{0: {0: 'value shown as a CSS class in the frontend',1: 'value shown in BE'},}". But now I get the BE value in the frontend template.
Also all my content elements from my provider extension are shown twice (without a title) in the backend and the fields defined in the 'Configuration' section of my content element are shown twice.
There's also a RTE field shown at the bottom of my content element that has not been there before.
BE Output: view
Code on Pastebin: http://pastebin.com/CNcphn2k
Any help deeply appreciated.
EDIT:
I just set up a fresh instance of TYPO3 6.1.9 (blank package) and installed my extension with the above mentioned content elements. Dependencies were resolved automatically as it should (newest versions). Via the content wizard I tried to create a new element and I get the same result as in my existing install I first noticed this bug in.
EDIT2:
I was able to narrow it down to the flux:form.container tag. This duplicates the output in the BE. The select values are still switched though.
It is possible that you missed this official announcement:
http://fluidtypo3.org/blog/news/new-colpos-value.html
Failure to run the update script before letting TYPO3 change the type of the colPos value will result in the symptoms you describe. There is, unfortunately, no way to restore this (since your SQL will have cropped off all negative values and made them zero without any backup).
Restore from a backup and run the script and you should be fine.