Re: [TYPO3-german] mm_forum

[Stephan Kleiber]

Hallo Peter,

mit der waybackmachine findest du das zip:
http://web.archive.org/web/*/http://typo3-browser-forum.de/mm_forum_1.11.zip

Klick auf 9.März 2016 ... da war es noch verfügbar und wurde zum letzten
Mal indiziert.

Der Download schaut auf den ersten Blick o.k. aus, aber bitte selbst
noch prüfen.

Viele Grüße
Stephan



Am 09.06.2016 um 09:27 schrieb Peter Linzenkirchner:
> Hallo Peter, 
> 
> danke für den Link!
> Ich kannte ich den allerdings schon. Leider gibt es keine Migration von 
> mm_forum auf typo3_forum, deshalb ist das leider im Augenblick keine 
> Alternative. 
> 
> Meine Frage bleibt also bestehen: hat noch jemand diese Version? 
> 
> Viele Grüße
> Peter Linzenkirchner 
> 
> 
> 
> 
>> Am 09.06.2016 um 01:08 schrieb Peter Reinboth :
>>
>> Hallo  Peter Linzenkirchner & TYPO3-German-NG,
>>
>> am Mittwoch, 8. Juni 2016 schrieb Peter Linzenkirchner:
>>
>>> eine Zeitlang gab es eine einigermaßen lauffähige Version von
>>> mm_forum für TYPO3 6.2. Hier ist auch noch der LInk: 
>>> https://die-netzmacher.de/titel/mm-forum-fuer-typo3-62/
>>> Leider ist der Link broken … hat jemand noch diese Version, oder
>>> hat evtl. einen neueren Link?
>>
>> https://www.mittwald.de/blog/cms/typo3-cms/kompatibel-mit-typo3-6-2-und-7-x-aus-mm_forum-wird-typo3_forum
>> -- 
>> Grüße aus Berlin
>> Peter Reinboth
>>
>>
>>
>>
>>
>>
>>
>> ___
>> TYPO3-german mailing list
>> TYPO3-german@lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
> 
> --
> Xing: http://www.xing.com/profile/Peter_Linzenkirchner
> Web: http://www.typo3-lisardo.de
> Facebook: http://tinyurl.com/lisardo-multimedia
> 
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Konflikt mit baseUrl ?!

[Stephan Kleiber]

Hallo Steffen,

schau doch mal bei deinem Benutzer nach, ob der evtl. eine
Benutzergruppe zugewiesen hat, wo der Seitenbaum enthalten ist. Evtl.
siehst du den einen Seitenbaum als Admin, den anderen wegen der
Benutzergruppe.

Viele Grüße
Stephan


Am 26.05.2016 um 17:18 schrieb Steffen Liebig:
> Hi Philipp,
> 
> das hat jede "gleiche" Unterseite auch dieselbe ID. Ich hab jetzt ijn
> den Settings "reset configuration and clear temporary data" ausprobiert,
> das hatte keinen Erfolg. Was Anderes zum Thema Cache findet sich nicht.
> 
> Cu, Steffen
> 
> Am 26.05.2016 um 16:54 schrieb Philipp Gampe:
>> Hi Steffen Liebig,
>>
>> Steffen Liebig wrote:
>>
>>> Jetzt frage ich mich noch, wieso mir der Seitenbaum plötzlich (unterhalb
>>> Seite 0) plötzlich doppelt angezeigt wird und wie sich das beheben
>>> lässt.
>> Wenn die Seitenbäume unterschiedliche UIDs haben, dann wurden die Seiten
>> kopiert. Lösche dann einfach eine der beiden Kopien.
>>
>> Ansonsten (bei gleichen UIDs) musst du deinen User Cache löschen (User
>> Settings).
>>
>> Grüße
> 
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Internal error (500) nach Update auf Update auf 7.6.1

[Stephan Kleiber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hallo Gunter,

ein paar Tipps zu 1und1:
- - 1und1 führt manchmal Updates durch und überschreibt z.B. eine
angepasste .htaccess ... Problem hatte ich schon mehrfach bei
Kunden-Instanzen mit WordPress, wo plötzlich nichts mehr ging
- - 1und1 führt alte Verträge zu alten / ursprünglichen Bedingungen
weiter ... was man dabei wissen muss: wenn ein Vertrag z.b. 10 Jahre
alt ist und damals mit einem PHP memory_limit von 32 MB geschlossen
wurde, dann wird das Limit beibehalten, bis der Kunde sich meldet.
- - sämtliche Anzeigen des 1und1 PHP memory_limit (im 1und1
Kundenbackend; phpinfo, Shell) sind mit Vorsicht zu genießen. Dein
faktisches / reales / maximales 1und1 PHP memory_limit entspricht dem
Limit, was in deinem ursprünglichen Vertrag serverseitig eingetragen
wurde. Anpassungen im Kundenbackend oder mit php.ini / .htaccess
ERSCHEINEN zwar als gesetzte Werte, greifen aber definitiv nicht
(falls höher als z.B. ein historisch bedingtes 32 MB-Limit).

Oft ist es einfach nötig, direkt beim Kundensupport anzurufen und nach
dem memory_limit zu fragen. Eine Erhöhung (bei älteren Verträgen) ist
i.d.R. nicht möglich, aber es gibt oftmals aktuellere Angebote, die
teils deutlich mehr und preislich gleich sind.

1und1 produziert hier ganz viel sinnlosen Debugging- / Arbeitsaufwand.
Als Dienstleister sollte man beim ersten memory_limit Fehler sofort
Kontakt mit 1und1 aufnehmen und ggfs. ältere Verträge aktualisieren.

Viele Grüße
Stephan


Am 20.12.2015 um 13:39 schrieb Gunter Königsmann:
> Hallo, allerseits,
> 
> Seit ich mich überreden lassen habe, meine Homepage auf Typo3 
> umzustellen, haben  erst 4 Sicherheits-Updates nicht einen 500 
> (Internal Server Error) resultiert.
> 
> Bisher habe ich immer gewartet, bis irgendjemand herausgefunden
> hat, woran das liegt (Extensions hab' ich nur noch sehr wenige
> installiert, da die Updates eh nie überleben). Aber dieses Mal
> würde ich gerne eine der Seiten ändern.
> 
> Was ich über mein System sagen kann, ist: - 1&1 Dual Hosting (Ich
> vermute, das ist ein Teil des Problems. Aber - 1&1 war relativ
> günstig, wenn man mehrere URLs haben will) - PHP 4.4.9 (cgi-fcgi)
> (built: Dec 16 2015 14:02:44) - Zend Engine v1.3.0, Copyright (c)
> 1998-2004 Zend Technologies
> 
> und sowohl das Install-Tool, als auch das normale Backend
> liefern den 500-Fehler.
> 
> An Logs bekomme ich nur das folgende aus meinem System heraus:
> 
> 20-12-15 05:34 - cms: $TSFE->set_no_cache() was triggered. Reason: 
> no_cache has been set before the page was generated - safety
> check. Caching is disabled! 20-12-15 05:37 - cms:
> $TSFE->set_no_cache() was triggered. Reason: Another process wrote
> into the cache since the beginning of the render process. Caching
> is disabled! 20-12-15 05:37 - cms: $TSFE->set_no_cache() was
> triggered. Reason: no_cache has been set before the page was
> generated - safety check. Caching is disabled!
> 
> 
> Wie debuggt man so etwas?
> 
> Vielen Dank, und Gruß,
> 
> Gunter.
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWduH+AAoJELJbu9NEgXKKKl0QAOLuU9/72pOP0RtIEcKrHvgp
ndFRvMMZXmZsZ35S2ZgKdk2zw/fjlo654vuawK1/+wDF6zAei11poqnV1xw1Tlkp
e0q+6r1nEWUGpS/6oZhf3EnXJUZZKHXQ6vBUUt1aRaL23sdzotGWaVT/kvRI+e73
BCIi5FvkJRgYDkt0ZSzGqWylhsuOke3eXADyAfkc6rqrYLyUVBHmOEyH0nlVS9iO
d7mmueq4VpccellIAnLcYhU0gPluUqF7NlP9HQe+bsK93kv9hy/f8hzGQsgy1YqE
B4b5ItdEDGObVBCOzemnj0b+cXCRzlWzs+7ML8Mi7MU8d+QOLV6F5hfWjw5Y8KbG
IrFgS6UbLNcWUqqKmjDiP2VbRRV213YCjEHN/zTFT8RXhHbp0OAuTy2WvhF5SY8A
GKwzyWg+KmpN+fJFnHpW85HbYyXpR2VclNEEYo2R3tQeDV5+9Ze1JK4okwF1KJfg
h6nHwIoC6PZfwgGUDhBhrWXQYZXacA1k9i5g7J5Z7/zqwN7yE0SZfnnLiuvloB5h
ki11tUYPG62DsMWzbb705LcpS0n2scCq4bsQMDp/Gc6PgMiX9z596QAk6pGy/pQJ
bP1vjeOZv7PE39OoFhYI/YsYKBkkSqB0e6EKW3K46TEZU5kRUIe01/DoAXr+E0jF
55sItrPwC5oJvb33WPi0
=f/n6
-END PGP SIGNATURE-
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] PHP Exception nach Update auf 6.2.16

[Stephan Kleiber]

Hallo Peter,

für Mac gibts "fseventer" (läuft auch noch in 10.10)
http://www.macupdate.com/app/mac/19141/fseventer

Damit kannst du recht einfach sehen, welche Dateien auf dem System
gerade erstellt / gelöscht werden. Wenn der Cache also auf die
Festplatte schreibt, dann siehst du genau, wo das passiert.

Der fseventer ist auch nützlich um andere Programme besser zu verstehen.

Viele Grüße
Stephan

Am 17.12.2015 um 20:25 schrieb Peter Linzenkirchner:
> ja, das kenne ich und hatte ich probiert … deshalb habe ich das Problem hier 
> doch noch geschildert. Da muss es noch einen Cache geben, der nicht über das 
> Install-Tool gelöscht wird, sondern nur beim De- und Installieren von 
> Extensions. 
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Problem mit Klein- und Großschreibung beim Update von 4.5 auf 6.2.

[Stephan Kleiber]

Hallo Peter,

noch ein Hinweis zwecks cs-Backup: wenn eine zweite Partition verwendet 
wird mit "Mac OS Extended (Groß-/Kleinschreibung und Journaled)", dann 
sollte für das Backup natürlich auch eine entsprechende Partition 
verwendet werden.
Wie es mit TimeMachine geht, keine Ahnung - ich nutze Carbon Copy Cloner 
(bootbare HDD) und damit klappts einfach.


Viele Grüße
Stephan


Am 13.11.2015 um 07:32 schrieb Stephan Kleiber:

Hallo Peter,

du kannst das Problem lösen, indem du eine zweite Partition auf deinem
Mac erstellst und diese formatierst mit "Mac OS Extended
(Groß-/Kleinschreibung und Journaled)".
Dateien verschieben, Pfade anpassen und es sollte bereits funktionieren.

Netzwerkmounts leite ich auch auf die Case-Sensitive-Partititon.

Im PhpStorm kann man dann noch "idea.case.sensitive.fs=true" eintragen
in ~/Library/Preferences/WebIde100/idea.properties.

Viele Grüße
Stephan



Am 12.11.2015 um 12:23 schrieb Peter Linzenkirchner:

Hallo Liste,

ich habe hier gerade ein ziemliches Fiasko mit einem Update von 4.5
auf 6.2. Ich habe das Problem gefunden, und weiß wie man es vermeiden
kann, also brauche ich an sich keine Hilfe, sondern das hier ist eher
eine Warnung.

Ich habe das Update lokal durchgeführt, auf einer MAMP-Instanz unter
Mac OS X. Der Updater von TYPO3 stellt auf Systemen, die keine
Unterscheidung von Klein- und Großbuchstaben machen automatisch auf
„Schreibung ignorieren“ um. Beim Portieren der Dateien in FAL werden
dann alle Dateinamen in Kleinbuchstaben(!) in der Datenbank gespeichert.

Solange die Instanz auf dem Mac läuft, merkt man das Problem nicht, es
tritt aber natürlich auf, sobald man das Update auf den Server
portiert. Alle Dateien mit Großbuchstaben sind in FAL falsch
gespeichert und können nicht mehr dargestellt werden.

Das gleiche tritt natürlich auf, wenn man das Update unter Windows
durchführt. Und es ist in der Konstellation auch nicht vermeidbar.

Mein Fazi: Ein Core-Update von 4.5 auf 6.2 ist _nur_ und
_ausschließlich_ auf einem Rechner möglich, dessen Dateisystem
zwischen Klein- und Großschreibung unterscheidet. Wenn man lokal
arbeitet, muss man trotzdem das Core-Update nochmals auf dem Server
direkt durchführen; oder sich eine Entwicklungsumgebung anschaffen,
welche Klein- und Großschreibung unterscheidet.

—

So und jetzt schaue ich mal, wie Schadensbegrenzung machen kann.

Gruß
Peter

--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Problem mit Klein- und Großschreibung beim Update von 4.5 auf 6.2.

[Stephan Kleiber]

Hallo Peter,

du kannst das Problem lösen, indem du eine zweite Partition auf deinem 
Mac erstellst und diese formatierst mit "Mac OS Extended 
(Groß-/Kleinschreibung und Journaled)".

Dateien verschieben, Pfade anpassen und es sollte bereits funktionieren.

Netzwerkmounts leite ich auch auf die Case-Sensitive-Partititon.

Im PhpStorm kann man dann noch "idea.case.sensitive.fs=true" eintragen 
in ~/Library/Preferences/WebIde100/idea.properties.


Viele Grüße
Stephan



Am 12.11.2015 um 12:23 schrieb Peter Linzenkirchner:

Hallo Liste,

ich habe hier gerade ein ziemliches Fiasko mit einem Update von 4.5 auf 6.2. 
Ich habe das Problem gefunden, und weiß wie man es vermeiden kann, also brauche 
ich an sich keine Hilfe, sondern das hier ist eher eine Warnung.

Ich habe das Update lokal durchgeführt, auf einer MAMP-Instanz unter Mac OS X. 
Der Updater von TYPO3 stellt auf Systemen, die keine Unterscheidung von Klein- 
und Großbuchstaben machen automatisch auf „Schreibung ignorieren“ um. Beim 
Portieren der Dateien in FAL werden dann alle Dateinamen in Kleinbuchstaben(!) 
in der Datenbank gespeichert.

Solange die Instanz auf dem Mac läuft, merkt man das Problem nicht, es tritt 
aber natürlich auf, sobald man das Update auf den Server portiert. Alle Dateien 
mit Großbuchstaben sind in FAL falsch gespeichert und können nicht mehr 
dargestellt werden.

Das gleiche tritt natürlich auf, wenn man das Update unter Windows durchführt. 
Und es ist in der Konstellation auch nicht vermeidbar.

Mein Fazi: Ein Core-Update von 4.5 auf 6.2 ist _nur_ und _ausschließlich_ auf 
einem Rechner möglich, dessen Dateisystem zwischen Klein- und Großschreibung 
unterscheidet. Wenn man lokal arbeitet, muss man trotzdem das Core-Update 
nochmals auf dem Server direkt durchführen; oder sich eine Entwicklungsumgebung 
anschaffen, welche Klein- und Großschreibung unterscheidet.

—

So und jetzt schaue ich mal, wie Schadensbegrenzung machen kann.

Gruß
Peter

--
Xing: http://www.xing.com/profile/Peter_Linzenkirchner
Web: http://www.typo3-lisardo.de
Facebook: http://tinyurl.com/lisardo-multimedia


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Update auf 6.2.10 Fehler wegen trusted Pattern Check

[Stephan Kleiber]

Hallo Heike,

das Problem mit dem trustedHostsPattern tritt v.a. bei 1und1 auf.
Grund dafür ist scheinbar, dass bei 1und1 SERVER_NAME und HTTP_HOST 
anders behandelt werden als z.b. bei dF oder Strato.


Testen kannst du das bei 1und1 oder anderswo recht schnell hiermit (file 
erstellen servername_12345xyz ... halt mit kryptischer Endung damits 
nicht leicht findbar ist):


?php
// test  bei 1und1; Aufruf: 1) domain.de, 2) www.domain.de
echo 'SERVER_NAME: '.$_SERVER[SERVER_NAME];
// ergibt: 1) domain.de, 2) domain.de
echo 'br /br /HTTP_HOST: '.$_SERVER[HTTP_HOST];
// ergibt: 1) domain.de, 2) www.domain.de
?

Bei 1und1 ergeben sich hier unterschiedliche Werte, wenn die Domain mit 
www.domain.de aufgerufen wird.
Bei dF und Strato sind die Werte jeweils identisch und entsprechen der 
aufgerufenen URL - eben mal mit, mal ohne www.


Die schnelle und vmlt. recht unsichere Lösung hast du ja schon gefunden:
$TYPO3_CONF_VARS['SYS']['trustedHostsPattern'] = '.*';

Eine mögliche Lösung aus dem Shopware-Forum ist, SERVER_NAME=HTTP_HOST 
zu setzen.

http://forum.shopware.com/installation-einstieg-f9/installationsproblem-bei-1und1-auf-shared-server-t1345-10.html

also das hier
$_SERVER['SERVER_NAME'] = $_SERVER['HTTP_HOST'];

Vielleicht klappts ja damit, einfach mal testen.

Viele Grüße
Stephan


...







Am 11.03.2015 um 11:04 schrieb Heike Herzog-Kuhnke:

Hallo Bernd,

danke nochmal. Ich werde mal mit Dreamweaver auf den Server schauen.
Bisher habe ich das 11 Webinterface verwendet, weil ich nicht im Büro bin.

Mal sehen, was ich dann finde.
Sollte sich daraus nichts ergeben, werde ich die Sache an die Forge
weitergeben. Es irritiert mich schon sehr, dass es mit dieser Eintragung
klappt und mit der korrekten nicht.

Hast Du eine 6.2.10 auf einem normalen Server am Laufen, bei der Deine
Klammer-Lösung angenommen wird? Wie gesagt, auf der suche nach dem
Problem habe ich einige Seiten mit dem Tipp gefunden das Ganze einfach
zu deaktivieren.

Mit welchen Problemen muss man denn rechnen, wenn man es deaktiviert?
Hast Du da zufällig einen Link zu dem Thema?
Ich hab den Kunden jetzt shcon mal drauf hingewiesen, dass da aus
Sicherheitsgründen eine Einschränkung sein wird, aber es wäre mir
wohler, wenn ich bei einem Gespräch auch wüßte, welche Gefahren es gäbe,
wenn er sich für eine Deaktvierung entscheidet.

Da die Seite wahrscheinlich sehr bald online gehen wird, habe ich nicht
mehr so viele Chancen zu testen, was ich aber gerne machen werde.

Alles Liebe
Heike


Am 11.03.15 um 09:03 schrieb bernd wilke:

Am 11.03.15 um 07:41 schrieb Heike Herzog-Kuhnke:

Ich dachte heute morgen, ob es vielleicht mit meiner Datenbank
zusammenhängen würde, die ich ja erst gestern wirklich auf UTF-8
gestellt habe.


sehr unwahrscheinlich, insbesondere sind Klammern in allen Zeichensätzen
an der gleichen Stelle kodiert.


Aber das ist es nicht. der 11 Server will einfach keine Klammern
interpretieren. Nur mit der vorher genannten Konfiguration kann ich die
Seite mit com und de aufrufen. Alle anderen Varianten führen zu dem
Fehler. Kann das vielleicht mal jemand ausprobieren, ob das auch bei
anderen Servern funktioniert?


das wird wohl nicht speziell am 11-Server liegen.
ich würde jetzt eher einen Bug vermuten.
Du kannst ja mal ein Ticket in Forge anlegen.


Da ich im Web nur Lösungen gefunden hatte, die das Ganze komplett
deaktivieren und diese Variable ja nicht eingeführt wurde, weil die
Entwickler Spaß daran haben arme Admins zu ärgern, sondern weil sie Sinn
macht, wäre das unter Umständen eine Sache, die man verfolgen sollte.


die Einstellung gibt es wohl schon länger, sie ist jetzt nur mit einem
anderen (sehr restriktiven) Defautl versehen.


Ich bin froh, dass es jetzt geht, aber auch irritiert.
Mit den Domain Records bin ich irgendwie nciht weiter gekommen, weil ich
da ja aktiv nix mache. Ich leite im Admin bei 11 dann die Domain auf
die Seite um, das wird dann wohl ein Redirect auf Server-Seite werden.
Aber momentan ist der noch nciht eingerichtet, weil ich mit dem
Konfigurieren noch nciht fertig bin.


die Domainrecords sind eigentlich eine gute Sache, weil sie ein paar
Konfigurationen einfacher machen.
in den Domainrecords kann man zb. folgendes einrichten, was aber eher in
die .htaccess gehört:
Aufrufe mit domain.tld werden nach www.domain.tld weiter
gereicht. Sinnvoller ist da schon:
www.domain1.tld an www.domain2.tld weiterreichen. zb. wenn die
Website demnächst über eine neue Domain aufgerufen und gefunden werden
soll. Google mag gleichen Inhalt unter verschiedenen Domains gar nicht
so gern. da hilft es wenn man google sagt: du kannst zwar alle domains
für den Zugriff benutzen, aber offiziell ist es immer diese Domain.


Verzeichnisschutz ist keiner drin, das kann es auch nicht sein.

Die _.htaccess kann ich nciht umbenennen und die echte sehe ich nicht.


entweder ein anderes Tool, oder in den Einstellungen zu deinem Tool
nachgesehen. irgendwo kann man meist einstellen: auch versteckte
Dateien anzeigen.


bernd

Re: [TYPO3-german] EXT lorem_ipsum with PHP =5 .3; Lösung: 'ereg_replace' mit 'preg_re place' ersetzen in Datei 'class.tx_loremipsum_w iz.php'

[Stephan Kleiber]

Hallo Steffen,

danke für die Info. Beim nächsten Mal gibts dann nur einen Post auf der 
englischen Liste.


Ich hab jetzt einfach den Bug eingetragen und Kasper eine Mail 
geschrieben. Mal schauen, ob er Zeit findet und es ins SVN committen kann.


Viele Grüsse,
Stephan

Am 24.07.2010 20:01, schrieb Steffen Gebert:

Am 24.07.2010, 18:54 Uhr, schrieb Stephan Kleiber ty...@a24cms.com:

das ist mein erster Beitrag in der Mailingliste. Bisher war ich nur 
stiller Mitleser.

Hi Stephan,

bist auch als Schreiber willkommen ;-)

Falls jemand einen Tipp hat, ob ich in so einem Fall alternativ 
besser direkt an den Extension-Autor (in dem Fall Kasper) schreiben 
soll ... bin gerne offen für Vorschläge zum nächsten/richtigen 
Bug-Report.
Das mit Kaspers Extensions ist etwas schwierig. Keine Ahnung, ob er 
reagiert, wenn du ihn anschreibst. Aber versuch's doch mal!
Wenn nicht, frag ihn doch nach dem Extension Key, ob du die weiter 
maintainen darfst (wenn du kannst und möchtest).


Sei so gut und mach beim nächsten mal keine Crosspostings auf mehrere 
Listen! Nur auf die englische würde reichen, meiner Meinung nach.


Schönen Abend noch!
Steffen
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german


___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

[TYPO3-german] EXT lorem_ipsum with PHP =5 .3; Lösung: 'ereg_replace' mit 'preg_re place' ersetzen in Datei 'class.tx_loremipsum_w iz.php'

[Stephan Kleiber]

Hallo @all,

das ist mein erster Beitrag in der Mailingliste. Bisher war ich nur 
stiller Mitleser.

Ich hoffe, es ist o.k., einen Bugeintrag plus Lösung zu posten.
Zumindest habe ich bisher noch nix dazu gefunden auf der Liste oder bei 
Google.

Also hoffentlich ein nützlicher Beitrag für manche.

EXT lorem_ipsum with PHP =5.3

Wenn man 'lorem_ipsum' mit PHP =5.3 verwendet, dann gibts Fehler im 
Backend, sobald man ein neues content element (text) anlegt.


Der Fehler wird verursacht durch 'ereg_replace' in der Datei 
'class.tx_loremipsum_wiz.php', weil ereg_replace deprecated ist in 5.3.


Die Lösung ist, das 'ereg_replace' mit 'preg_replace' in der Datei 
'class.tx_loremipsum_wiz.php' zu ersetzen.

-- danach funktionierts wieder in 5.3
-- ebenso getestet mit 5.2.12 ... alles o.k.

Ich hoffe mal, das spart jemandem ein paar Minuten.

Ich hab dasselbe auch in den Mantis-Bugtracker eingegeben. Nachdem das 
mein erster Bug-Report ist und ich frisch angemeldet bin (also noch ohne 
weitere Rechte), gehe ich mal davon aus, dass es jemand anders ins SVN 
einspielen wird/muss.


Falls jemand einen Tipp hat, ob ich in so einem Fall alternativ besser 
direkt an den Extension-Autor (in dem Fall Kasper) schreiben soll ... 
bin gerne offen für Vorschläge zum nächsten/richtigen Bug-Report.


Viele Grüsse,
Stephan
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german