Re: [TYPO3-german] TYPO3 7.6 - wie Frontend-Login per IP-Adresse?

[Schuler, Stephan]

Hallo zusammen.

Ich unterstütze den Vorschlag von Alex.

Ich hätte zwar den Service leicht anders umgesetzt. Bei mir würde kein
"Early Return" nur IP-baiserte treffende Benutzergruppen liefern sofern es
welche gibt sondern ich würde ein "array_merge" der regulären Gruppen mit
den IP-basierten bereitstellen. Damit erhält man sich die Möglichkeit des
fe_logins für später.

Abgesehen von dieser Kleinigkeit halte ich aber die Idee, IP-basierte
Benutzergruppen für die Anzeigebeschränkung zu verwenden für eine nette
Idee.
Die fe_groups lassen sich bei Bedarf als Condition im TypoScript mit
formulieren, wenn sie einmal berechnet sind dürften sie kein Show-Stopper
für das Caching darstellen und Redakteure sehen im Backend per verändertem
Icon zu jedem Inhaltselement dass hier ein Zugriffsschutz besteht. Und dem
Redakteur ist der Workflow über das "Access"-Tab im TYPO3-Backend
vielleicht sogar schon bekannt.

Einzig ob man sich dabei dann vielleicht mit "Show at any login" und "Hide
at login" ins Knie schießt wäre zu prüfen, sowohl was das Setting in
tt_content und pages als auch eine vergleichbare Prüfung via TS. Ich bin
mir jedenfalls nicht zu 100% sicher, ob ein per IP berechtigter Request
sofort einen eingeloggten oder nicht-eingeloggten Benutzer bedeuten soll.
Das dürfte im Zweifelsfall von der konkreten Anforderung abhängen.

Beste Grüße,
  Stephan.


Am 25. April 2017 um 19:20 schrieb Ralf-Rene Schröder :

> Am 25.04.2017 um 12:18 schrieb Frank G.:
> > Das wäre aber nur theoretisch eine Lösung. Praktisch müssen die
> > Redakteure direkt beim Erstellen neuer Seiten/Inhaltselemente einstellen
> > können, was nur intern sichtbar ist. Und die kann ich ja kaum im
> > Template herumfummeln lassen...
>
> davon hatte ich ja auch nichts geschrieben (exakter lesen)...
> du könntest aber im Template eine Area haben die NUR für intern ist
> (z.B. unter oder oberhalb des normalen Contents)
> sowas ist z.B. mit BackendLayouts leicht einzurichten...
> und ALLES was da DRIN ist wird nur für die eignen IPs ausgegeben.
>
> --
> image[FORMAT] - Ralf-René Schröder
> http://www.image-format.eu ... Wir geben Ihrem Image das richtige Format
> ___
> TYPO3-german mailing list
> TYPO3-german@lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
>
___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Seitentypen, mögliche Inhalte und mögliche Unterseiten

[Schuler, Stephan]

Hallo Bastian.

Zunächst möchte ich auf die Aussage von Mark kontern, TYPO3 wäre dazu da,
Redakteuren Freiheiten zu geben anstatt sie zu beschränken. "Der Form nach"
hat Mark natürlich Recht. Würden wir Kasper fragen geht es sicherlich um
Freiheit. Aber meine persönliche Erfahrung zeigt, und damit bin ich nicht
alleine, dass man Redakteuren Grenzen setzen muss. Die Schwierigkeit bei
der Umsetzung von Webseiten mit TYPO3 liegt nicht im HTML, nicht in
TypoScript, nicht in Fluid und nicht in Plugins. Es geht vielmehr darum,
ein sinnvolles Zusammenspiel aller Möglichkeiten die TYPO3 bietet in einer
Form zu konfigurieren, sodass einerseits dem Redakteur die notwendigen
Freiheiten für seine Arbeit zur Verfügung stehen, andererseits aber alle
Regeln des Layouts eingehalten werden, mitsamt der dadurch definierten
"dont's".

Es geht also *doch* darum, dass der Redakteur eben nicht H1 bis H5 zur
Verfügung hat sondern nur "fett", "fett und unterstrichen" und "blinkend".
Was das in Markup bedeutet oder im CSS spielt keine Rolle, wenn der
Styleguide vorgibt dass auf allen First-Level-Seiten nur diese drei
Überschriftstypen zur Verfügung stehen dürfen dann dürfen da nur die zur
Verfügung stehen. Es ist weder die Aufgabe des Integrators noch die von
TYPO3 zu bestimmen, was der Designer sich gedacht hat.

Jetzt ein paar Gedanken zur Umsetzung.

Deine Fragen sind einerseits sehr konkret, sodass ich erstens eine konkrete
Antwort geben möchte und zweitens Du auch eine konkrete Antwort erwartest,
auch wenn Du das schon verneint hast.
Auf der anderen Seite kann man ohne eine wirklich konkrete Vorgabe leider
überhaupt nicht konkret antworten, ich muss jetzt also ein Bisschen raten.
Wenn das in die falsche Richtung geht oder wenn Du gerne mehr Details
wissen möchtest musst Du auch mehr Vorgaben verraten.

Dieter hat ja bereits erzählt, dass Du sowohl den "doktype" als auch das
Seitenlayout verwenden kannst, um die globale Gestaltung einer Seite zu
bestimmen. Inhaltlich wird es bei Dir dann sowas wie "Starteseiten",
"Landing Pages", "Kategorie-Seiten" oder sowas geben. Vielleicht gibt es
auch eine Seiten-Vorlage "Event" die eine Struktur zur ansonsten
redaktionell pflegbaren Gestaltung für Veranstaltungen definiert. Welche
Typen es geben soll hängt von Dir ab, bzw. von Deinen Layoutvorgaben. Und
ebenso hängt es von den Layoutvorgaben ab, ob das Wording dazu optisch
orientiert ist (Einspalter, Zweisplter mit automatischem Menü links,
Onepager, Teaser als vollbreiter Slider) oder inhaltlich (Event, Job,
Startsite, Mitarbeiterprofil oder Produkt).

Es ist letztendlich Geschmackssache, ob Du den "doktype" erweiterst oder
das Seitenlayout dafür nutzt. Möglich ist beides.
Ein technisches Argument für den Doktype und gegen das Seitenlayout ist,
dass über dem Pagetree jeder Doktype mit seinem Icon als
"Quick-Create-Icon" aufgeführt werden kann. Redakteure können so über das
Schnellmenü direkt eine Seite des Typs "Onepager" in den Seitenbaum ziehen,
oder eben eine Seite des Typs "Teaser als vollbreiter Slider".
Ein technisches Argument gegen den Doktype und für das Seitenlayout ist,
dass das der Doktype seine ursprüngliche Funktion als inhaltliche
Unterscheidung weiterhin und unabhängig vom Layout erfüllen kann. Wenn ich
einen Doktype "Event" anlege habe ich Events mit einem fixen Layout, alle
Events müssen dem folgen. Wenn ich ein Seitenlayout "Event" anlegen kann
ich sowohl den Doktype "Page" verwenden als auch den Doktype "Shortcut"
wenn ich Events pfegen  möchte deren Inhalt gar nicht auf meiner Seite
liegt.
Es ist eben einerseits Geschmckssache und hängt andererseits von den
Anforderungen ab.

Du hast von Seiten gesprochen, die Teile ihres Inhalts von Unterseiten
beziehen. Das ist problemlos möglich. Und schon gibt es Spielraum.
Soll dieser Seitetyp *immer* seinen gesamten Inhalt von
Unterseiten beziehen? Dann braucht dieser Seitentyp überhaupt keine
Möglichkeit der Inhaltspflege im TYPO3-Backend.
Oder soll auf diesem Seitentyp möglicherweise ein redaktioneller
Einleitungstext vor dem automatischen Teil und ein weiterer redaktioneller
Schlusstext nach dem automatischen Teil erlaubt sein?
Dann kannst Du entweder ein Backend-Layout mit den zwei Zeilen "Content
Before" und "Content After" anlegen und in der Mitte den Automatismus
rendern.
Oder Du kannst eine einzige Zeile und eine einzige Spalte anlegen (es
handelt sich dabei also optisch erst mal um eine Standardseite) und dafür
ein Plugin/FCE/Grid-Element/Content-Element bauen, das vom Redakteur frei
positioniert werden kann und das im  Frontend-Rendering selbständig
Textfragmente von Unterseiten bezieht.
Ich würde die zweite Version bevorzugen. Dadurch bleibt es dem Redakteur
überlassen, ob er als Seiten-Layout jetzt den Einspalter, den Zweispalter
mit automatischem Menü links oder den Onepager verwendet, auf all diesen
drei Seitentypen kann er an einer beliebigen Stelle das Element "Render
description content of all headlines of first level children pages of this
page" platzieren.

Re: [TYPO3-german] Cross-Domain Preview in Multidomain-Projekt

[Schuler, Stephan]

Hey zusammen.

Dass die cookieDomain Kommagetrennt mehrere Werte erlauben würde ist mir
neu. Man kann meines Wissens lediglich alternativ zu einer fixen Domain
einen regulären Ausdruck hinterlegen. Das ist immer dann der Fall, wenn die
Domain mit / anfängt, wobei / dann auch der Delimiter ist. Also so was:
/(www)?\.mydomain\.com/

Das hilft allerdings häufig nicht weiter, bzw. ist sogar kontraproduktiv.

Wenn ich lediglich mydomain.com angebe, werden die Cookies auf mydomain.com
gesetzt, ich kann also diverse Subdomains damit ab handeln. So weit ist das
noch schön.
Wenn ich den oben geschriebenen Ausdruck verwende, wird der Cookie nur dann
gesetzt wenn die Domain www.mydomain.com oder mydomain.com lautet -- und
dann wird er an die spezifische Domain gebunden.

Was allerdings keinesfalls geht: mydomain.com, mydomain.de. Und zwar
grundsätzlich. Jeder Browser weigert sich aus Sicherheitsgründen ganz
einfach, einen Cookie für eine Domain zu setzen, die nicht in der
Level-Hierarchie höher liegt. Ich kann zwar von www.mydomain.com auf
mydomain.com einen Cookie legen, aber nicht von mydomain.com auf www.
mydomain.com. Das Top-Level-Glied von dieser Regel ausgenommen, auf de
oder com darf grundsätzlich niemand einen Cookie binden.

Ich kann mir zwar vorstellen, dass das mit mehr oder weniger
abenteuerlichen Zusatzscripten doch zu lösen ist. Man müsste explizit
Cookies von einer Domain an eine andere übergeben. Aber in TYPO3 integriert
ist das meines Wissens nicht.

Gruß,
Stephan.


Grüße,
  Stephan Schuler.




Am 9. April 2013 19:51 schrieb JoH asenau i...@cybercraft.de:

 Am 05.04.2013 12:24, schrieb Stephan Vidar:

  Hallo zusammen,

 innerhalb eines Multidomain-Projekt können Redakteure den Preview einer
 deaktivierten Seite nur im Baum der Domain aufrufen, über die sie sich
 auch im Backend angemeldet haben.

 Die Previews der anderen Domains enden in einem 404 - Error, da das für
 den Preview nötige Cookie für die gültige BE-Session nicht
 Domain-übergreifend ausgelesen werden kann.

 Weiß hier jemand einen Rat wie man hier Abhilfe schaffen kann?


 Soweit ich weiss kann der Parameter cookieDomain im Install-Tool so
 gesetzt werden, dass auch mehrere Domains per Regular Expression angegeben
 werden können.

 HTH

 Joey

 --
 Wenn man keine Ahnung hat: Einfach mal Fresse halten!
 (If you have no clues: simply shut your gob sometimes!)
 Dieter Nuhr, German comedian
 Xing: http://contact.cybercraft.de
 Twitter: http://twitter.com/bunnyfield
 TYPO3 cookbook (2nd edition): http://www.typo3experts.com

 __**_
 TYPO3-german mailing list
 TYPO3-german@lists.typo3.org
 http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-**germanhttp://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

___
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

Re: [TYPO3-german] Bitte um Brainstorming - Filtermenü

[Schuler, Stephan]

Hallo zusammen.


Zunächst mal hat Duplicate Content nicht die Bedeutung wie oft
angenommen: Es gibt keinen pauschalen Strafbonus wenn man Inhalt
wiederverwendet oder unter unterschiedlichen URLs anbietet. In dieser
Beziehung gibt es genau zwei Situationen die sich negativ auswirken
können:

1.: Bei bewusster Manipulation des Index wird Google Maßnahmen
treffen. Wie diese aussehen weiß nur Google, allerdings liegt der
Focus auf bewusst. Sofern der doppelte Inhalt nicht zur
absichtlichen Täuschung/Manipulation des Index erstellt wurde, greift
Google nicht zusätzlich regelnd ein.

2.: Wenn mehrere URLs den gleichen Inhalt aufweisen, kämpfen diese im
Index gegeneinander. Hier kommen dann alle sonstigen
Rankingmechanismen zum Tragen, je weniger sinnvoll/bekannt/beliebt
eine URL ist desto weiter unten wird sie im Index auftauchen, bzw. die
URL mit der größten Relevanz (häufig die einzige der vielen möglichen
die von anderen Seiten außer der eigenen, verschachtelten Menüliste
verlinkt wird) ist der für Google relevante Suchtreffer. Kurz: Google
wird aus den vielen URLs die den gleichen Inhalt präsentieren einen
möglichst sinnvollen Repräsentanten wählen und alle anderen als
unwichtig klassifizieren weil sie nichts neues bieten.

http://www.google.com/support/webmasters/bin/answer.py?hl=deanswer=66359


Zum eigentlichen Problem: Es ist also nicht wirklich
wiederverwendbarer Inhalt sondern vielmehr eine Verschlagwortung von
Seiten gewünscht. Es sollen also nicht viele unterschiedliche
Inhaltsblöcke nach Bedarf auf Seiten verteilt werden um dem Redakteur
die Arbeit zu ersparen, Inhalte mehrfach tippen zu müssen sondern es
sollen vielmehr einer Seite einzelne Schlagworte zugeordnet werden, in
Verbindung mit einem Schlagwort-Auswahlmenü als Navigationshilfe im
Frontend und einem Schlagwort-Auswahlmenü als Konfigurationselement im
Backend.

Das hierarchisch abzubilden dürfte schwer bis unmöglich sein,
insbesondere wenn es um SEO-URLs geht. Angenommen die SEO-URL enthält
die Schlagworte immer alphabetisch sortiert und ein Schlagwort immer
doppelt. Bei nur zwei Schlagwörtern ergeben sich vier URL-Varianten
(kein Schlagwort, je eines de Schlagwörter, beide Schlagwörter), bei
drei Schlagwörtern schon acht (kein Schlagwort, 3* je eines, 3* je
zwei, 1* alle drei Schlagwörter). Bei n Schlagwörtern dann 2^n
Kominationen. SEO-URLs dafür würde ich deshalb praktisch ausschließen,
das ist also kein Punkt über den wir uns groß Gedanken machen müssen.

Was der Benutzer an solch einer Stelle gerne hat ist facettierte
Navigation. Wenn er SchlagwortA angeklickt hat und es keine Treffer
mit SchlagwortASchlagwortB dafür aber 10 Treffer mit
SchlagwortASchlagwortC gibt, sollte man dem Benutzer in der
Navigation die Option von SchlagwortB überhaupt nicht geben, dafür
SchlagwortC mit dem Hinweis über die zehn zu erwartenden Treffer
geben. Siehe das Produktmenü bei Amazon.

Wenn sowas eine relevante Konfiguration ist würde ich einen Blick
Richtung Apache Solr werfen. Das geht allerdings nur ganz begrenzt
generisch, jedenfalls ist das kein Plug'n'Play-Plugin sondern benötigt
Kenntnis über die eigenen Daten sowie zusätzlich eine
Solr-Server-Instanz. Grundsätzlich ließe sich damit zwar ein
generisches Taggingsystem realisieren, allerdings hatte ich bisher
noch nicht die Anforderung, das auf tt_content zu verwirklichen.
Deshalb kann ich leider nicht mit einer fertigen Konfiguration für
tt_content dienen. Meine bisherigen Solr-Integrationen befassten sich
stets mit sehr kundenspezifischen ExtBase- oder FLOW3-Models.

Auch wenn das jetzt vielleicht ein wenig übers Ziel hinausgeschossen
ist, aber vielleicht ist es ja auch genau das richtige. Ich kenne
immerhin die Größenordnung deines Projekts nicht:
http://media.netlogix.de/community/details/artikel/apache-solr-storage-backend-for-extbase-our-little-christmas-gift-for-you
http://forge.typo3.org/projects/extension-nxsolrbackend/repository
Leider ist das zugehörige Repository zur Zeit etwas hinten dran weil
unser FLOW3-Solr-Storage und unser ExtBase-Solr-Storage dieselbe
Codebase sind und die letzten Änderungen  im FLO3-Zweig nicht so
einfach in den ExtBase-Zweig unseres Solr-Projekts einzugliedern sind.


Grüße,
  Stephan Schuler.






Am 19. November 2011 19:07 schrieb Robert Wildling robertwildl...@gmail.com:
 Allerdings musst du auch bedenken, dass bei so einem System dann alle Tags
 wieder für alle Records zu Verfügung stehen. Aber du willst bestimmte Tags
 vielleicht nur für News Records verwenden, manche nur für den Kalender,
 manche für Content Elemente und zugleich für Adressen.
 Also müsste man konfigurieren können, wo was angezeigt wird - zumindest
 wenn
 man ein Lösung für alles anstrebt. Außerdem musst du noch bedenken, dass
 verschieden Backend Benutzer verschiedene Rechte haben.
 Ach, und Workspaces gibt es auch ;)

 Ufff... das wird ja 'ne lange Kette an ifs und elses und cases undundund...

 Wie wäre es, wenn man es als CE anbietet, so wie Text And Images ein
 Content To Page