I use the tt_news extension in TYPO3. I have updated the extension from 2.5 to 3.2.1. After the update, my pages which were using AMENU and ###TEMPLATE_ARCHIVE### are not working.
This is error I get in the FE:
My content folder for archived items is well configured (http://clip2net.com/s/28oYA), as well as TS constant:
plugin.tt_news.archiveTypoLink.parameter = 104
What might be wrong here?
Related
I just upgraded a TYPO3 extension with cal and had an exception. This was resolved by changing the constant:
plugin.tx_cal_controller.view.list.listTemplate =
FILE:EXT:somextkey/somepath/list.tmpl
to
plugin.tx_cal_controller.view.list.listTemplate =
EXT:someextkey/somepath/list.tmpl
While the latter is how it is documented in the cal docs and should have been used in the first place, this is an easy mistake to make, because often FILE:EXT is actually used to reference files. I don't know why this worked in TYPO3 8 and not in TYPO3 9.
The part that broke was
$absPath = $GLOBALS['TSFE']->tmpl->getFileName($path);
with $path being the path as defined by the constant.
Also, on this page TypoScript Syntax: Includes both variants are used:
and
Is there an easy to remember rule what is to be used when, is the variant "FILE:EXT" deprecated?
FILE:EXT: is only for inclusion because there we have also DIR:EXT:. For templates you always need EXT:. The only other exception is with languages: LLL:EXT:. It is like this since TYPO3 3.x.
We are using TYPO3 8.7.19 with the extension frontend_editing (Version: 1.4.0) and CoolURI. We still use css_styled_content.
When editing a content element in the frontend with the „frontent-editing bar”, e.g. text I get an error, but only, if it contains an internal link.
The changes are not saved. It crash with:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1460629247: No valid handlers found for type: unknown | TYPO3\CMS\Core\LinkHandling\Exception\UnknownLinkHandlerException thrown in file /usr/share/typo3/typo3_src-8.7.19/typo3/sysext/core/Classes/LinkHandling/LinkService.php in line 163. Requested URL: https://www.mysite.de/typo3/index.php?ajaxID=%2Fajax%2Ffrontend-editing%2Fprocess&ajaxToken=--AnonymizedToken--&page=123
There is a bug report and a suggested solution für TYPO3 9.5.x and a solution for TYPO3 8.7.x
Unfortunately, I don't know how to realize that solution for my system, cause
wee use coolURI but not the required realurl-xtension.
I don't know where to add the suggested code
Any hints for me?
Problem has been solved by the author of frontend_editing:
Add in typo3conf/ext/frontend_editing/Configuration/TypoScript/setup.ts
# Prevent links from being parsed to FE url
lib.parseFunc_RTE.tags.a >
I have case sensitive problems in TYPO3 v 8.7 LTS. System is sometimes mocking that a file is missing. The error message is
Oops, an error occurred!
File /archiv/ABCD.pdf does not exist.
Allthough the file is there. When I put the file in lowercase to fileadmin "abcd.pdf" than FAL isn't mocking around. But seems after a while it still is mocking.
At least I am not understanding where the problem lies. Because even if ABCD.pdf is there and in the right place I get warnings.
I checked DB integrity several times. But still no luck. Afterwards delete the cache in INSTALL TOOL.
I found DB tables where files are stored. Is there a way, that I manually can update this tables and get rid of these error message?
Make sure the checkbox "case sensitive" on the storage is equal to your file system.
Run the FAL index update scheduler task.
That should align the DB values again
I've updated my TYPO3 website from 4.1 to 6.2.9. Now the Umlauted Characters [German Letters] are not shown properly. Is there any Idea to fix that.
I experienced similar troubles when upgrading from 4.1 to 4.2. The following paragraphs are notes from my blog. Hope it helps.
Updating from TYPO3 4.1 (and earlier versions) to 4.2 (and later)
Some DB fields in 4.1 are of type BLOB (for example the TS templates). Most of these fields get converted to TEXT in 4.2. Now think about the following scenario, which seems to be common. The template was saved using TYPO3 4.1 and a DB using latin1 (ISO-8859-X) as charset. Then the DB converted to UTF-8 and TYPO3 was configured accordingly. You think you're finished because everything works will. But in most cases, there's still some latin1 formatted data in the BLOB fields. You just don't see. Once you upgrade TYPO3 to 4.2, these BLOBs get converted to TEXT, assuming the data is UTF-8. But it's latin1, because BLOB was not converted before. The result is a broken template. Lots of people in the mailing lists complain about whole parts missing. The reason is invalid non ascii characters (like umlauts äöüé¢ etc), which break the template view.
How to avoid that?
If you change the charset of TYPO3 and/or your DB, convert those BLOB fields which would have been changed by the TYPO3 update to TEXT before converting the charset or make sure to convert the BLOB data otherwise.
More about UTF-8 and older versions of TYPO3: https://stmllr.net/blog/thinking-about-utf-8-character-set-conversion-in-typo3/ Creative Commons License CC BY-SA 3.0
Hi all I'm trying to upload a image when creating a item in my app, however the action fails returning the following error: The mimetype of file 'mytestimage.jpg' could not be detected.
I've tried adding a Mime Type validator but the error persists, can anyone tell me where I'm going wrong in the code below.
// Image uploads
$images = new Zend_Form_Element_File('images');
$images->setMultiFile(2)
->addValidator('IsImage')
->addValidator('Size',false,'5242880')
->addValidator('Extension',false,'jpg,png,gif')
->addValidator('ImageSize',false,array(
'minwidth' => 250,
'minheight'=>250,
'maxwidth'=>500,
'maxheight'=>500
))
->setValueDisabled(true);
Many thanks in advance.
Graham
I had the same problem.
Zend_Frameworks tries to determine the mimetype in two ways:
First it tries to use the PECL FILEINFO-Extension (which is not installed on every server)
if the extension is not istalled it tries to use mime_content_type (a php function). This function however is deprecated as of php version 5.3
So in this case I guess your hoster is using php version 5.3 and has not installed the PECL FILEINFO-Extension. Same goes unfortunately for my hoster :(
Here are more details of the two ways in the php-manual:
http://de.php.net/manual/en/function.mime-content-type.php
http://de.php.net/manual/en/ref.fileinfo.php
By the way. You can see the code ZF uses in the file "Zend\File\Transfer\Adapter\Http.php" (lines 1281-1318: methodname is _detectMimeType