ganz ausschließen tut das SoftCreatR wohl auch nicht.
Nein, tu ich nicht. Denn das Tool prüft nur auf ihm bekannte Schriften (sollten aber so ziemlich alle sein) und dies wiederum nur im Quelltext und im CSS. Werden Schriften z.B. mittels Javascript geladen, erkennt das Tool das nicht. Und wenn ich eine absolute Aussage treffen würde, die sich am Ende als falsch herausstellt, bin ich der Doofe 
Nein, tu ich nicht. Denn das Tool prüft nur auf ihm bekannte Schriften (sollten aber so ziemlich alle sein) und dies wiederum nur im Quelltext und im CSS. Werden Schriften z.B. mittels Javascript geladen, erkennt das Tool das nicht. Und wenn ich eine absolute Aussage treffen würde, die sich am Ende als falsch herausstellt, bin ich der Doofe
Dein Plugin zum Laden der Schriften auf dem Server funktioniert ja beim 5.3 nicht, richtig?
Dein Plugin zum Laden der Schriften auf dem Server funktioniert ja beim 5.3 nicht, richtig?
Du verdrehst wieder was. Das von woltlab ist quasi das Gleiche, was Softi schon hatte. Mit dem einzigen Unterschied, dass bei Woltlabs Implementierung nur eine Font unterstützt wird.
einzeln auf Stabilität und Sicherheit überprüft.
Aber das heißt doch nicht, dass sie auch rechtlich überprüft werden?
Noch einmal. Ich sehe mich und bestimmt 90% der Foreninhaber als Anwender, welche nicht extrem in der Materie der Programmierung bei Woltlab drin stecken. Ich kaufe ein Forensystem und einige Plugins etc. im offiziellen Store und vertraue auf die Funktionen die für das Forensystem beworben werden.
Ist es jetzt mein Fehler, wenn diese Funktionen nicht gegeben sind? Nein. Dann muss ein Hinweis dazu, dass beworbene Funktionen nur beim Standartstil gegeben sind.
Wenn man keine Ahnung davon hat und sich selber nicht zutraut/zumutet, seine Webseite so zu warten und zu prüfen, dass sie auch rechtlich abgesichert ist, sollte man eine Rechtsberatung dahingehend in Betracht ziehen oder eine andere Person, die sich damit auskennt. Ich sehe hier auch nicht das Problem bei WoltLab.
Gruß
ilou
Also werden alle Produkte aus dem Store nicht auf Kompatibilität mit den angegebenen Funktionen der Woltlab Software überprüft? Gut zu wissen.
Das hat doch nichts miteinander zu tun. Natürlich wird das geprüft. Aber die WoltLab-Software ermöglicht grundsätzlich nur die Verwendung einer einzigen Google-Schriftart und wenn man nun mehrere nutzen möchte, muss man entweder diese über Google Fonts laden, oder dem Stil-Paket beilegen.
Also werden alle Produkte aus dem Store nicht auf Kompatibilität mit den angegebenen Funktionen der Woltlab Software überprüft? Gut zu wissen.
Und wieder verdrehst du Dinge. Das hat nichts mit Kompatibilität zu tun. Das ist lediglich eine Funktion die vom WSC zur Verfügung gestellt wird. Nicht mehr und nicht weniger. Ob und wie ein Entwickler dieses einsetzt, ist ihm überlassen.
Und wieder verdrehst du Dinge. Das hat nichts mit Kompatibilität zu tun. Das ist lediglich eine Funktion die vom WSC zur Verfügung gestellt wird. Nicht mehr und nicht weniger. Ob und wie ein Entwickler dieses einsetzt, ist ihm überlassen.
Du willst es nicht verstehen? Was verdrehe ich denn? Dies Funktion wird als Neuerung beworben. Also sollte ich als Hersteller dieser Neuerung auch schauen, ob diese in meinem Lizenzshop bei dem am dritthäufigsten verkauften Stil auch funktioniert. Sonst muss ich diesen Stil halt in meinem Store als nicht kompatibel markieren. Ganz einfach.
Oder halt für jeden ersichtlich machen, dass Neuerungen, welche die User als Grund für bezahlte Updates nehmen, nur bei dem Standartstil funktionieren.
Was verdrehe ich denn? Dies Funktion wird als Neuerung beworben.
Dem ist auch so. Denn die Funktion gab es vorher nicht im Core sondern nur via Plugin.
Es ist ganz einfach: Der Stil läuft mit 5.3, also ist es kompatibel. Das hat nichts damit zu tun, ob er nun eine Funktion nutzt oder eben nicht.
welche die User als Grund für bezahlte Updates nehmen, nur bei dem Standartstil funktionieren
steht irgendwo, das sie in Drittanbieter Stilen funktionieren, Woltlab geht immer vom Standard aus.
Aber sie funktionieren auch, wenn du im Stil das laden der Schriftart entfernst.
Woltlab prüft bei PlugIns aus dem Shop auf grobe Sicherheitsmängel. Dadurch, dass sie die Pakete von ihrem Server aus ausliefern, ist das ein weiteres Plus an Sicherheit, wenn man ihnen mehr Kompetenz unterstellt als den Entwicklern von PlugIns. Mehr haben sie nie behauptet.
Ich denke, nicht einmal für die Cloud-Kunden würden sie rechtliche Dinge prüfen, die ja auch PlugIns aus dem Store installieren können.
Sonst muss ich diesen Stile halt in meinem Store als nicht kompatibel markieren. Ganz einfach.
Sie sind technisch kompatibel. Du bekommst keine Fehlermeldung und technisch läuft das Forum einwandfrei. Aber selbst dafür übernimmt Woltlab ja keine Gewähr. Wenn es technische Probleme gibt, ist auch der Entwickler in der Pflicht und Woltlab testet auch nicht jedes PlugIn selber. Das wäre ja auch ein viel zu großer Aufwand.
Bei Googelfonts könntest du doch auch einfach einen entsprechenden Passus in die Datenschutzerklärung schreiben und erledigt ist das Problem. Oder darf man das nicht mehr? Da bin ich jetzt nicht auf dem aktuellen Stand, ich hab sie auch lokal.
Wenn ich den Auspuff vom Händler kaufe schon.
Nicht zwangsläufig, Woltlab bietet hier eine Handelsplattform für Plugin und Stil Entwickler an, um Ihre eigenen Produkte zu verkaufen, dies bedeutet jedoch nicht, das Woltlab eine 100 % Funktionalität oder Einhaltung der Datenschutzverordnungen oder der gesetzlichen Auflagen für Produkte von Drittanbietern, welche über ihre Handelsplattform verkauft werden Garantieren muss oder dieses tut.
Ein Blick in die https://pluginstore.woltlab.com/de/richtlinien/ würde unter anderem auch einiges zur Klärung beitragen.
Display MoreAlle im Plugin-Store eingestellten Erweiterungen und Stile unterliegen einigen grundsätzlichen Mindestanforderungen, die primär darauf abzielen, Probleme beim Einsatz zu vermeiden. Die Dateien werden vor der Veröffentlichung in zwei Schritten überprüft, eine erste automatische Überprüfung arbeitet auf rein formalen Gründen und soll einfache technische Mängel aufdecken. Im zweiten Schritt erfolgt eine manuelle Sichtung durch einen WoltLab Mitarbeiter, mit dem Augenmerk auf Fehler und potenzielle Probleme beim Betrieb.
Im Falle eins negativen Prüfungsergebnisses erhalten Sie eine Benachrichtigung mit den Beanstandungen und – falls praktikabel – auch konkrete Hinweise zur Behebung.
Vorabprüfung auf technische Mängel
Im Rahmen eines automatisierten Prüfprozesses wird die formale Korrektheit der hochgeladenen Datei überprüft:
- Sind alle enthaltenen PHP- und XML-Dateien formal korrekt bzw. enthalten keine Syntax-Fehler, die eine Funktionalität unmöglich machen?
- Enthält das Archiv alle Dateien, die gemäß der package.xml für eine Installation benötigt werden?
- Sind keine überflüssigen Dateien, z. B. versteckte Dateien von Windows oder macOS, im Archiv enthalten, die bei der Installation problematisch sein können?
- Sind die Angaben zur Kompatibilität vollständig bzw. formal korrekt?
Prüfung durch einen Mitarbeiter der WoltLab GmbH
Wir überprüfen alle hochgeladenen Dateien manuell auf Fehler und insbesondere auf mögliche Sicherheitsprobleme. Der individuelle Programmierstil wird dabei nicht bewertet, unser oberstes Ziel ist es, Probleme frühzeitig zu erkennen und in Zusammenarbeit mit dem Hersteller zu lösen.
Die wichtigsten Kriterien die von uns überprüft werden:
- Sicherheitsprobleme stehen klar an erster Stelle. Diese können fehlerhaft verarbeitete Parameter oder Datenbankabfragen sein, aber auch unzureichende Berechtigungsüberprüfungen oder XSS-Lücken im Template fallen darunter.
- Erweiterungen müssen grundsätzlich lauffähig sein, angefangen von der Installation bis hin zu einem groben Funktionstest. Die Benutzeroberfläche sollte sich dabei grundlegend an der Bedienung der restlichen Software orientieren, besonders im Sinne der Benutzerfreundlichkeit.
- Nutzung der bestehenden APIs, beispielsweise die Verwendung von Guzzle (<=5.2: die HTTPRequest-Klasse) für die Durchführung von HTTP-Anfragen. Die bestehenden APIs decken bereits viele unterschiedliche Fälle automatisch ab, etwa die Unterstützung für Proxy-Server, und sorgen für ein konsistentes Verhalten.
- Überflüssiger Programmcode, der zu Testzwecken eingebaut wurde oder fest integrierte API-Codes, die zum Test verwendet wurden und nicht für die normale Installation geeignet sind.
- Grobe Effizienz-Probleme, bei denen aus unserer Erfahrung bereits absehbar ist, dass diese abseits von überschaubaren Testdaten relativ schnell zu Engpässen führen, insbesondere sehr ineffiziente Datenbankabfragen. Oftmals reichen bereits minimale Änderungen, um diese Probleme aus der Welt zu schaffen.
- Unvollständige Übersetzungen, insbesondere die englische Übersetzung ist nicht nur für einen größeren Kundenkreis notwendig, sondern wird oftmals auch als Grundlage für die Übersetzung in andere Sprachen verwendet. Mit einfachen Werkzeugen, beispielsweise dem Dienst von deepl.com, lassen sich mit wenig Aufwand bereits gute Übersetzungen erreichen, die eine ausreichende Basis darstellen.
- Sichtbare Copyright-Vermerke sind bei Stilen auf allen Seiten und bei Apps auf den App-eigenen Seiten zulässig. Sonstige Erweiterungen dürfen derartige Hinweise nur auf eigenständigen Seiten, die von der Erweiterung selbst stammen, setzen.
- Die implizite oder explizite Installation von Paketservern ist generell unzulässig.
Also ich fände es zumindest etwas überraschend, wenn ein Stil irgendwelche Ressourcen anderer Anbieter einbindet, und würde zumindest erwarten, darüber informiert zu werden, um überprüfen zu können, ob sich der Stil für meine Zwecke eignet, und was ich ggf. beim Einsatz alles beachten muss. Hier sehe ich den Ersteller in der Pflicht.
Also ich fände es zumindest etwas überraschend, wenn ein Stil irgendwelche Ressourcen anderer Anbieter einbindet, und würde zumindest erwarten, darüber informiert zu werden, um überprüfen zu können, ob sich der Stil für meine Zwecke eignet, und was ich ggf. beim Einsatz alles beachten muss. Hier sehe ich den Ersteller in der Pflicht.
Naja, nur weil man etwas erwartet, heißt das lange nicht, dass er es tun muss.
Wie heißt es so schön, wenn man online was kauft soll man auch die Kommentare lesen. 
Ich weiß ist jetzt nicht so hilfreich aber da wäre er fündig geworden.
Quote
Ja, die verwendeten Fonts werden noch aus Google geladen. Das liegt daran, dass wir in diesem Stil zwei Fonts verwenden, die von WoltLab noch nicht unterstützt werden.
Ein Stil ist nun einmal weder ein Template noch ein Style noch ein Theme.
FYI: Stil ist identisch mit Style, nur einmal der deutsche und einmal der englische Begriff. Theme kommt meistens aus dem WordPress-Umfeld und meint damit aber dasselbe wie ein Stil/Style. Das einzige, was wirklich etwas anderes ist, ist ein Template.
Um hier mal etwas Licht ins Dunkle zu bringen:
Korrekt ist, dass es ab 5.3 standardmäßig eine Funktion gibt, um im Stil eine WebFont lokal über die eigene Installation ausliefern zu lassen. Der verwendete Stil stammt grundsätzlich noch aus der Zeit vor 5.2, bei der diese Möglichkeit nicht bestand. Bei der Prüfung von Updates konzentrieren wir uns vor allem auf Änderungen, weshalb die Relikte in Form der eingebundenen Fonts nicht direkt aufgefallen sind.
Hintergrund ist, dass die Funktion bei Stilen nur den Namen der Schriftart erwartet, wie dies auch in den Vorversionen der Fall war. Nur führte dies vorher dazu, dass dynamisch die Font von Google eingebunden wurde und seit 5.3 eben lokal ausgeliefert wird.
Don’t have an account yet? Register yourself now and be a part of our community!
