Klar, es gibt bereits viele Ansätze, und ich habe die meisten auch ausprobiert, aber irgendwie nervte es oft, dass man bei Nutzung den aktuellen Kontext verlassen hat. Also habe ich es nach oben in den Admin-Header verfrachtet, der sich dann einfach selbst neu lädt, und eine kleine JS-Info bei Erfolg ausgibt.
Leider gehört die /out/admin/tpl/header.tpl ja quasi zum Core, aber die letzten Monate/Jahre haben gezeigt, dass die Datei bei Updates fast nie (ich glaube nur einmal) geändert wird, also finde ich den Weg ausnahmsweise vertretbar…
Weiterhin lungerte hier seit längerem ein Header-Link zum Öffnen des Frontends in einem neuen Fenster herum, der sich nahezu aufdrängte, mit ins Modul integriert zu werden.
Ein letzter Tipp an alle, die noch die Version 1.0.0 geladen haben:
Falls es mit OXID <= 4.5.1 passiert, dass man bei Nutzung ausgeloggt wird, dann bitte die Version 1.0.1 laden, die ist korrekt abwärtskompatibel bis mind. 4.3.0!
Bidde schön, gern geschehen!
Ich weiß selbst gar nicht, wie ich anfangs noch ohne diese beiden Buttons auskommen konnte, die fehlen in OXID einfach…
Ich wollte es zuerst noch komplizierter machen mit <select> nach bestimmten Temp-Arten (gab es ja auch schon mal), aber letztlich ist der Cache in den meisten (nicht allzu großen) Shops so schnell wieder komplett neu erstellt, dass sich der Aufwand bisher nicht lohnt, zumindest für mich.
wir haben das Problem, dass der Shop in letzter Zeit sich oft aufhängt und wir den Temp ordner löschen müssen. Dann gehts wieder.
Könnte man nicht ein PHP Script basteln, das den Inhalt des TMP ordners löscht. Wenn wir unterwegs sind, kommen wir nicht ins backend (Mobile: einloggen nicht erlaubt) oder auf einen ftp Server. Aber eine URL könnten wir aufrufen. Wäre ein PHP Script eine Lösung?
Im Prinzip kann man aber den Script beliebig (auch außerhalb des Shops) auf dem Server platzieren und nach einer kurzen Passwortabfrage ausführen lassen.Der Script muss nur Zugriffsrechte auf den Ordner haben.
Temp alle paar Stunden zu löschen ist keine Lösung, weil da anscheinend irgendwas falsch läuft.
Ich würde euch raten den Shop mal checken zu lassen.
Ja, genau, es wäre sicherlich besser die Ursache zu beheben, als nur Symptome zu bekämpfen, keine Frage!
Aber es gab mal so ein Modul, welches bei JEDEM Zugriff immer alles löscht. Ist ein krasser Ansatz und taugt nur zur Entwicklung, aber wen es interessiert:
<?php
/**
* This file is part of Musterdenker Dev Module for OXID eShop.
*
* Musterdenker Dev Module for OXID eShop is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, either version 3 of the License, or
* (at your option) any later version.
*
* OXID eShop Community Edition is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with Musterdenker Avatar Module for OXID eShop. If not, see <http://www.gnu.org/licenses/>.
*
* @link http://www.musterdenker.de
*/
/**
* class to extend "_runOnce()" methode to be executed at the very begining
*/
class mude_oxshopcontrol extends mude_oxshopcontrol_parent
{
/**
* Extension of oxshopcontrol _runOnce() method to empty the "tmp/" folder in case
* productive mode is off.
*
* @extends _runOnce()
* @return null
*/
protected function _runOnce()
{
if ( !$this->getConfig()->getActiveShop()->oxshops__oxproductive->value )
{
foreach (glob(getShopBasePath() . "tmp/*") as $filename) {
unlink($filename);
}
}
parent::_runOnce();
}
}
Keine Ahnung, ob es diesen “Musterdenker” noch gibt, seine Domain ist tot und auch sonst konnte ich nix finden. Von daher ist es wohl okay, wenn ich es hier poste, denke ich. Aber ich fand den Ansatz zu radikal. Besser dann schon ein Cronjob jede Stunde oder so, aber wie gesagt: am besten die Fehler beheben!
Fehler? Hört sich jetzt nicht so dolle an. Zumindest hatten wir deshalb nun 8 Stunden keine Umsätze mehr gehabt. Alle Admins unterwegs und ohne FTP Zugänge, da kannst dann nur flennen.
Werden uns wohl mal was überlegen müssen. Es kam in letzter Zeit schon häufiger vor…aber wenns mal wieder ruhiger ist mit “downs” dann vergisst man das Thema schnell. Danke Euch für die schnellen Ideen
Ich würde ein PHP-Script erstellen, dass alle Dateien in /tmp löscht (ausser .htaccess) via Browser aufgerufen werden kann. Das Verzeichnis des Scripts muss dann natürlich auch via .htaccess und .htpwd geschützt werden.
Dieses Script kann dann entweder von unterwegs übers Internet per Browser von jedem mit Zugangsberechtigung aufgerufen werden, oder auch via Cronjob automatisiert laufen.
Wie gesagt, das behebt nur das Symptom, aber nicht die Ursache.
foreach ( glob(getShopBasePath().'tmp/*') as $sFile )
@unlink( $sFile );
Dabei verhindert glob() in dieser Form automatisch das Löschen aller Dotfiles, und es kann im tmp-Dir ja nur die .htaccess geben. Mehr Code braucht es also gar nicht, allerdings gibt es getShopBasePath() ja nur innerhalb des OXID-Kontextes. Wenn man es solo laufen lassen will, muss man die Funktion halt ersetzen durch z.b.:
(Falls der Shop in einem Subdir installiert ist, muss dieses auch noch vor “tmp/”.)
Eine Schein-Sicherheit könnte man als Notlösung auch dadurch schaffen, dass man das Script z.b. “hk34fkc3d8.php” nennt, da kommt per Zufall niemand drauf, und man kann sich weiteres evtl. sparen. Für euer Szenario sollte es evtl. reichen.
So, es wurde mal wieder Zeit für ein Modul-Update (1.1.1)! Und zwar ist es nun technisch erheblich simpler gelöst (braucht nur noch eine Klasse) und die header.tpl muss [B]nicht[/B] mehr in die Views kopiert werden, sondern bleibt im Modul-Ordner und wird dort aktiviert. Das hält den Core cleaner!
Außerdem habe ich mich mal dem Layout aus OXID 4.7 angepasst, welches ja bereits den “Startseite des Shops”-Button enthält. Und auch die Löschung der tmp-Files ist unter OXID 4.7 nun wieder komplett, d.h. auch alle Inhalte des smarty-Ordners werden nun gnadenlos mitgelöscht. Ob dies allerdings überhaupt sinnvoll ist, oder man sich doch mal Gedanken über eine selektive Löschung machen sollte, sei dahingestellt. Wenn sich da jmd. richtig gut mit auskennt, darf er gern helfend eingreifen…
Ach ja, und ich finde die Bewertungs-Quote im eXchange ziemlich mager, muss ich gestehen, das geht sicherlich besser als 2 von ca. 524288 (und dann noch kommentarlos), also gebt mal bisserl Gas!
ich könnte mir gut vorstellen, dass man auf GitHub leicht “Gespielen” findet, die gern mit in den Code eingreifen. Das fertige Ergebnis könnte man dann wieder von Zeit zu Zeit auf dem eXchange platzieren. Quatsch mich per PN an, falls es damit Schwierigkeiten gibt.
ihr immer mir eurem GitHub!
Aber hast wahrscheinlich schon recht, und ich muss mich da beizeiten mal mehr mit auseinandersetzen… danke jedenfalls für den Tipp!
Gitthapp windoof Äpp klingt gut, wenn auch etwas spät, thx!
Seit eben ist aber erstmal DelTmp 1.1.2 online im eXchange, da seit OXID 4.7.5 die Revision anders lautet und nicht ins Backend oben rechts passt. Außerdem wird nun beim (De)Aktivieren des Moduls automatisch der Header reloaded…
Und damit auch alle etwas davon haben, habe ich die 1.0.1 re-integriert, sodass es endlich wieder nur ein Modul für alle OXID-Versionen gibt. Genaueres steht in der setup.txt des Modul-ZIPs. Viel Spaß weiterhin damit!
So, liebe Leute. Es wurde Zeit für ein Update auf Version 1.2.1, da in der 1.2.0 ein Mini-Bug schlummert, der aber nur unter OXID 4.7.10 zum Tragen kommt (mit 4.8.x geht es wieder/noch), siehe auch hier. Danke nochmal an Coarsy!
In Kürze im eXchange erhältlich (sonst per Mail)…
Und da ich ja nun auch zum erlauchten Kreis der githubber gehöre (naja), würde mich die Meinung interessieren, in wie weit es realistisch wäre, das Modul in den “trunk” mergen zu wollen? Ich meine, so oft, wie es bisher im Einsatz zu sein scheint, geht es doch bald quasi als Standard durch, oder?
Es kann von mir aus aber auch ein Modul bleiben, da ziemlich pflegeleicht.
