Zum Inhalt springen

probleme mit realurl, tt_news und chash

Erstellt am 1. Juli 2005 · 6 Antworten · letzte Antwort am 4. Juli 2005

Tags: RealURL, tt_news, Frage

tom2 ·

hallo liebe t3-gemeinde,

ich suche nun schon seit stunden nach einer vernünftigen erklärung wieso das problem auftritt und wie man es effektiv beheben kann.

nachfolgend das problem:

realurl ist konfiguriert und läuft wie gewünscht. ebenso tt_news (wenn man die seite im browser neulädt). bei jedem ersten besuch einer seite mit tt_news bekomme ich eine fehlermeldung die wie folgt aussieht:

Error: Stored cHash and calculated did not match!
0	c388f27c7d
1	51c060544d
2	dateiname.html
3	155343803
Error: Stored cHash and calculated did not match!
0	8546593ad4
1	d1b7f5f446
2	andererdateiname.html
3	227948292

wie gesagt, lade ich die seite nun neu, sind die probleme für immer verschwunden - nehme an, die extension trägt dann die neuen hashes ein!? das geht dann solange gut, bis ich aktualisierungsbedingt, neue sachen anlege und / oder die caches leere.

es wurde sowohl unter t3 3.7 als auch 3.8 unter windows und linux getestet - realurl und tt_news jeweils in den aktuellsten versionen.

weiß jemand rat? :o

falls das hier oder woanders bereits erklärt und gelöst wurde, bitte ich bereits vorab um entschuldigung aber meine suchbegriffe haben für mich nichts brauchbares ergeben. 😢

tom2 ·

also eigentlich ist der chash gar nicht definiert, da ich den transparent übergeben lasse - da ich diesen chash nicht in der url haben wollte bzgl. seo.

ich hab' nachfolgend mal den code gepostet, hatte ich am anfang vergessen *sorry*:

<?php
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tstemplate.php']['linkData-PostProc'][] = 'EXT:realurl/class.tx_realurl.php:&tx_realurl->encodeSpURL';
$TYPO3_CONF_VARS['SC_OPTIONS']['tslib/class.tslib_fe.php']['checkAlternativeIdMethods-PostProc'][] = 'EXT:realurl/class.tx_realurl.php:&tx_realurl->decodeSpURL';

$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearAllCache_additionalTables']['tx_realurl_urldecodecache'] = 'tx_realurl_urldecodecache';
$TYPO3_CONF_VARS['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['clearAllCache_additionalTables']['tx_realurl_urlencodecache'] = 'tx_realurl_urlencodecache';

$TYPO3_CONF_VARS['FE']['addRootLineFields'].= ',tx_realurl_pathsegment';

$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array(
	'init' => array(
		'enableCHashCache' => 1,
		'enableUrlDecodeCache' => 1,
		'enableUrlEncodeCache' => 1,
		'appendMissingSlash' => 'ifNotFile',
	),
	
	'preVars' => array(
		array(
			'GETvar' => 'no_cache',
			'valueMap' => array(
				'no_cache' => 1,
			),
			'noMatch' => 'bypass',
		),
		
		array(
			'GETvar' => 'L',
			'valueMap' => array(
				'no' => '1',
			),
			'noMatch' => 'bypass',
		),
	),
	
	
	'fileName' => array (
		'index' => array(
			'backend.php' => array(
				'keyValues' => array (
					'type' => 100,
				)
			),
			
			'print' => array(                         
				'keyValues' => array(
					'type' => 98,
				)
			),
		),
		'defaultToHTMLsuffixOnPrev' => 1,
	),
	
	'fixedPostVars' => array(),
	
	'postVarSets' => array(
		'_DEFAULT' => array (
			'mitteilungen' => array(				
				array(
					'GETvar' => 'tx_ttnews[tt_news]',                    
					'lookUpTable' => array(
						'table' => 'tt_news',
						'id_field' => 'uid',
						'alias_field' => 'title',
						'addWhereClause' => ' AND NOT deleted',
						'useUniqueCache' => 1,
						'useUniqueCache_conf' => array(
							'strtolower' => 1,
							'spaceCharacter' => '-',
						),
					),
				),
				
				array(
					'GETvar' => 'tx_ttnews[backPid]',
					'lookUpTable' => array(
						'table' => 'tt_news',
						'id_field' => 'uid',
						'alias_field' => 'uid',
						'addWhereClause' => ' AND NOT deleted',
						'useUniqueCache' => 1,
						'useUniqueCache_conf' => array(
							'strtolower' => 1,
							'spaceCharacter' => ',',
						),
					),
					'noMatch' => 'bypass',
				),	
			
			),
		),
	),
	
	'pagePath' => array(
		'type' => 'user',
		'userFunc' => 'EXT:realurl/class.tx_realurl_advanced.php:&tx_realurl_advanced->main',
		'spaceCharacter' => '-',
		'languageGetVar' => 'L',
		'expireDays' => 3
	),
);
?>

soweit ich das verstanden habe, wird durch enableCHashCache, enableUrlDecodeCache, enableUrlEncodeCache das ganze so von typo3 bzw. der extension realisiert, dass der chash nicht mehr als solches in der url auftauchen muss bzw. auftaucht.

jenses ·

Error-prone setups
One might ask; When will a URL ever contain a blank cHash value since the combination of parameters and cHash is automatically created by TYPO3 anyway?
An obvious answer is when the enemy forges URLs on you website! It will be very easy for the enemy to tease you with this confusing bug. This alone should be motivation enough to fix the problem.
However a much more likely scenario is that it happens when using the “realurl” extension or some other extension manipulating the URL and its parameters:
With realurl the problem simply is that the value of “cHash” is not “speakable” under any circumstances and since the realurl extension is trying to translate parameter strings into something human readable the cHash value of URLs will typically be the only left-over that cannot be a part of the URL. The solution chosen for realurl is to store the cHash value in a table linked to the complete URL it was associated with. This works very well until something changes the values of the URL. In reality what happens is that when translating the URL back, realurl might
either retrieve a wrong cHash value from the database; no problem, caching will be disabled since cHash-strings didn't match.
or retrieve nothing; big problem, because parameters will be set but cHash empty!
This is the reason why “realurl” has sparked some fancy situations where the frontpage of the documentation library of TYPO3.org has been a particular page deep inside the documentation library instead of the frontend page - because something has resulted in no returned value from the cHash-table in realurl!

tom2 ·

hallo jenses,

da mein englisch nicht mehr das beste ist, hier kurz meine interpretation:

man sollte, um der gefahr von spielereien mit realurl aus dem weg zu gehen, die chashes mit übergeben. realurl versucht die chashes in einen speakable parameter zu münzen und das geht ja nicht. solange sich inhalte nicht ändern funktioniert es, da sich hier der in der realurl chashtabelle gespeicherte wert ja nicht ändert. man sollte wenn man mehr als nur den chash einer seite übergibt, den parameter lieber direkt mit übergeben.

ist diese interpretation soweit inhaltlich korrekt?

wenn ja, dann ist das schade, da es doch eigentlich machbar sein müsste bei einem cache leeren auch den cache von realurl zu löschen... aber dann kommt ja das problem wieder... hm, alles suboptimal. dann werde ich den chash doch mit übergeben auch wenn's nicht so toll aussieht.

vielen lieben dank für die info 🙂 darf ich fragen von wo sie stammt? bzw. wie du danach gesucht hast? :o

jenses ·

So in etwa ist deine Interpretation wohl richtig, es besteht eben die Gefahr, daß bei Änderungen der Seite der cHash neu berechnet wird und dann nicht mehr mit dem von RealUrl gespeicherten übereinstimmt.
Dann erscheint die Fehlermeldung aus deiner Ausgangsfrage.
Dann müßte man also regelmäßig die RealUrl - Caches löschen (speziell tx_realurl_chashcache),
nur wann ist regelmäßig ? #paralyzed#
Also läßt man den cHash-Parameter lieber als Url-Bestandteil bestehen und spart sich eine Menge Probleme.

Die Info stammt von hier : "Kennst du den Artikel : http://typo3.org/development/articles/the-mysteries-of-chash/ ?" (siehe oben)

Wer lesen kann, ... 😃

viele Grüße
jenses

tom2 ·

ach verdammt, da ging es weiter :o danke ... ich sollte wirklich lesen lernen. ok, dann werd ich doch den parameter schweren herzens mit übergeben... sieht dennoch doof aus #giggle#

vielen dank für die schnelle hilfe 🙂