Beiträge von Demokrit

    Moin in die Runde,

    ich stehe bei einem (Luxus)problem auf dem Schlauch:

    In meinen Themes und Plugins nutze ich Sprachdateien, erstellt mit poedit. Baut man sich z.B. ein eigenes Login Form, so liegt entsprechender Code mit geeigneten Gettext Schlüsselworten (__, _e) im Plugin oder Theme-Directory. Klappt auch alles.

    Jetzt gibt es Strings, die einer eigenen Übersetzung bedürfen, und andere, die bereits im Core stimmig übersetzt wurden. Übersetzt man diese erneut, schafft man unsinnige Redundanz.

    Auf Seiten WP ist das einfach, denn es gibt die Textdomain, also:

    PHP
    <?php _e('Log in', 'myPlugin'); ?>

    Lässt man die Textdomain (myPlugin) weg, und existiert ein entsprechender Eintrag in den Core Lokalisierungen, so kommt "Anmelden" statt "Log in". Bon.

    Wie bringe ich poedit dazu, die Textdomain auszuwerten? Ist keine angegeben, so soll auch nix in die eigene .po Datei wandern. Ein Schlüsselwort wie "Lass die Finger davon, Übersetzung ist anderswo geregelt".

    Bin für allen Input dankbar.

    Grüße,

    Thomas

    Ja, danke, diesen Beitrag hatte ich bereits an verschiedenen Stellen und in ähnlichem Kontext gefunden. Die Lösung empfinde ich als cryptischen Overkill. Alles wäre banal einfach, wenn der attribute Filter tatsächlich die Attributes behandeln würde (und title ist eines von ihnen), ohne hart verdrahteten Titel direkt im Anschluss.

    Eigentlich ist dies wohl eher ein harter bug.

    Moin zusammen,

    ich nutze comments_popup_link(), um unter dem angetexteten Beiträgen auf der Index Seite Direktlinks in den Kommentarbereich zu ermöglichen.

    Wenn ich bei einem Beitrag, der bereits Kommentare enthält, die Kommentarfunktion (für diesen Beitrag) deaktiviere, so möchte ich natürlich weiterhin den Link auf die bereits vorhandenen Kommentare. Klappt auch. Lediglich der Title dieses Links ist total daneben "Kommentiere <Beitragstitel>". Dies wäre ok, wenn das Kommentieren noch möglich wäre. Bei abgeschalteten Kommentaren müsste der Titel natürlich anders erzeugt werden, z.B. "Kommentare deaktiviert".

    Es gibt zwar einen Attributes Filter (comments_popup_link_attributes), aber wie es ausschaut, wird das Title Attribute danach wieder überschrieben. Übersehe ich hier vielleicht etwas Wesentliches?

    Grüße,

    Thomas

    Danke für den Hinweis. "CommentLuv" ist zwar aus dem UK, aber gerade deshalb leider ebenso zweifelhaft, wie US-Services. Zudem ist es (sehr) kostenpflichtig.
    Ansonsten passt noch "IntenseDebate", dessen Daten aber leider auch im (rechtsfreien) Raum lagern.
    Eigentlich ist das alles ein Armutszeugnis für Europa.

    Moin in die Runde,

    ich bemühe mich, mein im Entstehen befindliches Blog zugänglich und nach Europäischen Datenschutzstandards (die ja zumindest noch auf dem Papier bestehen) aufzubauen. Integration in Social Media möchte ich bieten (für die, die's brauchen), ein automatisches Tracking der Nutzer werde ich aber über ein eigenes Plugin (ähnl. Social Share Privacy) verhindern. Bis hier steht alles.
    Was bleibt ist das Problem der Kommentare. Nutze ich interne Kommentarfunktionen von WP, so ersaufe ich entweder im Spam, muss Nutzer zur Registrierung nötigen, oder weiche meine "Do not track me" Policy durch US-basierte Services, wie Akismet, wieder auf. Am liebsten würde ich meine Kommentare per Web Service abhandeln (wie z.B. per Disquss - leider erneut US-basierend). Dann quillt auch nicht die Datenbank sinnlos über.

    Jetzt meine Frage: Kennt ihr einen Europäischen Webservice für Kommentare, der auch ein Nesting erlaubt? ("Juvia" z.B. klingt toll, ermöglicht aber leider kein Nesting). Es muss keine WP Integration verfügbar sein. Die schreibe ich bei Bedarf selbst.

    Danke für allen Input

    Grüße,

    Thomas

    Du kommst sehr einfach an die unterschiedlichen Uris der Bilder:

    PHP
    $large_image_url = wp_get_attachment_image_src(get_post_thumbnail_id(), 'full');
    $url = $large_image_url[0];

    Damit liest Du nacheinander alle erforderlichen Größen aus, und bastelst Dir einen figure tag. Das ist kein großes Ding.

    ABER:

    vergiss es besser - zumindest vorerst.

    Du versuchst etwas zu implementieren, was zwar seit langem im W3C im Gespräch ist, aber noch lange nicht verbindlich verabschiedet wurde. Die Browserunterstützung ist eher als "experimentell" anzusehen. Ich habe mit genau diesem Ansinnen bei TYPO3 6 Monate verdampft. Am Ende hat's geklappt - abgesehen von den Browsern.

    WP scheint mir übrigens auch völlig ungeeignet für diesen Ansatz. Dazu benötigst Du ein CMS mit einem Digital Assets Management. Dies erlaubt dann natürlich auch die Mehrfachnutzung einzelner Assets.

    Das Errorlog hat nichts mit den Statistiken zu tun. Komplett andere Baustelle. Wordpress ist eine Anwendung. Wenn diese ein Bäuerchen kriegt, weil z.B. eine der erforderlichen Grundparameter zu gering oder falsch eingestellt ist, so schreibt die Anwendung eine Fehlermeldung in's error_log. Auf dem Bildschirm ausgegeben wird diese i.d.R. nicht, da sicherheitsrelevante Dinge in der Meldung stehen könnten.

    Ohne Zugang zu einem solchen Error Log ist Webhosting sinnlos. Vermutlich wird man das Log über irgend eine Verwaltungsoberfläche des Hosters einsehen können.

    Direkter Zugang zur php.ini ist nicht erforderlich. Was drin steht, kann man über phpinfo ausgeben. Für die Lösung Deines Problems sind diese Daten erforderlich.

    Sollte einer der php.ini Parameter nicht passen, so kann man sie über .htaccess im Webroot (in Grenzen) anpassen.

    Du wirst Dich also entweder tiefer mit diesen Dingen beschäftigen, oder Deinen Hoster um Hilfe bitten müssen. Ich halte ein gepflegtes Basiswissen über den Server für unerlässlich.

    All diese erforderlichen Kenntnisse kann man sich aber aneignen. Alles ist quelloffen und bestens dokumentiert. Und legale Hürden bringen alle Unternehmungen mit sich. Auch die sind zu meistern.

    Der technische Einstieg in WP erschien mir vergleichsweise einfach, verglichen mit anderen Plattformen. Eine wesentliche Frage sollte also wohl eher sein: Ist Wordpress eine gute Basis für einen Freelancer mit Zielmarkt Small Business?

    WP ist flott, als CMS geeignet und als Blog sowieso. Für einen gewerblichen Einsatz in Europa hat es jedoch einen gravierenden Makel. Fehlende (seriöse) Mehrsprachigkeit. Ist diese im Zielmarkt nicht relevant, so erscheint mir WP gut geeignet. Bleibt die Betriebssicherheit. WP Sites werden gerne gehackt. Dies mag aber auch an der Art der typischen User liegen, denen ein Wissen um einen sicheren Serverbetrieb abgeht. Hier darf man sich als professioneller Anwender keine Blöße geben, sonst wird's schnell teuer.

    PHP 5.3.7 läuft bei mir als fcgid/suexec. Kann an dieser Stelle aber nicht ursächlich sein, denn jedwede andere Funktionen klappten ja. Es scheint sogar so, als würde NUR die Default Einstellung der Permalinks zu besagtem Problem führen. Da ich sowieso nicht vor hatte, mit den unschönen URLs auf Sendung zu gehen, kann ich erst mal mit dem minimalen Restproblem leben.

    An anderer Stelle habe ich gelesen, dass paginate_comments_links() sehr eng mit wp_list_comments() verzahnt ist. Ich nutze natürlich wp_list_comments(), aber mit einem eigenen Walker. Vielleicht hat sich hier zwischen 4.0 und 4.1 etwas verändert? Der Walker klappt zumindest weiterhin.

    So, bin einen entscheidenden Schritt weiter. Mein Entwicklungssystem stand noch auf "Standard" hinsichtlich der Permalink Struktur, also

    Code
    [URL]http://www.mydomain.com/?p=123[/URL]

    Nach Umstellung auf "Beitragsname"

    Code
    http://www.mydomain.com/Beispielbeitrag/

    klappt die Paginierung der Kommentare auf Anhieb.

    Da der einzige Unterschied zwischen beiden Varianten der "base" Parameter ist, vermute ich das Problem im

    Code
    add_query_arg( 'cpage', '%#%' )

    . Genau dieser Parameter wird bei den Links in "Permalinks-Default" Einstellung falsch gesetzt.

    Vielleicht hilfts ja wem.

    Nein, WP nutze ich ausschließlich für mich persönlich. Nenne es Spielwiese. Und natürlich sind mir Dinge wie SEO, Spamschutz und (mit minderer Wichtung) Social Media Integration wichtig. Nur, was ich brauche, dass schreibe ich mir selbst. Natürlich unter Zuhilfenahme existenter Plugins, von denen ich mir viel abgucke. Wie ich schrieb: Ich will WP verstehen, denn ich will mit und für WP entwickeln.

    Ein Beispiel: Mir ist Schutz persönlicher Daten wichtig. Accessibillity ebenfalls. Beides Dinge, die nicht gerade im Fokus von WP liegen. Vorhandene Implemenationen von "Social-Share-Privacy" z.B. gibt es zwar, sie scheinen aber nicht sehr lebendig. Also erstelle ich mir einen Plugin, und behalte die volle Kontrolle. Dies nicht, weil ich anderen Plugin Autoren misstraue. Ich mache es, weil ich's kann - oder genauer, weil ich's lernen will.

    Ich kann tatsächlich noch keine Langzeiterfahrung mit WP verkünden, aber ich komme aus einer Szene, in der Schreckliches alltäglich ist. Als bei TYPO3 neue Entwicklungsparadigmen eingeführt wurden, waren diese eine Rückintegration einer parallelen Neuentwicklung, die es noch gar nicht gab. In deutsch: BMW baut tolle Motorräder, und ist Marktführer. Allerdings scheint die Technik der aktuellen Produktpalette ausgereizt. Man plant also eine komplett neue Produktreihe, die mit allem bricht, was bislang zählte - UND - man beginnt, diese zukünftigen Dinge (z.B. den Fluxkompensator) scheibchenweise in die alten Produkte einzubauen, was diesen nicht bekommt. Entwickler wissen, mit dem alten Kram ist kein Blumentopf mehr zu gewinnen. Also streichen sie entweder die Segel, oder sie programmieren nach neuen Paradigmen weiter. Mittlerweile hat man im (virtuellen) Zukunftsprodukt jedoch festgestellt, dass Fluxkompensatoren nicht klappen - und hat die Entwicklung gestoppt. Zwischendurch stellte noch irgend ein Cleverle fest, dass man noch schnell sämtliche bisherigen Lokalisierungsmittel austauschen könnte. Heute po, morgen XML, übermorgen Xliff. Dann noch die Coding Standards geändert - mehrfach. Die Doku bleibt selbstredend auf der Strecke, und eventuell vorhandene Tutorials von 2013 sind 2014 vollkommen unbrauchbar. Ich vergas zu erwähnen, dass man auch die Entwicklungsumgebung neu geschrieben hat. Extbase - darauf hat die Welt gewartet. Heute so, und morgen anders.

    Kommt man aus dieser Welt, so wirkt WP paradiesisch. WP scheint vergleichsweise banal, aber dafür gut dokumentiert. Mehr wollte ich nicht ausdrücken.

    Die Suche in meinem Blog klappt übrigens einwandfrei. Zwischen 4.0 und 4.1 ist mir jedoch meine zeitgemäße Kommentar Paginierung verloren gegangen. Next/Prev geht, aber nicht mehr paginate_comments_links(). Da diese Funktion bei Anderen noch klappt, weiß ich, dass ich in meinem Code suchen muss. Ein großer Vorteil.

    Klar. Ich nutze nur einen Plugin, und der ist von mir. Auch das Theme ist ein eigenes. Weder Plugin noch Theme verändern Dinge in diesem Bereich. Auch eine Aktivierung von Twentyfourteen (mit temporärem Einbau von paginate_comments_links() führt zum gleichem Ergebnis.

    Zu den Links: ALLE stimmen auf der ersten Seite
    KEINER stimmt auf den Folgeseiten (ausser current).

    Ich vermute einen Bug. Auf der ersten Kommentarseite ist der URL Parameter "cpage" gar nicht gesetzt (warum sollte er auch?). Auf den Folgeseiten wird er gesetzt. Auf der Seite richtig, in der Paginierung falsch. Korrigiert man die cpage händisch im Link, kommt man auch wieder zurück :-)

    Vielleich könnte ja mal kurz jemand paginate_comments_links() in's comments.php Template schreiben (ohne Parameter), und gucken, ob's korrekt klappt. Falls nein, so würde ich einen Issue bei WP öffnen.

    Ich denke, eine korrekte Antwort auf die Frage kann nur erfolgen, wenn man denn weiß, was es zu pflegen gibt. Wird WP als Blog genutzt, oder als CMS. Oder gar als vergewaltigtes e-Commerce System? Welches Theme ist im Einsatz, welche Plugins? Wie gut war der/die Ersteller(in) des Themes/Plugins?

    Ich bin php Entwickler, und erst seit Juni bei WP angelangt (davor 7 Horror Jahre TYPO3). Als solcher will ich völligen Durchblick bei meinen Werkzeugen (hier: WP). Um diesen zu erlangen nutze ich NULL Plugins von Dritten ein, und arbeite mit eigenem Theme/Plugins. Sämtliche Updates seit 3.9 sind völlig "geräuschlos" und ohne besondere Ereignisse abgelaufen. Soll heißen, binnen < 1 Min.

    WP scheint extrem konservativ bei "breaking changes". Sie werden weitgehend vermieden. Dies jedoch zum durchaus hohen Preis, dass mancher olle Kram sehr lange erhalten bleibt, wie z.B. ein vorsinnflutliches Image Handling ohne Mehrfachnutzung der Assets.

    Ansonsten halte ich WP für sehr angenehm pflegbar.

    Grüße,

    Demokrit

    für das (automatische) Einbinden eines favicons sollte es reichen, dieses in's Web-Root zu kopieren. Zeitgemäße Browser suchen es dort, per default.

    Möchte man es aber über ein Theme einbinden, z.B. weil man in einer multidomain Umgebung mit verschiedenen Favicons arbeiten möchte, so gibt's dafür WP Bordmittel:

    z.B. so:

    moin zusammen,

    kann es sein, dass "paginate_comments_links()" auf 4.1 zu falschen Links führt?

    Auf der ersten Kommentarseite stimmt noch alles: z.B.

    1 2 next (alle Links korrekt, 1 ohne Link = current)

    ab der 2. Seite sieht es dann so aus:

    prev 1 2 (der Link unter "prev" und "1" verweist auf 2, also auf sich selbst)

    M.E. hat dies unter 4.0 noch funktioniert.

    Stelle ich auf next_comments_link() und previous_comments_link() um, so klappt alles - inklusive mieser User Experience.

    Wie sieht das bei Euch aus?

    Grüße,

    Demokrit

    Moin in die Runde,

    ich arbeite derzeit an den letzten Feinheiten meines Themes "Bootstrapped", welches Twentyforteen 1:1 abbildet, jedoch mit Bootstrap 3.2.0 Markup. Dazu habe ich auch sämtliche Post-Formats übernommen.

    Twentyforteen gibt (fast alle) Post-Formats einfach per "the_content()" aus. Dies bedeutet letztendlich, dass sich die einzelnen Post Formats genau so verhalten wie Standard Posts. Schreibt ein Redakteur einen neuen Beitrag und markiert diesen als Post Format "Image", so gibt dieser ein hard-codiertes Image aus, wenn dieses am Anfang des Beitrags steht. Steht da jedoch ein Video, so wird dieses ausgegeben. Auch sämtliche andere eventuell vorhandenen Seitenelemente werden bedient.

    Laut Codex soll das Post Format "Image" lediglich ein einziges Image mit oder ohne Caption ausgeben. Tatsächlich jedoch gibt das Ding alles aus, was der Redakteur reingeschrieben hat.

    Ist das "expected behaviour"? Wenn ja, welchen Sinn machen Post Formats dann?

    Danke für allen Input

    Grüße,

    Thomas