How can I overwrite the default settings of the TYPO3 extension realurl with my own extension?
this dont work:
// RealUrl Config File
if (!isset($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['realurl']['configFile'])
|| empty(trim($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['realurl']['configFile']))
) {
$GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['realurl']['configFile'] = 'typo3conf/ext/xxx/Resources/Private/Hooks/realurl_conf.php';
}
How can I use this?
Probably the problem is that realurl is inialized and executed very early (it's the first process which needs to translate the speaking url to url parameter which decide which page and which plugin is rendered).
Your attempt to modify the assignment which is done normaly in typo3conf/LocalConfiguration.php could not be attached to that file as it is just an array, which gets written anew automatically every now and then.
You might add that to typo3conf/AdditionalConfiguration.php.
But why don't you request an admin to assign the path to the config-file in your extension in the realurl EM-config by hand?
Related
I have some problems with realURL Cache. For example:
The URL to the "home"-page is /the-shoe/home. Translated to switzerland (german) the url is: /ch/der-schuh/home. The problem here is that the URL /ch/the-shoe/home also works.
My idea was, that this is a cache problem. Because the page got translated and the page got called before the title of the page got translated
So I tried to clean the cache with the backend-module "Speaking URLs". I Flush all entries in the URL Cache and deleted the paths für this page and language in the Path Cache.
But this did not change anything. I can still call /ch/der-schuh/home and /ch/the-shoe/home and both works. After calling both URLs I can also see them again in the URL Cache (but not in the Path Cache):
So why is this a problem
I do not want 2 URLs lead to the same content
Sometimes <f:link_page> and co. creates a Link with the "wrong" URL (not the translated one).
When I am logged in in the backend the "wrong" URL will not work!
Now my question is, where is this problem coming from? How can I solve it? It looks like just clearing the cache does not solve the problem.
ANy ideas?
This is a RealURL bug, which I actually had fixed once by patching RealURL (that was in RealURL v1 back then, but I'm sure you will figure out the line of code where it is now).
With this patch applied, it is NOT possible anymore to access a translated page with the original page title in it (which my project needed to avoid duplicate content & pages).
diff --git a/realurl/class.tx_realurl_advanced.php b/realurl/class.tx_realurl_advanced.php
index 5af10a6..2860eb1 100644
--- a/realurl/class.tx_realurl_advanced.php
+++ b/realurl/class.tx_realurl_advanced.php
## -1073,6 +1073,11 ## class tx_realurl_advanced {
// Process titles. Note that excluded segments are also searched
// otherwise they will never be found
$uidTrack[$row['uid']] = $row;
+ // If the page has a page translation, don't add the titles from the default language to the list
+ // of valid pages, the translation is processed below.
+ if ($this->pObj->getDetectedLanguage() > 0) {
+ continue;
+ }
foreach ($segTitleFieldArray as $fieldName) {
if ($row[$fieldName]) {
$encodedTitle = $this->encodeTitle($row[$fieldName]);
The issue is halffixed in realURL v2.0.14.
Best fix for now is to disable cache for realURL.
I am building an extension with extbase where I need to create a pdf file inside fileadmin folder with php from a controller :
fopen("/fileadmin/pdf/anass.pdf", "w") or die('could not create file');
The permission is granted to write files ... so I think I made a mistake writing the path. Could somebody please help me?
PS: I am working on typo3 4.5
Indeed you're specifying absolute path in the filesystem and most probably there's no such path like /fileadmin/pdf/... there.
Quite safe would be using some TYPO3 constant to specify where's your app's root i.e. PATH_site, like:
fopen(PATH_site . "/fileadmin/pdf/anass.pdf", "w") or die('could not create file');
it will use the path like (sample)
/var/www/your-app/fileadmin/pdf/anass.pdf
note, that if you should use slash before fileadmin or not is OS/server config depended, so just check if your PATH_site ends with slash or not.
I have an extension that access a file directory. I use an ajax function to send the path that needs to be access to the controller and in the controller I use a $_GET cause I haven't figure it out how to make it work otherwise.
$image_file_path = $_GET["url_region"];
$d = dir($image_file_path) or die("File not found!");
But of course when you request for something else like ../../.. you can access all other directories.
Could you suggest me a way to sanitize this? Please!
You should provide a cHash as URL parameter and let TYPO3 verify that. This way you can be sure the URL has been generated by TYPO3 itself and thus is valid.
You should consider using t3lib_div::_GET() which unescapes the parameters regardless what php.ini magic_quotes says.
You easily could use a regex to catch all "../" - values of the parameter. The other way could be, that the available paths being defined in a array, or something else, to check up the right access.
i am wondering what TS code is needed to set path to my own indexed search local_lang.
I changed what i needed in pi1/local_lang but i would like to set it to my own so i can have the edited (Croatian in this case) for future projects.
Something like:
plugin.tx_indexedsearch.templateFile = fileadmin/search_temp.html
but for Local_lang of it?
with this lines you can overwrite individual translations:
plugin.tx_myPlugin_pi1._LOCAL_LANG.de.key = value;
plugin.tx_myPlugin_pi1._LOCAL_LANG.en.key = value;
I think that not all extensions supports a complete own localLang file, but not 100% sure.
You could add your translation to the official Translation Server . So your translation will be available trough the Translation Modul in TYPO3 Backend.
The croation translation for indexed_search is managed there: http://translation.typo3.org/hr/TYPO3.TYPO3.core.indexed_search/
There is a single-sign-on with typo3.org implemented. So you need an account on typo3.org first.
I am using wamp on Win XP SP3 and creating a Joomla template with changeable parameters.
initially the message is
The parameter file \templates\ssc_2010\params.ini is
writable!
once I make changes everything works as expected, except now i get the message:
The parameter file \templates\ssc_2010\params.ini is
unwritable!
One solution is to brows to the directory, right click the file, select properties, and uncheck read-only. Again the file is writable but once I modify the parameters again it becomes read only again. I'm quite lazy and would like to prevent this from happening again, I've notice this happening in past projects, but now I have to work a lot with parameters so it becomes quite boring doing manual labor like that :P
There is a bug in Joomla 1.5 that causes the message to be displayed.
A security feature was added that makes the template files unwritable until just before save, where they are made writable, saved, then made unwritable again.
Try to make a change, then go back and check the preview. You will see that the change was actually made.
If you want to fix the annoying unwritable message, add the following code to
administrator/components/controller.php around line 179, just after setting the FTP credentials:
$file = $client->path.DS.'templates'.DS.$template.DS.'params.ini';
// Try to make the params file writeable
if (!$ftp['enabled'] && JPath::isOwner($file) && !JPath::setPermissions($file, '0755')) {
JError::raiseNotice('SOME_ERROR_CODE', JText::_('Could not make the template parameter file writable'));
}
This will make the file writable during the edit load process, and before the file's status is posted in the template.
Then for security, in case the edit screen is closed without saving, search for the following lines:
require_once (JPATH_COMPONENT.DS.'admin.templates.html.php');
TemplatesView::editTemplate($row, $lists, $params, $option, $client, $ftp, $template);
and paste the following code just AFTER these lines but before the closing brace:
// Try to make the params file unwriteable
if (!$ftp['enabled'] && JPath::isOwner($file) && !JPath::setPermissions($file, '0555')) {
JError::raiseNotice('SOME_ERROR_CODE', JText::_('Could not make the template parameter file unwritable'));
}
That will make the file unwritable again.
This is the same code that is used in the saveTemplate() function. We are just doing it again before we display the status of the file on the edit screen. If the process fails because of your web server's configuration, you will get warning messages, BEFORE you've made a bunch of changes to your template. :)
P.S. Remember to save a copy of this file separately, so that you can redo the changes when you upgrade Joomla! (if they haven't fixed this themselves yet.)
This sounds like a user rights problem within Windows - have a look a the security permissions for the directory in which the file you are editing is located, and check that the user "IUSR_xxx" (where xxx is the name of your computer) has full control.
If this doesn't work, then can you tell us what version of Windows you are running as this may help...
Matt