Beiträge von 1a-Spielwiese

https://wordpress.org/themes/

Das zweite AddOn heißt vielmehr: Dust-Me-Selectors

PS.:

Das von mir bevorzugte AddOn heißt im übrigen nicht Spider this Side, sondern vielmehr Dust-Me-Selectors:

https://addons.mozilla.org/en-US/firefox/…t-me-selectors/

Zitat

Kann mir jemand den Unterschied nennen zw. Kostenlos und Premium ?

Na, "kostenlos" oder nicht "kostenlos"!

Wenn Du gerade auf dem Design eines bestimmten Premium-Themes stehst (und kein ähnliches kostenloses findest), dann wirst Du zahlen müssen...

Wenn Dir eines der kostenlosen gefällt, dann dürftest Du damit gut bedient sein.

CSS Usage versus Spider this Page

Zitat

eine extension welche sich CSS Usage nennt -> https://addons.mozilla.org/de/firefox/addon/css-usage/

So, ich habe sie inzwischen ausprobiert und bin leider nicht besonders gut mit zu Recht gekommen, habe aber dadurch etwas anderes (Spider this Page) gefunden, was mir deutlich besser gefällt.

Erst einmal zu CSS Usage:

• Ich fand es nicht besonders intuitiv zu benutzen (das geht mir aber mit dem ganzen Firebug so. Insofern kommen diejenigen, die mit Firebug gut zu Recht kommen, vielleicht auch mit CSS Usage gut zu Recht.)

• Recht müheselig ist - erwartungsgemäß -, dass jede Seite einzelnen aufgerufen werden muss.

• Das Analyseergebnis wird in nur einer Liste - farblich unterschieden in "seen", "before seen" und "unseen" (was anscheinend bedeutet: "auf der aktuellen Seite in Benutzung gefunden", "vorher in Benutzung gefunden" sowie "nicht in Benutzung gefunden" bedeutet) - angezeigt.

• Bei Export mit Kopieren/Einfügen gehen die Farbmarkierung aber verloren. Mit der 'richtigen' Exportfunktion bin ich nicht zurecht gekommen.

Auf der Suche nach einer Hilfe-Seite für CSS Usage bin ich dann auf eine Empfehlung für Spider this Page (ebenfalls ein Firefox AddOn) gestoßen.

• Dieses Tool analysiert die ganze Seite auf einmal - aber ausschließlich der Subdomains (was in meinem Fall etwas unpraktisch, aber aufgrund des weitgehend einheitlichen Designs auch nicht so problematisch ist).

• Seine Benutzung erschloss sich für mich deutlich intuitiver.

• Das Analyseergebnis wird in Form zweier Listen ("Used" und "Unused") ausgegeben.

• Der Export war auch bei diesem Tool nicht ganz einfach: Offiziell ausgegeben wird das Ergebnis als csv-Datei, mit der ich nicht so richtig etwas anfangen konnte. Die Kopieren/Einfügen-Methode funktionierte dann besser: In Word den Text - unter Verwendung von Tabstops als Trennzeichen - in eine Tabelle umwandeln lassen.

Resultat:

Von meinem Reddle-Theme sind nur 126 Selektoren benutzt, aber 342 unbenutzt. In meinem Child-Theme (das nicht nur geänderte Reddle-, sondern auch geänderte BuddyPress-style-Definitionen enthält) ist das Verhältnis 87 : 28.

Dass auch in meinem Child-Theme unbenutzte style-Definitionen sind, liegt daran, dass ich in Fällen wie

body,
button,
input,
select,
textarea {
    font-size: 13px;
    font-size: 1.3rem;
    font-family: Verdana, sans-serif;
}

die gewünschte Änderung - im Interesse der Einheitlichkeit - gleich in Bezug auf das ganze 'Paket' vorgenommen habe.

@ Deinhard:

Zitat von Laperinni

[size=10][FONT=arial] wird bei der Aktualisierung Hostname, FTP Zugangs-Name und Passwort verlangt. Habe alles mögliche ausprobiert, bis jetzt erfolglos.

Ich verstehe das so, dass Laperinni seine Zugangsdaten nicht (mehr) kennt oder hat. - Aber da können wir ihm auch nicht weiterhelfen, sondern nur sein Provider.

Danke.

Zu den Einzügen: ja, funktioniert - mit Leerzeichen hinter dem Doppelpunkt habe ich es gleich mal gemacht.

Zu der Überschrift und der Blase: 60px war immer noch etwas eng; ich habe jetzt aber gefunden, wie sich die Blase ganz nach rechts (und ein kleines Stück weiter nach unten) setzen lässt:

.comments-link {
  position: absolute;
  top: 2px;
  right: 0;
}

Und dann reichte für die Überschrift das:

.entry-title {
  margin: 0 55px 0 0;
}

@ pixselig:

Zitat

CSS verlangt vom Clientsystem relativ wenig Ressourcen (zumindest wenn es nicht wirklich SEHR VIELE, sich wiedersprechende und überschreibende Angaben gibt). Auch der Dateigrösse hält sich meist in Grenzen (vorallem wenn die CSS Datei minified wird), ausserdem wird sie, bei richtiger htacces-Definition, auf dem Clientsystem gecached.

Ja, Danke. Das hatte ich mir schon gedacht. Es geht mir weniger darum. Es geht mir vielmehr darum, dass ich selbst mehr Übersicht über mein Stylesheet haben will - um es weiter zu verändern.

Z.B. kommen im Original-Stylesheet diverse unterschiedliche Farben vor; ich habe auch noch ein paar neue eingeführt. Und ich würde die Zahl gerne auf - sagen wir - fünf (für Schrift, Rahmen und Hintergründe) reduzieren.

Bei einer style-Definition, die eh nicht in Verwendung ist und die ich auch selbst nicht benötige, würde ich mehr gerne sparen zu überlegen, wie sie in mein (Farb-)Konzept passt, sondern sie einfach rausschmeißen.

Nein, die aktuelle Übersetzung ist nur unvollständig.

Das liegt zum einen daran, dass in der neuen BuddyPress-Version ein paar neue Begriffe dazugekommen sind; was logisch ist.

Und es werden komischerweise einige Begriffe, die schon mal übersetzt waren, nicht mehr auf Deutsch angezeigt.

Es geht also zum einen darum, die neuen Begriffe zu übersetzen - damit alle davon etwas haben, sollte das dort gemacht werden:

https://translate.wordpress.org/projects/buddy…default?filters[status]=untranslated

vgl. https://buddypress.org/support/topic/…ge/#post-198025

Leider blieb aber meine Frage unbeantwortet, ob es eine bestimmte 'Übersetzungs-policy' (für WordPress im allgemeinen oder BuddyPress im speziellen) gibt - also bspw. hinsichtlich in Betracht kommender Übersetzungsalternativen oder Schreibweisen. -

Und es müsste geklärt werden, warum von der aktuellen BuddyPress-Version einige der bereits existierenden Begriffs-Übersetzung ignoriert werden.

----

Ansonsten ist es nur so, dass die Sprachdateien jetzt in einen anderen Ordner sollen: nicht mehr im BuddyPress-Verzeichnis, sondern in ein WordPress-Verzeichnis:

Zitat

po/mo files goes into wp-content/languages/buddypress-xx_XX.mo – when the translation file is in this directory, glotpress will automatically update the file, like it does for wordpress. (under condition your language exist and is fully translated).
if you use a custom translation, add YOUR po/mo version to this directory, so it won’t be updated and your work remains intact until you decide to update it yourself.
wp-content/languages/plugins/buddpress-xx_XX.mo | po

https://buddypress.org/support/topic/…ge/#post-197890

Ich würde mein Stylesheet gerne zwecks Gewinnung von mehr Übersicht entschlacken. - Daher die Frage:

Gibt es Tools, die die php-Dateien meines Themes und meinen Plugins-Ordner durchsuchen und automatisch feststellen können, welche Style-Definitionen darin verwendet werden?

Dann würde ich anschließend alle Definition, die bisher nicht in Verwendung sind und die ich auf absehbare Zeit auch nicht selbst nötige, um Artikel und Seiten zu formatieren, aus meiner style.css herauswerfen wollen.

@ Gerd-E. / http://forum.wpde.org/plugins-und-wi…html#post580605 :

Müsste das auch mit

PermanentRedirect  /die-teams/ http://1a-spielwiese.de/mitglieder/?bp_profile_search&field_124=Team

oder

PermanentRedirect  /die-teams/ /mitglieder/?bp_profile_search&field_124=Team

gehen? - Beides ruft bei mir die Fehlermeldung:

Zitat

"The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there was an error in a CGI script."

hervor.

Vgl. auch: http://forum.wpde.org/konfiguration/…html#post580063. -

Und spricht etwas gegen meine dort:

http://forum.wpde.org/konfiguration/…html#post580145

beschriebene 'Notlösung'?

Ist das so:

Zitat

I also suggest you don’t use the <meta http-equiv=”refresh” … > technique. Since it tries to “hide” the real URI of a page, search engines could blacklist your site.

http://dontdream.it/support/topic/…-page-template/

? - Und hätte ich mit anderen 'Lösungen' für das gleiche Ziel auch das gleiche Problem? Oder ließe sich das Problem umgehen, aber mein Ziel trotzdem erreichen?

Hier noch ein Bildchen, wie's aussehen soll:

http://1a-spielwiese.de/wp-content/upl…te_Einzuege.jpg

Die Absätze 2 und 3 eines jeden Aufzählungspunktes sollen nicht nur mit ihrer ersten Zeile, sondern auch mit ihren weiteren Zeilen rechts der roten, senkrechten Linien beginnen.

Es geht um solche Aufzählungen:

http://1a-spielwiese.de/2014/10/14/tes…etzen-bestehen/

Das Problem (incl. erster ursprünglicher, aber falscher Problemdiagnose) ist im letzten Absatz beschrieben; davor ist nur Blindtext.

In meinem Stylesheet steht im Moment:

ul, ol {
    margin: 0 0 0 3.23em;
}


ind_left {
    margin: 0 0 0 3.23em;
}

Die jeweils ersten Absätze meiner drei Aufzählungspunkte sind korrekt mit

<ul><li>

sowie

</li></ul>

geöffnet und geschlossen, die folgenden Absätze mit

<ind_left>

und

</ind_left>

.

In Bezug auf die ind_left-Absätze hatte ich es zuvor mit den gleichen Werten, aber einem padding statt eines margin versucht - funktionierte aber auch nicht, wie es soll.

In beiden Fällen wird von meinem bevorzugten Browser (Firefox 32) nur die erste Zeile statt des ganzen Absatzes eingezogen. Das gleiche gilt für Opera 22. IE 8 nimmt gar keinen Einzug vor.

(Ich möchte das erreichen, was in Microsoft unter Format/Absatz "Einzug" - im Unterschied zum "Sondereinzug" - genannt wird.)

PS.:

Anderes Problem, das mir dabei noch aufgefallen ist: Wie kann ich verhindern, dass die Überschrift in die Blase mit der Anzeige der Kommentar-Anzahl hineinfließt?

Nein, gibt's nicht mehr. - Das, was statt dessen angeführt wurde, funktioniert nicht richtig.

Siehe dort:

http://forum.wpde.org/buddypress/133…html#post579011

und den dort genannten Link - hilft zumindest ein bißchen weiter.

Ja, klappt jetzt. Danke noch mal.

Nee, der Vorschlag funktioniert nicht. Dann rutscht mir die fragliche Zeile in die erste Zeile des Beitrags-Textes. -

Ich bleibe also bei der ersten Variante und melde mich noch mal, falls mir später an anderer Stelle Probleme auffallen.

Danke - funktioniert:

http://1a-spielwiese.de/2014/09/21/was-wir-noch-tun-wollen/

Ich habe auch bemerkt, warum

[COLOR=#ff0000]clear: both;[/COLOR]

an der zweiten Stelle, die Du mir geschrieben hast, notwendig ist. - Nun gibt es ja aber

.entry-content, .entry-summary

in meinem Parent-Theme schon - bisher aber ohne

[COLOR=#ff0000]clear: both;[/COLOR]

.

(Wie) kann ich in solchen Fällen voraussehen, ob solche Änderungen/Ergänzungen an anderen Stellen meines Blogs Auswirkungen haben, die ich dort gar nicht haben möchte?

Zitat

hast Du dem Text innerhalb des Elements gesagt, dass es Rechts stehen soll

Heißt das, dass das Text - terminologisch - niemals selbst ein Element, sondern immer nur in Elementen enthalten sein kann? Oder hängt das irgendwo von ab, ob es so oder so ist?

Ansonsten habe ich jetzt unten die alte Zeile "Posted in Installations- und Design-Protokoll" gelöscht und "Edit" in "Bearbeiten" umbenannt. Die für Letzteres einschlägige Zeile ist:

<?php edit_post_link( __( 'Edit', 'reddle' ), '<p class="edit-link">', '</p>' ); ?>

Hat "reddle" ("Reddle" ist der Name meines Themes) an dieser Stelle irgendeine Funktion oder könnte ich das auch einfach streichen oder durch "reddle-child" (*) ersetzen?

(*) Das "Simple Costum CSS"-Plugin verwende ich nur zum Ausprobieren; die endgültigen Sache verschiebe ich dann in die style.css meines Child-Theme.

Es geht dort:

http://1a-spielwiese.de/2014/09/21/was-wir-noch-tun-wollen/

um die Zeile:

"Am 21.09.14 in der Kategorie Installations- und Design-Protokoll veröffentlicht"

Mit:

post-header {
      padding: 5px;
      background: #DCDCDC;
    text-align: right;
}

im "Simple Costum CSS"-Plugin und:

<post-header>
        <?php if ( 'post' == get_post_type() ) : // Hide category and tag text for pages on Search ?>


            <?php if ( $categories_list && reddle_categorized_blog() ) : ?>


            Am <span class="day"><?php the_time( 'd' ); ?>.</span><span class="month"><?php the_time( 'm' ); ?></span>.<span class="year"><?php the_time( 'y' ); ?></span> <?php printf( __( 'in der Kategorie %1$s ver&ouml;ffentlicht', 'reddle' ), $categories_list ); ?>


            <?php endif; // End if categories ?>
        <?php endif; // End if 'post' == get_post_type() ?>


    </post-header>

in der einschlägigen .php-Datei, wird mir die Zeile wunschgemäß mit grauen Hintergrund angezeigt, aber nicht rechtsbündig.

Füge ich versuchsweise in die fragliche php-Datei am Anfang und Ende der Zeile ein:

<p> Meine Zeile. </p>

wird mir die Zeile wunschgemäß rechtsbündig, aber ohne grauem Hintergrund angezeigt. -

Was muss ich machen, damit mir die Zeile sowohl rechtsbündig als auch mit grauem Hintergrund angezeigt wird?

@ pixselig / http://forum.wpde.org/design/134028-…html#post579348:

Offtopic noch mal wegen:

Zitat

"PS: schaue dir mal deinen Header bei einem grösseren Monitor an. Bei mir (1920*1080) sieht der echt nicht gut aus."

Ich habe mich jetzt mit meinem Header befasst; im Moment soll es so:

http://1a-spielwiese.de/wp-content/upl…FF32-normal.jpg

aussehen (vgl.: https://wordpress.org/support/topic/…=4#post-6112471).

Wie sieht denn das bei Deinem großen Display aus?

-----

Und zwischendurch hatte ich das probiert:

https://wordpress.org/support/topic/…18#post-6108892 (vgl. auch den folgenden Kommentar). -

Und das:

https://wordpress.org/support/topic/…18#post-6108920

habe ich noch nicht probiert, weil ich dann erst einmal mit der jetzigen Version rumgespielt hatte. - Falls ich mich am Ende gegen Javascript entscheide oder auch die jetzige Variante bei großen Displays nicht so aussieht, wie sie aussehen soll, werde ich die zuletzt genannte Variante noch ausprobieren.

So:

1. mit Dank an emilyTK:

Das - stylesheet-widrige - Vorhandenseinsein von Serifen bei 'normalem' Text im Internet Explorer 8 erklärt sich daraus, dass dieser nicht in der Lage ist, die Zeile

font: 1.3rem Verdana, sans-serif;

zu verarbeiten. Wird diese Zeile in

font-size: 13px;
font-size: 1.3rem;
font-family: Verdana, sans-serif;

aufgelöst, verschwinden die Serifen bei 'normalem' Text auch im IE8 stylsheet-gemäß.

2.a) Selbst bemerkt: Bei Firefox 32 fehlen die Serifen bei Überschriften nur dann stylesheet-widrig, wenn die - sicherheits-optimierte - Version JonDoFox verwendet wird. Bei Verwendung des Default-Profils werden die Überschriften-Serifen dagegen stylesheet-gemäß korrekt angezeigt.

b) Auch ansonsten ist die Darstellung bei beiden Firefox-Varianten ziemlich unterschiedlich: Die Default-Variante benötigt deutlich mehr Platz: Aus einem einzeiligen Header-Menü wird eine zweizeiliges Header-Menü; bei längeren Absätzen werden zusätzliche Zeilen benötigt:

https://wordpress.org/support/topic/…18#post-6111991

c) Ich habe daher nun im englisch-sprachigen Reddle-Support-Forum gefragt, was alles von der JonDo-Variante 'weggefiltert' wird und ob es Möglichkeiten gibt, die gleichen Effekte auch sicherheits-unbedenklich zu erzeugen, bzw. was - umgekehrt - aus dem Reddle-Theme entfernt werden müsste, um auch Leute, die die Default-Variante von Firefox verwenden, nur Unbedenkliches und das gleiche Erscheinungsbildung wie bei der JonDo-Variante zu bieten:

https://wordpress.org/support/topic/…18#post-6111865

Gut, Danke. Dann bin ich im Bilde.

Dann lasse ich das - da ich für 8 Euro niemanden zum Arbeiten veranlassen möchte - für meine Spielwiese erst einmal sein. -

Und diejenigen, die meine Spielwiese begutachten werden und (mit mir zusammen) entscheiden müssen, ob daraus mal etwas 'Richtiges' werden soll, sollen sich erst einmal überlegen, ob sie denn ihrerseits das von mir für sinnvoll gehaltene Feature überhaupt für nötig oder zumindest nützlich halten.

PS.:

Um das mal hier auszuplaudern - das Ganze ging von einer Idee von einigen Leuten (mich eingeschlossen) aus, was wir gerne hätten. Ich habe aufgrund meiner Erfahrungen mit wordPress.com und anderen Blog-Communities, die auf WordPress basieren, die Idee beigesteuert, dass sich das, was wir gerne hätten mit WordPress relativ einfach und kostengünstig realisieren lassen könnte.
Und da die anderen noch weniger Ahnung haben als ich und wir kein Geld für ungelegte Eier ausgeben wollen, blieb es an mir hängen, mal auszuprobieren, wie dicht denn die Wirklichkeit an den Wunsch herankommen kann und welche neuen Wünsche bei dem Arbeiten an der Wunsch-Erfüllung noch entstehen.
Und eigentlich läuft es ganz gut, auch wenn's zeitaufwendiger ist als gedacht - aber das ist die Wunscherfüllung ja meistens. -

Und als eventuelle künftige Blog-Netzwerk-Betreiber/innen wollen wir an unseren künftigen hoffentlich-Benutzer/innen kein Geld verdienen, weshalb es kostengünstig sein soll.