Beiträge von F-rank

if ( ! comments_open() && ! is_page() ) :           ?>
           <p class="nocomments"><?php _e( 'Comments are closed.', 'yoko' ); ?></p>           
<?php endif; // end ! comments_open() && ! is_page() ?>

Diesen Teil kannst du einfach löschen.

Grüße,
Frank

EDIT: Wenn die comments.php bei Updates überschrieben wird, wäre die Änderung "weg". Arbeitest Du eh' mit einem Subtheme?

Zitat von rainbow-warrior

Na das ist ja okay, sieht nur doof aus.

Wie genau soll es denn aussehen? Kannst du das einmal per Grafik skizzieren? Und zusätzlich am besten einen Link zur Online-Seite, wo es mit Listenpunkten noch so aussieht, wie du es gerade nicht haben willst.

Und nein: CSS ist nicht dazu da Listen-Auszeichnungen zu entfernen - es ist dazu da, sie zu formatieren. Nur weil Standart-Browser-Darstellungen Listen immer nur hässlich zeigen, heißt das nicht, dass Listen nicht so dargestellt werden können, als wäre es gar keine Liste. Das horizontale Dropdown-Menü fast jeder Website ist heuzutage in Wahrheit eine Liste. - Nun aber, ich weiß ja nicht, was dir eigentlich visuell vorschwebt...

Aber grundsätzlich ist es viel einfacher (und sicherer!) CSS zu bearbeiten, als Plugins zu installieren oder PHP-Funktionen zu schreiben. Insbesondere, wenn man dabei vermeiden kann, mit der Kirche ums Dorf zu fahren.

Auch auf die Gefahr hin, off topic zu sein:

eine Liste von Menüpunkten ist und bleibt eine Liste. Semantisch ist daran schwer etwas zu rütteln. Alles weitere könnte und sollte man mit CSS lösen, dazu ist es da.

Grüße!

Also jetzt mal ganz ehrlich: das Theme ist von bedenklicher Qualität. Tabellen-Layouts sind schon lange relativ verpönt. Bedenke, dass Handy- oder Tablet-Benutzer auch etwas vom Vergnügen haben sollten. Es sollen ja in den nächsten 1-2 Jahren noch ganz viele werden, die nur noch mit diesen Mobil-Geräten herumlaufen! Mein Rat wäre daher: suche nach einem ähnlichen Theme, aber zeitgemäßer umgesetzt, als Responsive Webdesign - geht locker auch gratis, siehe dazu auch wordpress.org

Denn jetzt kämpfst Du also in einem starren Tabellenlayout mit den floatenden DIVs, erzeugt von der WordPress-Galerie ... aber wenn rechte und linke Seite unabhängig von der Text-/Datenmenge übereinstimmen müssen (meinst Du überhaupt die Bildergalerie?), wäre (auch semantisch) nun wieder eine Tabelle wahrscheinlich am korrektesten. Eine zweispaltige Tabelle kann darüber hinaus auch responsive sein. Mit DIVs geht es sicher auch, wenn die beiden floatenden DIVs. die nebeneinanderstehen, ein Wrapper-DIV bekommen. Ganz verdrehte Welt also ... :???:

Von Tooltips würde ich hinsichtlich des Zugänglichkeitsaspekts (mobile Geräte, generelle Übersichtlichkeit) abraten. Das geht ganz sicher auch mit Touch, ist aber wieder ein anderes weites Feld.

Grüße!

Versuche doch bitte die Problembeschreibung noch einmal mit anderen Worten.

Die "Links"-Abteilung wurde offiziell abgeschafft.
Du kannst dir alternativ deine Wunsch-Links zunächst unter "Design" => "Menüs" als eigenes Menü anlegen. Danach ziehst du dir unter "Design" => "Widgets" das Widget "Individuelle Menüs" in deine Seitenleiste und dort lässt sich konfigurieren, welches der selbsterstellten Menüs du dort angezeigt haben willst.

Grüße,
Frank

Ich würde mir vor Klärung der Frage noch überlegen, ob du wirklich nicht auf Duplicate content verzichten kannst.

Tausche doch einmal in der style.css bei den @font-face-Anweisungen die Zeichenketten "glenmedia.de/vintage-days" gegen "http://www.vintage-days.de" aus ...

Du hast ja den Fehler nur, wenn du das Theme aktivierst; es sollte reichen, nur dieses versuchshalber neu zu installieren.

Wenn das dann immer noch den Fehler macht, kann es am Theme liegen: welches ist es denn? Hast du unter https://wordpress.org/themes/THEME-NAME schon mal den Reiter Support aufgesucht? Vielleicht hatten andere das Problem ja auch schon ...

Nun, im Moment lenkt http://www.vintage-days.de/blog/ auf http://www.vintage-days.deblog/ um. Und da es die TLD deblog nicht gibt, kann ich jetzt leider den Unterschied zum Direktaufruf von http://www.glenmedia.de/vintage-days/index.php nicht sehen ...

Hast du eine oder mehrere Dateien davon selbst bearbeitet? Wenn ja, mit welchem Programm? Wenn nein: Dateien löschen, nochmals downloaden u. entpacken.

Da kann dir hier m. E. keiner helfen.

Das ist direkt vom Theme abhängig, auf das man Zugriff haben müsste, um zu sehen, was da abgeht. Jedenfalls scheint bei den Vorschau-Artikeln ein Bug im Spiel zu sein, wenn da ein hardcodierter Autor erscheint und in der Vollansicht des Artikels dann wieder der richtige Autor steht. Da sollte für dich über den Themeforest-Support zum Theme etwas an Info zu holen sein - falls nicht die Startseite überhaupt hardcoddiert wurde und der Theme-Autor dafür eigentlich nichts kann.

Aber das alles kann hier wahrsch. niemand wissen ...

phpMyAdmin

Via phpMyAdmin geht's am schnellsten: geh in deine WP-Datenbank, mache bitte zuerst ein Backup (Reiter "Exportieren") - danach wähle den Reiter "SQL" und gib als SQL-Befehl ein:

UPDATE `wp_posts`  SET  `post_author`  =  '4712' WHERE  `post_author`  = 4711 AND `post_type` = 'attachment';

Falls dein Tabellen-Präfix nicht "wp_" ist, musst du das vorher an den richtigen Tabellennamen anpassen. Auch steht im Beispiel "4711" für die Altbenutzer-ID, "4712" für die ID des Benutzers, der die Attachments zugewiesen bekommen soll - die ID's sind natürlich gleichfalls vorher anzupassen ...

Tschüssss

Am sinnvollsten du deponierst einen Link zu einer realen Seite, die das Problem hat. Ohne Firebug ist (zumindest mir) das einfach zu theoretisch :smile:

Hallo,

den importierten Beiträgen fehlt das custom field views in der postmeta-Tabelle.
Am besten, Du machst ein Bulk-Edit auf alle betroffenen Artikel, setzt sie einmal alle auf Entwurf, dann Speichern und danach wieder zurück auf Veröffentlicht + Speichern. Dabei sollte das custum field initialisiert werden.

Probier's einfach erst einmal an einem einzelnen Artikel aus - da sollte nichts schiefgehen können.

Schöne Grüße,
Frank

Also mein Lösungsvorschlag: diese leidige SESSION-Datei in /tmp entweder selber löschen (falls eigener Zugriff via SSH besteht) oder aber den Hoster bitten, dies für dich zu tun.

Schöne Grüße,
Frank

Zitat von r23

Deine Anwendung möchte eine Session speichern. Die Session soll in /tmp/ gespeichert werden. Hierfür hast du verständlicherweise keine rechte auf dem Server.

Ich interpretiere die Fehlermeldung anders; eine bestehende Sesssion-Datei in /tmp darf da scheinbar nicht geöffnet werden. In /tmp darf übrigens normalerweise jeder schreiben, lesen und löschen (dazu ist der Ordner da), aber jeder strikt nur seine eigenen Dateien - was hier das Problem zu sein scheint. Deshalb habe ich im ersten Anlauf blind auf einen Benutzerwechsel getippt (PHP-Modus-Wechsel).

Falls der Provider die Anweisung zulässt (sollte eigtl. ohne weiteres gehen), würde ich in der .htaccess nun folgendes versuchen:

<IfModule mod_php5.c>
      php_flag session.save_path   /absoluter/unix/pfad/zu/meinemweb/htdocs/wp-content/files/tmp
</IfModule>

Der tmp-Ordner im eigenen Webspace muss von PHP beschreibbar sein, also ggf. mit 777 versehen. Und lege bitte eine leere index.php in den tmp-Ordner. Noch besser wäre es, wenn der eigene tmp-Ordner ausserhalb des DOCUMENT_ROOT angelegt würde, also z. B. unter /absoluter/unix/pfad/zu/meinemweb/tmp

EDIT: Obwohl das eigtl. alles Quatsch ist. Ich sehe im FF keinerlei Fehler. Hast Du mehr als deinen einen Mac-Safari getestet? Was sagt denn z.B. Chrome auf deinem Mac? Sieht irgendjmd. hier im Forum Fehlermeldungen auf seinem Safari?

Ich glaube, Du hast einfach Deine Domain- bzw. Sitzungscookies noch nicht alle erwischt. Der Fehler taucht wahrsch. nur bei dieser einen Session auf.

Hast Du zufällig serverseitig den PHP-Modus gewechselt (mod_php auf CGI oder umgekehrt)?
Egal - ich würde einmal versuchen, die SESSION-Cookies in Deinem Browser zu löschen.

Schöne Grüße,
Frank

Gehe in den Bearbeiten-Modus für diese Seite und klicke oben rechts auf den Hängereiter Optionen. Schau bitte nach, ob der Haken bei "Revisionen" gesetzt ist - falls nicht, setze ihn.

Unterhalb des Editors sollte spätestens jetzt das Modul "Revisionen" sichtbar sein. Da kannst Du gucken, ob die Autosave-Funktion von WordPress gegriffen hat und nun imstande ist, Dein Leben zu retten.

Schöne Grüße,
Frank

Zitat von Michi91

Da sich die Domain bei dir ändert mache folgendes:
- Installiere einen leeren Blog bei Mittwald (keine DATEINEN ÜBERNEHMEN!)
- Exportiere die XML im alten Blog
- Importiere die XML und mache einen Haken bei Mediadatein übernehmen
- Voilá

Na - ich glaube, die Domain soll sich ja gerade nicht ändern ...

Zitat von colourpoint

Dank der offline-Kopie des Blogs und des damit 1:1 möglichen FTP-Transfers der Mediathekstruktur dürfte es ja eigentlich kein Problem sein, das nun anzugehen und die domain zu transferien. Dann stimmen die links wieder und alles liegt beim neuen Provider.

Oder übersehe ich da etwas?

Ich denke, gerade diejenigen Links, die jetzt bei Mittwald funktionieren, werden eben dann nicht mehr funktionieren - dann dann verdreht sich sich das Problem.

Wie also oben schon gesagt: willst du das verlässlich testen, lasse lokal auf Deinem Rechner die echte Domain (zeigt dzt. auf einen 1&1-Server) auf den Mittwald-Server auflösen. Dann spiele einfach den 1&1-Datenbank-Dump bei Mittwald ein und alle Links der Neuinstallation sollten (vorerst natürlich nur lokal von Deinem Rechner aus betrachtet) schon funktiionieren und Du kannst den Domaintransfer veranlassen.