Vt Dev Utils

vanilla_thunder · October 14, 2012, 2:03am

Hallo,

die neue Modul Verwaltung ist zwar toll für den Benutzer, der Entwickler hat aber einige Hürden.
Die Settings, eigene Klassen, Templates und Blocks werden in verschiedenen Tabellen und auch noch als Blobs gespeichert, was während der Entwicklung nur unnötig viel Zeit und Aufwand kostet die Einträge mal zu aktualisieren.

Deswegen habe ich ein Modul gebastelt, das die alten Einträge für ein Modul löscht und jeweils die neuen Einträge für Templates, Blocks, Files etc. aus der metadata.php wieder übernimmt.

Bis jetzt gibts nur 5 Funktionen:
1: tmp/ leeren ( + Anzahl und Gesamtgröße der gelöschten Dateien)
2: templates Einträge aktualisieren
3: blocks aktualisieren
4: files aktualisieren
5: settings aktualisieren

und hier gibts das gute Stück:

freue mich auf die Rückmeldung und Verbesserungsvorschläge

toxid · October 14, 2012, 3:01pm

Ich denke, ich werde mir davon etwas in mein Modul rüberkopieren. Muss ich nur umlizenzieren, befürchte ich

Zwei Anmerkungen hab ich:

Da bei Oxid der Doc-Root im Wurzelverzeichnis der Applikation liegt, dürften einige Benutzer in das tmp-Verzeichnis eine .htaccess legen, um den Zugriff darauf zu sperren, anstatt das in der Server-Config zu definieren. Weiters könnten sich dort auch eine .gitignore oder ein .svn-Verzeichnis befinden, die sicher nicht gelöscht werden sollten. Daher würde ich Dotfiles nicht löschen. Ich habs so gelöst:
https://github.com/tueena/oxid_module_tueena_dev/blob/master/views/tueena_dev_views_shopcontrol.php
Ist es wirklich nötig bzw. sinnvoll, vier verschiedene Links zur Aktualisierung der Moduldaten anzubieten? Die Performance ist in dem Fall egal und falls man mehr als eine Sache löschen muss, muss man mehrmals klicken. Ich würde einen Link für den kompletten Modul-Cache bevorzugen.

vanilla_thunder · October 14, 2012, 4:20pm

Moin,

1: php Funktion glob() liefert (zumindest unter Linux) keine versteckten Dateien, das bedeutet, dass alle Ordner und Dateien mit einem Punkt am Anfang (und alle git und svn Ordener/Dateien haben das) nicht gefunden und somit nicht gelöscht werden.
Problem gelöst

2: Das hatte ich anfangs auch so, allerdings hat es mich schnell frustriert, dass die Einstellungen jedes Mal verloren gingen, wenn ich zum Beispiel Blocks aktualisieren wollte. Und dann habe ich die Funktion dann auf 4 Funktionen verteilt, so dass man das aktualisieren kann, was gerade benötigt wird.

toxid · October 18, 2012, 10:29am

[QUOTE=vanilla thunder;104834]

1: php Funktion glob() liefert (zumindest unter Linux) keine versteckten Dateien[/QUOTE]

Oh ja, stimmt. Du hast recht.

[QUOTE=vanilla thunder;104834]
2: Das hatte ich anfangs auch so, allerdings hat es mich schnell frustriert, dass die Einstellungen jedes Mal verloren gingen, wenn ich zum Beispiel Blocks aktualisieren wollte.[/QUOTE]

Ja, das ist ein Argument. Allerdings würde es dann doch reichen, die Settings extra zu machen und den Rest zusammen zu packen, oder?

jschindler · October 18, 2012, 10:52am

[QUOTE=toxid;105344]
Ja, das ist ein Argument. Allerdings würde es dann doch reichen, die Settings extra zu machen und den Rest zusammen zu packen, oder?[/QUOTE]

Oder vier Checkboxen und ein Button draus machen

vanilla_thunder · November 14, 2012, 10:44pm

hier ist eine kleine Vorschau von dem kommenden Feature:

man kann php Code (inklusive dem Shop Framework) eingeben und live die Ergebnisse betrachten.
Spart eine Menge Zeit im Vergleich mit dem sonstigen ändern-speichern-hochladen-neuladen.

Was meint ihr?

Levo · September 25, 2015, 1:38pm

Hallo,

wenn ich das Modul _dev-core aktiviere, dann werden in einigen anderen Modulen die Admin language files nicht mehr erkannt, wenn ich es wieder deaktiviere dann funktioniert wieder alles. An was kann das liegen?

Gruß
Levo

marco.steinhaeuser · September 28, 2015, 12:12am

Hallo Levo,

es liegt daran, dass dev-core zwingend benötigt wird, um die anderen Module zu betreiben. Ein einfacher Usability-Flaw

Gruß

Levo · September 28, 2015, 5:56pm

[QUOTE=Marco Steinhaeuser;163910]Hallo Levo,

es liegt daran, dass dev-core zwingend benötigt wird, um die anderen Module zu betreiben. Ein einfacher Usability-Flaw

Gruß[/QUOTE]

Die Module haben aber gar nichts mit den Dev Utils zu tun, das sind komplett eigenständige. Deswegen verwundert mich das etwas.

vanilla_thunder · October 5, 2015, 11:54am

Hi,

ist das die neuste Version?
Dann gitbs in den Modul-Einstellungen des core Moduls 3 checkboxen, deaktiviere sie mal.
und schreib mit bitte per PN, welche fremden Module davon betroffen sind.

Levo · October 10, 2015, 9:11am

Ja, ist die neuste Version (1.2.0).
Bei mir gibts nur zwei Checkboxen, Language und Smarty Cache deaktivieren.
Habe sie beide deaktiviert, hat aber leider nicht geholfen

m431342 · March 2, 2017, 11:28am

Ist das Modul eigentlich für die PE-Version geeignet?

Bei mir funktioniert es in der CE 4.10.3 einwandfrei, aber nicht in der PE.

In der PE-Version bekomme ich schon beim Anklicken der Teilmodule editor, logs, mail, modules die Meldung ‘Modul kann nicht geladen werden’.

Bei den Teilmodulen core und console hingegen tritt dieser Fehler nicht auf.

Alle übrigen Module sind nicht betroffen und funktionieren einwandfrei.

Hat jemand einen Tip?

vanilla_thunder · March 2, 2017, 11:42am

wir haben es in einem 4.9er PE drin, aber 4.10 ist nicht wirklich anders (bis auf das visual cms beta Ding)
“Module kann nicht gerladen werden” kommt meistens dann, wenn der Pfad zum Modul aus diversen Gründen nicht richtig aufgelöst werden konnte oder Moduldateien fehlen.
Lade die Module vorsichtshalber nochmal hoch.
Und führe mal diesen Code in der console aus:

print_r($cfg->getConfigParam("aDisabledModules"));
print_r($cfg->getConfigParam("aModulePaths"));

dann siehst du zwei arrays, im ersten Sind deaktivierte Module und im zweiten sind Pfade zu den jeweiligen Modulen, die OXID im Cache hat.

Sind die nicht aktvierbaren Module im ersten Array enthalten?
Und wie sind die Pfade im zweiten Array?
sollte so sein:

    [dev-editor] => vt-devutils/dev-editor
    [dev-logs] => vt-devutils/dev-logs
    [dev-mails] => vt-devutils/dev-mails
    [dev-modules] => vt-devutils/dev-modules

windes · May 5, 2017, 10:26am

Hallo Vanilla,

wenn ich habe das Modul vt-devutils Core aktiviere und dann wird in den Bestellungen und bei den Benutzern die Historie nicht mehr ausgegeben.

Es kommt zu dieser Fehlermeldung:

.config(function($mdThemingProvider) { $mdThemingProvider.theme(‘devutils’).primaryPalette(‘blue’).accentPalette(‘green’).warnPalette(‘red’).backgroundPalette(‘grey’); $mdThemingProvider.setDefaultTheme(‘devutils’); }) .filter(“html”, [‘$sce’, function ($sce) { return function(htmlCode) { return $sce.trustAsHtml(htmlCode); } }])

Modulversion 1.3.0
OXID 4.10.3

Henning_Kockerbeck · May 17, 2017, 5:33pm

Hallo,

ich habe gerade die Dev Utils installiert und habe Probleme mit dev_console und dev_modules. Die Dev Utils sind die aktuelle Version von Github, OXID ist Version 4.10.4.

Die Konsole wird angezeigt, aber wenn ich auf “Run Code” klicke, tut sich nichts weiter. Laut der Fehlermeldung in der Browserkonsole wird eine Funktion von Angular verwendet, die aus Angular 1.6.x entfernt wurde:

17:29:45.678 TypeError: $http(...).success is not a function

Anstelle von success() (und auch error()) soll man jetzt then() verwenden, siehe z. B. diese SE-Frage.

Wenn ich dev_modules aktiviere, kann ich keine Veränderung erkennen. Wo genau sollten die zusätzlichen Module über die Module auftauchen?

Bis dann,

Henning

vanilla_thunder · May 17, 2017, 6:13pm

warte bitte bis morgen Nachmittag, ich habe am Montag JS Frameworks aktualisiert und neues Modul eingebaut, weswegen dev-modules nicht funktioniert. Morgen spiele ich das Update auf github hoch und dann sollte es gehen.

edit:
die größten Baustellen sind fertig:
framework updates
bisschen redesign
core Modul
"dev-module" heißt jetzt "dev-metadata"
editor

nicht einsatzbereit sind:
email preview (da kommen etwas größere Umbauten)
checkout (neues Modul, ist eigentlich noch gar nix drin)