Beiträge von madas

    Ja, zum Beispiel. Am besten auch andere Dateinamen für die Partials verwenden, schon deshalb, weil man dann gleich ne Fehlermeldung erhält, wenn mal einer Fehlen sollte. Und damit diese den unsrigen nicht in die Quere kommen…

    Cool. Danke vielmals. Mit Euch macht die Zusammenarbeit wirklich Spaß. Toll.

    Hallo,

    sind die Scopes und die Suchreihenfolge für partials die gleichen, wie bei den Widgets?

    Zitat

    Scopes für Widgets

    Zeta Producer sucht in diesen Verzeichnissen (und in dieser Reihenfolge) nach Widgets:

    1. Projektordner
      Beispiel: C:\Users\*Benutzer*\Documents\Zeta Producer 14\projects\*Projekt*\widgets 
    2. Benutzerordner
      Beispiel: C:\Users\*Benutzer*\Documents\Zeta Producer 14\widgets 
    3. Programmordner

    Habe einige partials aus _Shared\templates angepasst. Um jedoch bei einem Update nicht die Änderungen zu verlieren, würde ich diese partials gerne in den Projekt Ordner verschieben.
    Bei einigen Layouts habe ich gesehen, dass im Ordner templates ein Unterordner partials gibt. Wäre dies der korrekte Ort, wo man die geänderten partials aus _Shared\templates einfügen sollte?

    Danke.

    Super. Ich finde es auch besser, sowas eher "generalisiert" anzugehen, als für jede einzelne Widget-Instanz irgendwie zu reagieren. So machen wir das mit den meisten Widgets ja auch (zum Beispiel Bilderalbum). Wir nutzen da auch gerne data-attribute um etwa Widget-spezifische Einstellungen im HTML zu speichern, auf die wir dann darüber von JS aus zugreifen können…

    Nur zur Info: üblicherweise nutz man jQuery ja per $(irgendwas) oder jQuery(irgendwas). $z ist ein alias auf das von uns mitgelieferte jQuery. Ein Benutzer könnte ja selbst nochmals jQuery laden und dann würde der $() oder jQuery() auf die zuletzt geladene Version verweisen. Mittels des Alias $z haben wir für uns einen Weg geschaffen, sicher auf die von uns installierte Version zuzugreifen…

    Danke für die zusätzlichen nützlichen Tipps.

    Hier mal eine Beispielwebsite mit dem Widget, die sicher selbst in einem IFrame aufruft.


    https://hosting.zeta-producer.com/4953141007/index.html

    Grüße madas

    PS: das Widget werde ich demnächst mal posten. Muss noch die Anzeige der Voraussetzungen für die Benutzung einbauen.

    Hallo,

    das würde ich so lösen. Im Standard.html des Widgets setzen Sie für das iFrame eine spezielle Klasse und eine ID, die die Artikel-ID enthält, also z.B. so:

    <iframe src="xyz" class="superFrame" id="frameId<$=article.id$>"></iframe>

    Im JavaScript, das Sie bundeln, initialisieren Sie dann alle iFrames, die durch Ihr Widget erzeugt wurden so:

    JavaScript
    $z(document).ready(function(){
        // mittels jQuery-Code alle SuperFame iFrames initialisieren
        $z("iframe.superFrame").each(function(){
            // die eindeutige ID des aktuellen iFrames in variable speichern
            var currentId = $z(this).attr("id");
    
            // nun der Funktionsaufruf von iFrame-Resizer inkl. Übergabe der iFrame ID aus variable.
            meineFunktion(currentId);
        });
    });

    Das ist natürlich alles ungetestet, sollte aber ggf. als Lösungsweg helfen. Oder?

    Vielen Dank. Werde ich gleich einmal testen.

     

    Hallo,

    Attribute werden ja nur zum Zeitpunkt des Erstellens der Ausgabeseiten aufgelöst und nicht etwa live, wenn eine Seite im Browser geladen wird. Ich vermute also, die angefragte Funktion würde ihnen gar nicht groß helfen und es gibt ggf. bessere Wege das gewünschte zu erreichen. Können Sie grob beschreiben, was das Skript, das mit der Artikel-ID verknüpft sein soll denn macht?

     

    Hallo,

    danke für die schnelle Rückmeldung. Hm, der Html Code eines Widgets wird doch zu 99% auch nur bei der Erstellung der Seiten aufgelöst, wenn ich nicht ganz daneben liegen.

    Gut dann etwas ausführlicher: Euer IFrame-Widget ist nicht für responsive Websites geeignet, so dass ich mir selber eines bastel möchte. Dazu verwende ich folgende Resize Bibliothek:

    https://github.com/davidjbradshaw/iframe-resizer

    Auf der einzubettenden Seite wird eine JS-Datei eingebunden (und der letzte HTML-Tag mit dem Attribut "data-iframe-height" versehen. Auf der Hostseite muss man 1 bzw. 2 JS-Dateien einbinden (das klappt über das Bundlen ganz gut) und aus diesen JS-Dateien dann noch eine Funktion aufrufen. Der Aufruf diese Funktion sollte möglichst am Ende der Seite stattfinden, sprich genau dort, wo das Footer_Script Attribut eingebunden wird. Der IFrame erhält eine ID, welcher auch beim Funktionsaufruf mitübergeben werden muss, damit die Berechung von Breite und Höhe klappt. Da sich theoretisch jedoch 1-n IFrames auf der Seite befinden können, würde ich der IFrameID gerne die ArtikelID überhelfen. Z.B.: id="IFrame_2023".

    Vielleicht versteht man das Ganze jetzt etwas besser.

    Grüße madas

     

    Hallo Jochen,

    vielen Dank für den Tipp, das hat wunderbar geklappt. Was jedoch passiert ist, dass nun jeder Text im Inhaltsbereich und in der Menüleiste "fett" dargestellt wird. Gibt es hierzu eine Lösung?

    Liebe Grüsse

     

    Versuchs mal so: Website <strong>Welt</strong>

    Da fehlt der schließende Tag.

    Wenn Du Deinen 13er Producer startest und dort auch eine gültige 13er Lizenznummer eingibst, dann sollte die freischaltung auch klappen. Es sei denn Du hast den Aktivierungs-Counter überschritten. Dann kurze Mail an den Support mit der Bitte den Counter zu erhöhen. Hat bis jetzt in den meisten Fällen ohne Mullen und Knullen geklappt.

    Für den 13er fängt die Lizenznummer mit ZP13 an und dann kommt ein Buchstabe je nach Version. B für Business, X für Expres, usw.

    Wenn Sie ein Widget kopieren, empfehlen wir, dass Sie Ihre CSS und JS-Dateien anders benennen, so dass sich diese deutlich von unseren Unterscheiden, sonst überschreiben Ihre Dateien ggf. auch unsere Funktionen. Alternativ können Sie die "order" der Datei im widget.js verändern, um das Ladeverhalten zu beeinflussen.

    Ich habe die Dateien vom geänderten Widget nun einmal umbenannt. Brachte vorerst auch keine Besserung. Also habe ich noch einmal alle Seiten, auf denen sich dieses Widget befand gelöscht und neuerstellt. Dann noch den Preview Ordner gelöscht und alles neuerstellen lassen. Jetzt scheint es erst einmal zu funktionieren. Problem bei der Preview war wohl, dass die js-Dateien nicht gebundelt werden, wie es sonst beim Output der Fall ist. Und daher geriet wohl etwas durch einander.

    madas

    Sorry, ich kann Ihnen noch nicht folgen, weil Sie nicht spezifiziert haben, was Sie in "meine Änderungen" genau wo geändert haben.

    Dazu könnte ein Blick in mein geändertes Widget hilfreich sein. :)

    Wenn wir an widgets arbeiten, schalten wir den Entwickler-Live-Modus (Extras > Entwickler) an. Dann werden sämtliche Änderungen in der internen Vorschau "live" geladen, sobald man eine Datei des Widget abspeichert.

    Den Entwickler-Modus habe ich angeschaltet. :(

    Was ich bis jetzt feststellen konnte, ist die Tatsache, dass mein Widget in der Preview vom Producer für ein neues, leeres Projekt so funktioniert, wie es soll. Nur nicht in dem Projekt, mit dem ich es entwickelt habe. Dort greifen zwar die Änderungen in der "eventoverview.html", jedoch die Änderungen in der "eventcalendar.js" nicht. Auch nicht einer kompletten Neuerstellung aller Seiten. Klicke ich nach dem Erstellen jedoch auf Vorschau, wird mir im Browser alles korrekt angezeigt.

    Trotzdem hätte ich noch eine Frage. Die Darstellung bei der Ausgabe funktioniert tadellos. Nur scheinbar haben meine Änderungen am Widget keine Auswirkungen auf die Vorschau im Producer selber. Dort greift weder der Filter, noch wird mein Footer angezeigt. Woran könnte das liegen? Das gleiche Problem habe ich auch bei anderen selbst geklöppelten Widgets.

    Grüße madas

    In der JS Datei vom Widget wird ja ein "Style" Tag in den Header injected. Findet das bei der Preview im Producer nicht statt? Wenn ja, warum nicht?

    Trotzdem hätte ich noch eine Frage. Die Darstellung bei der Ausgabe funktioniert tadellos. Nur scheinbar haben meine Änderungen am Widget keine Auswirkungen auf die Vorschau im Producer selber. Dort greift weder der Filter, noch wird mein Footer angezeigt. Woran könnte das liegen? Das gleiche Problem habe ich auch bei anderen selbst geklöppelten Widgets.

    Grüße madas

    Morgens,

    was muss ich bei der Veranstaltungsübersicht bei Auswählen > SQL eintragen, damit ich alle Veranstaltugnen eines Genres bekomme?

    Leider konnte ich keine Doku zur Filterung via SQL finden. Das Beispiel welches man eintragen kann, hilft auch nicht wirklich weiter, da die Bezeichnung der DB Felder nix mit den Namen/Bezeichnungen der Felddefinitionen im Widget "Veranstaltung" gemein zu haben scheint.

    Besten Dank.

    madas

     

    Deshalb soll uns dort auch kein Backup die Server "verstopfen".

     

    Aha. Bei mir ist es dann aber ok (wenn auch abwählbar)? :wacko:


    Bei kleinen Projekten mag es ja noch praktikabel sein, aber nicht für größe Projekte mit einer Größe vom Ausgabeverzeichnis von 300MB und mehr. Die Zip-Datei ist nur unwesentlich kleiner, sprich mit ihr wird das doppelte Kontingent an Webspace verbraten. Und für den Upload sollte man dann schon ne halbwegs fett Leitung haben.

    Trotzdem bleibe ich dabei: ein Webserver sollte ein abgeschottetes System sein, welches nur dem Zweck des Hostings der Website dienen sollte. Für Backupzwecke gibt es genug andere Lösungen. Zwei bietet Ihr ja mit Dropbox bzw. OneDrive schon als Option mit an.

    Grüße madas

    Solchen Kunden hat das schon derart oft das komplette "Neuerstellen" der Website erspart, das können Sie sich nicht vorstellen.

    Auf Eurem Hosting Server scheint Ihr die Backups aber auch nicht unbedingt zu mögen. ;)

    Code
    if (information.WantPublishToWebServer &&
        this._targetWriter.CanPublishToWebserver &&
        this._webProject.SettingsPublishing.PublishingServer != null &&
        this._webProject.SettingsPublishing.PublishingServer.WebPublishingProtocol != WebPublishingProtocolType.ProducerHosting)

    Man beachte das letzte "!=". Hust. :evil:

    Schönes WE. :P

    Moin,

    wenn dir dein Rechner abraucht und du sonst keine Sicherung(en) hast (hier schon oft vorgekommen), dann bist vielleicht froh dass dort ein Backup deines Projektes liegt

    Für den Privatmann mag das vielleicht zutreffen. Dieser wird aber kaum einen eigenen Webserver betreiben, geschweige denn sich irgendwelche Log-Dateien anschauen und die Zugriffsstatistik nach möglichen Angreifern durchsuchen. Daher handelt sich wahrscheinlich um ein nicht privates Umfeld. Und wer dort einen Webserver als Backup-Medium für Zip-Dateien missbraucht und diese dann per .htaccess Dateien gegen unerlaubten Zugriff versucht zu schützen, der sollte sein Konzept zur Datensicherung generell mal überdenken.
    Die Projekte werden sicher auf einem Entwicklungsrechner erstellt. Diesem sollte ein Raid-System zu Grunde liegen, welches den Datenbestand spiegelt (1. Sicherung). Weiterhin bieten die meisten Festplattenhersteller eine kostenlose Version von True Image an, welche hervorragend zur Datensicherung auf externe Medien (USB, NAS usw.) geeignet ist (2. Sicherung, gegebenenfalls auch 3. Sicherung außer Haus, wenn die USB-Platte mit nach Hause nimmt bzw. das NAS in einer Zweigstelle stellt). Seine Sourcen kann man jedoch auch mit einer Quellcodeverwaltung bzw. einem Versionssystem wie Subversion gegen Datenverlust schützen, sei es jetzt auf einem Server im eigenen Firmennetz oder via Github oder ähnlichem im WWW (3. Sicherung, außer Haus). Und das schöne daran: dies kann jeder Privatmann auch so machen.

    Nachtrag: Da das Backup von Zeta-Projekten wahlweise auch im Root-Verzeichnis des Servers gespeichert wird in der Form ***.zip gespeichert wird, besteht hier zumindest theoretisch eine Schwachstelle. Ich suche mal nach einer entsprechenden Sperranweisung für die .htaccess. Falls spontan ein anderer User diese schon griffbereit hat, bitte posten.

    Ähm sorry, aber was hat eine Backup-Zip von einem Zeta-Projekt auf einem Webserver zu suchen?

    Hallo,

    im "preview"-Ordner müssen wir eine Seite erstellen, da Sie sonst in der Internen Vorschau einen Fehler erhalten würden, wenn Sie im Seitenbaum auf die Seite klicken. In dem Moment wird nämlich versucht für die Vorschau eine Seite zu laden. Im Output-Ordner (die Daten, die auf den Webserver kopiert werden) würde aber sicher keine Datei benötigt werden.

    Ich rege das mal als "Feature Request" an. Die Datei ist ja aber nicht sehr groß und fällt daher nicht sonderlich ins Gewicht.

    Selbst für den Fall mit dem Preview Ordner könnte man auf die Erstellung verzichten und eine Art Dummy-Datei bereitstellen, die darauf hinweist, dass die Option "Umleitung" aktiv ist und für ganz Faule auch noch einen Button bzw. Link zur Verfügung stellt, mit dem man die Umleitung gleich testen kann. ;)

    madas

    Bitte schauen Sie einmal welche PHP Version auf Ihrem Server läuft. Damit der Shop läuft muss diese >= 5.6.0 sein (https://docs.zeta-producer.com/onlineshop-veroeffentlichen.html)
    Bei 5er Versionen darunter wird obiger Fehler angezeigt, da diese PHP Version nicht mit der Konkatinierung via '.' bei privaten Variablen klarzukommen scheinen.

    Zeile 10 aus SessionHelper.inc.php:

    private $Prefix = 'ZPS-' . ZPS_API_KEY . '-';

    (https://stackoverflow.com/questions/2786…ss-const-in-php)

    @Hr. Seiz: eventuell kann man die Variablen-Initialisierung von $Prefix in den Konstruktor verlegen, dann sollte es auch mit der 5.4.0 PHP-Version klappen.

    Also ich meine, Sie hätten bereits PHP 5.6 oder größer installiert gehabt. Sie können es aber gerne mal mit PHP 7 versuchen. Eine Anleitung dafür kann ich allerdings nicht bieten. Bei den meisten Webhostern lässt sich das aber per Administrations-Interface umstellen.

    Da war der Hr. Seiz wohl etwas schneller. :)

    http://prntscr.com/fhq8pl

    Ggf. könnte ich eine andere php-Version installieren, sofern ich die entsprechende Anleitung erhalte.

    Steht der Webserver bei Ihnen oder bei einem Hoster? Falls Hoster: haben Sie einen V-Server gemietet, den Sie selber verwalten oder haben Sie ein Webseite-Paket gebucht. Im letzteren Fall sollte die PHP-Version eigentlich über das Online-Portal des Anbeiters konfigurierbar sein. Bei den anderen beiden Fällen, müssten Sie es selber machen. Da ich auf Ihrem Bild aber irgendwas mit root erkennen kann, scheint es sich um Linux zu handeln. Da bin ich leider raus, da mir dieses Betriebssystem nicht zusagt und ich mich damit nicht auskenne. Aber Tante google hilft Ihnen sicher.

    Beste Grüße und viel Erfolg.

    Ist eher schlecht, da das ganze wichtig ist. Aber es gibt wohl keinen anderen Weg.

    Bitte schauen Sie einmal welche PHP Version auf Ihrem Server läuft. Damit der Shop läuft muss diese >= 5.6.0 sein (https://docs.zeta-producer.com/onlineshop-veroeffentlichen.html)
    Bei 5er Versionen darunter wird obiger Fehler angezeigt, da diese PHP Version nicht mit der Konkatinierung via '.' bei privaten Variablen klarzukommen scheinen.

    Zeile 10 aus SessionHelper.inc.php:

    private $Prefix = 'ZPS-' . ZPS_API_KEY . '-';

    (https://stackoverflow.com/questions/2786…ss-const-in-php)