Eigenes Feld in OXARTICLES wieder entfernt - alle URLs zeigen nur noch auf Startseite

Folgendes Verhalten bei einem Oxid V. 4.41: in der OXARTICLES habe ich ein eigenes Feld angelegt. Dies wird nicht mehr benötigt. Sobald ich es in der DB lösche, läuft der Shop nicht mehr - alle Artikel-URLs werden auf die Startseite umgelenkt.
Das Feld hat keine Funktion mehr für den Shop. Ich habe es bei allen Datensätzen geleert, keine Probleme. Sobald ich jedoch das Feld an sich lösche, tritt oben genanntes Verhalten auf. Stehe vor einem Rätsel!

Hast du das tmp-Verzeichnis geleert? Da werden nämlich die Feldnamen gecached.

Thx - das war es! Tmp leere ich eigentlich nach (fast) jeder Änderung, aber dss auch die Feldnamen zwischngespeichert werden entzog sich meiner Kenntnis!

[QUOTE=alexz hh;45407]Thx - das war es! Tmp leere ich eigentlich nach (fast) jeder Änderung, aber dss auch die Feldnamen zwischngespeichert werden entzog sich meiner Kenntnis![/QUOTE]

ja, gibt doch immer noch genug Anwendungsfälle für dieses kleine Modul.

[QUOTE=zottle;45433]ja, gibt doch immer noch genug Anwendungsfälle für dieses kleine Modul.[/QUOTE]

Hier ging es aber nicht um ein Modul, da dass von dir erwähnt Modul für 30€ den Fehler auch nicht erkannt hätte.

Wenn du schon ungeschickt Eigenwerbung machst will ich, ganz im Sinne der Community, auf die in meinen Augen bessere und kostenfreie Alternative von D3 aufmerksam machen.
Beide Module machen aber m.E. nichts anderes, als das man den tmp-Ordner bequem aus dem Admin heraus löschen/leeren kann.

http://www.oxidmodule.com/OXID-Community-4/TMP-leeren.html

CYA

[QUOTE=Firefax;45437]Hier ging es aber nicht um ein Modul,[/QUOTE]
Wäre dieses (oder das von D3) im Besitz, wäre wohl auch die Existenz des Datenbankcache klar gewesen.

[QUOTE=Firefax;45437] da dass von dir erwähnt Modul für 30€ den Fehler auch nicht erkannt hätte.[/QUOTE] Sonst noch was?

[QUOTE=Firefax;45437]Wenn du schon ungeschickt Eigenwerbung machst[/QUOTE]
Nun übertreib mal nicht. Das tust Du doch mit deinem Spielzeugladen schon ewig.

[QUOTE=Firefax;45437] will ich, ganz im Sinne der Community, auf die in meinen Augen bessere und kostenfreie Alternative von D3 aufmerksam machen.[/QUOTE]
Das ist völlig legitim. Ohne es selbst genutzt zu haben, ist es allem Anschein nach sogar funktionaler, da man wohl noch differenzierter auswählen kann. Wer also ohnehin noch Module von D3 einzusetzen plant (Das TMP-Leeren Modul ist hier Bestandteil des Modul-Connectors), dem kann man ernsthaft nichts anderes empfehlen.

[QUOTE=Firefax;45437]
Beide Module machen aber m.E. nichts anderes, als das man den tmp-Ordner bequem aus dem Admin heraus löschen/leeren kann.

http://www.oxidmodule.com/OXID-Community-4/TMP-leeren.html

CYA[/QUOTE]
Korrekt erfasst.

Viele Grüße

na hier kann man ja mal sagen “was ein glück wenn man ne ee hat” :wink:
ich log mich einfach aus admin aus und tmp ist geleert - wobei es sicher via ftp aber immer noch gründlicher ist.

Au Backe eh - hier ist noch eins:
http://www.oxid-esales.com/en/exchange/extensions/delete-tmp

Wäre gut, wenn die Module von zottle und d3 noch in den exchange oder in die projects reingehen würden.

Gruß

Was nützt mir ein Modul von D3, das nach der Installation weitere Downlaods verlangt und so einfach nicht funktioniert? Jetzt muss ich mir die Mühe machen, diesen (sorry) Kram wieder manuell zu löschen. Einfach aus Prinzip, eine Software ist eine Software, die OHNE weitere Software funktioniert!

mfG

Michael

Der benötigte Zend-Optimizer sollte mittlerweile eigentlich Standard bei einem ernstzunehmenden Hoster sein - oder zumindest auf Verlangen des Kunden als Service integriert werden.

ABER: Zend Optimizer für PHP 5.3 erscheint jetzt, ein Jahr nach PHP 5.3, und dann ist der Decoder (der jetzt Zend Guard heißt), nicht mal kompatibel zum bisherigen Format. Außerdem ist der Decoder (AFAIK in allen Versionen) nicht kompatibel mit xdebug. Siehe auch: http://www.marco-steinhaeuser.de/oxid-eshop-and-php-zend-guard.html

[QUOTE=leofonic;45532]ABER: Zend Optimizer für PHP 5.3 erscheint jetzt, ein Jahr nach PHP 5.3, und dann ist der Decoder (der jetzt Zend Guard heißt), nicht mal kompatibel zum bisherigen Format. Außerdem ist der Decoder (AFAIK in allen Versionen) nicht kompatibel mit xdebug. Siehe auch: http://www.marco-steinhaeuser.de/oxid-eshop-and-php-zend-guard.html[/QUOTE]
Encoding stinks! :mad:

[QUOTE=laramarco;45476]na hier kann man ja mal sagen “was ein glück wenn man ne ee hat” :wink:
ich log mich einfach aus admin aus und tmp ist geleert - wobei es sicher via ftp aber immer noch gründlicher ist.[/QUOTE]
Also das macht ja nun überhaupt keinen Sinn…

“tmp” ist ja das Cache-Verzeichnis für alles Mögliche, was sonst jedes mal neu erstellt werden müsste.

Templates, Datenstrukturen, Sprachdateien usw.

[QUOTE=modellzentrum;45502]Einfach aus Prinzip, eine Software ist eine Software, die OHNE weitere Software funktioniert![/QUOTE]

Falsch! Wenn du eine .net-Applikation installierst, ist das .net-Framework auch Voraussetzung.

[QUOTE=laramarco;45476]na hier kann man ja mal sagen “was ein glück wenn man ne ee hat” :wink:
ich log mich einfach aus admin aus und tmp ist geleert - wobei es sicher via ftp aber immer noch gründlicher ist.[/QUOTE]

Ist das ein Feature oder ein Bug?

So oft, wie wir uns in den Admin ein- und ausloggen, würden zigmal am Tag die Dateien neu gecached. Da kommt es, auch bei einem guten Server, zu Zeitverzögerungen.

Stimmt, deshalb mache ich das auch nicht :wink:

mfG

Michael