Wordpress versucht https zu laden

G1ggles

New Member
Guten Tag alle beisammen,

ich bin derzeit dabei meinen alten Blog wieder fertig zu machen bzw. diesen wieder Online zu bringen.

Die Datenbank ist importiert und die Daten wieder auf dem Webspace. Jetzt habe ich jedoch das Problem, dass ich damals ein SSL Zertifikat hatte, jetzt jedoch nicht mehr.

Wie schaff ich es, dass Wordpress nicht automatisch wieder auf https springt wenn ich nicht mehr weiß, über welches Plugin das ganze geregelt war?

Beste Grüße

G1ggles
 
Zwei übliche Möglichkeiten, wo das beeinflusst wird:
.htaccess hat eine rewrite rule oder in den WP Optionen wurde die WP-URL auf "https://example.com" gesetzt.
 
Ich hatte genau das "Problem" als ich ein WP so umstellen musste, dass nicht mehr das ganze WP HTTPS benutzt sondern nur noch das Backend.
Am Ende lief es darauf hinaus, dass ich total viele absolute Links in der Datenbank gefunden habe und diese dann mit einem String-Replace-Query ändern musste.
 
Wie schaff ich es, dass Wordpress nicht automatisch wieder auf https springt wenn ich nicht mehr weiß, über welches Plugin das ganze geregelt war?

Der einfachste Weg wäre doch, wieder ein Zertifikat einzubinden...
 
Okay, also ich würde ein SSL Zertifikat einbinden, wenn ich mich mit Mailservern besser auskennen würde. Erst wenn ich Zeit habe mich an den Mailserver zu setzen, kann ich mich anschließend auch um das Zertifikat kümmern. Da die Seite aber dringend Online muss, muss ich es irgendwie beheben.

Also die Hauptseite läd schon mal ohne Probleme und fix. Aber wenn ich versuche Beiträge oder Seiten zu laden, bekomme ich überall einen 404.

Wenn ich versuche auf wp-admin zuzugreifen zieht immer noch der SSL Rewrite. Gehe ich jedoch über wp-login.php ins Backend, gibt es keine Probleme.
 
Last edited by a moderator:
Poste mal bitte die .htaccess und die config, natürlich ohne Passwörter/Usernamen der DB.
Ansonsten kannte ich das, was Elias beschreibt, allerdings auch noch nicht, sehr interessant und gut zu wissen.

Wobei ich mich frage, ob ich der Einzige bin, der das etwas gruselig findet.
 
.htaccess:
Code:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

wp-config.php:
Code:
<?php
define('WP_SITE_URI', ($_SERVER["HTTPS"]?"https://":"http://").$_SERVER["SERVER_NAME"]); 
/** Enable W3 Total Cache Edge Mode */
define('W3TC_EDGE_MODE', true); // Added by W3 Total Cache


/**
 *
 * Secret-Keys, Sprache und ABSPATH. Mehr Informationen zur wp-config.php gibt es auf der {@link http://codex.wordpress.org/Editing_wp-config.php
 *
 * und die Installationsroutine (/wp-admin/install.php) aufgerufen wird.
 * Man kann aber auch direkt in dieser Datei alle Eingaben vornehmen und sie von wp-config-sample.php in wp-config.php umbenennen und die Installation starten.
 *
 * @package WordPress
 */
 
 /** Custom define for visuell-wysiwyg editor */
 define('CONCATENATE_SCRIPTS', false);

/**  MySQL Einstellungen - diese Angaben bekommst du von deinem Webhoster. */
define('DB_NAME', 'xxx');

/** Ersetze username_here mit deinem MySQL-Datenbank-Benutzernamen */
define('DB_USER', 'xxx');

/** Ersetze password_here mit deinem MySQL-Passwort */
define('DB_PASSWORD', 'xxx');

/** Ersetze localhost mit der MySQL-Serveradresse */
define('DB_HOST', 'localhost');

/** Der Datenbankzeichensatz der beim Erstellen der Datenbanktabellen verwendet werden soll */
define('DB_CHARSET', 'utf8');

define('DB_COLLATE', '');

/**#@+
 *
 * Auf der Seite {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service} kannst du dir alle KEYS generieren lassen.
 *
 * @seit 2.6.0
 */
define('AUTH_KEY',xxx);
define('SECURE_AUTH_KEY',xxx);
define('LOGGED_IN_KEY',xxx);
define('NONCE_KEY' ,xxx);
define('AUTH_SALT',xxx);
define('SECURE_AUTH_SALT',xxx);
define('LOGGED_IN_SALT',xxx);
/**#@-*/

/**
 *
 *  verschiedene WordPress-Installationen betreiben. Nur Zahlen, Buchstaben und Unterstriche bitte!
 */
$table_prefix  = 'wp_';

/**
 * WordPress Sprachdatei
 *
 * Hier kannst du einstellen, welche Sprachdatei benutzt werden soll. Die entsprechende
 * Sprachdatei muss im Ordner wp-content/languages vorhanden sein, beispielsweise de_DE.mo
 */
define('WPLANG', 'de_DE');

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
define('WP_DEBUG', false);

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
        define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);



Kurze Frage - wie wäre es, wenn ich eine neue Installation aufsetze und via Backup Tool die Beiträge einfach auf eine neue Installation bringe und das Theme rüber ziehe?
 
Okay, also ich würde ein SSL Zertifikat einbinden, wenn ich mich mit Mailservern besser auskennen würde. Erst wenn ich Zeit habe mich an den Mailserver zu setzen, kann ich mich anschließend auch um das Zertifikat kümmern.

Das Zertifikat für den Webserver hat absolut nix mit dem Mailserver zu tun.

Kurze Frage - wie wäre es, wenn ich eine neue Installation aufsetze und via Backup Tool die Beiträge einfach auf eine neue Installation bringe und das Theme rüber ziehe?

Für solche 'Versuche' gibt es Virtualisierungslösungen (Virtualbox o.ä.), wo man alles am lokalen PC austesten kann, ohne Produktivsysteme anfassen zu müssen.
Funktioniert es lokal, dann kann man die enstprechenden Maßnahmen auch in der Produktivumgebung gefahrlos umsetzen.
 
Letzten Fehler gefunden - AllowOverride sollte man nicht auf None stehen haben :D

Blog funktioniert wieder Einwandfrei.

Zertifikat hat außerdem doch was mit Mailserver zutun, da man bei der Zertifikatserstellung eine E-Mail an die eigene Domain senden lassen muss um glaube den CRT zu bekommen.
 
Zertifikat hat außerdem doch was mit Mailserver zutun, da man bei der Zertifikatserstellung eine E-Mail an die eigene Domain senden lassen muss um glaube den CRT zu bekommen.

Nicht, wenn man einen Smarthost verwendet.

[Offtopic]
Ich frage mich sowieso, wieso jeder unbedingt seinen eigenen Mailserver betreiben will. Der Aufwand für Konfiguration und Pflege steht in den meisten Fällen in keinerlei Verhältnis zum Nutzen...
[/Offtopic]
 
Ich hätte jetzt empfohlen, generell auf den Import der Options-Tabelle zu verzichten. Wenn ich mit WordPress jongliere, wird immer neu installiert, und eventuell gewünschte Plugins und Themes hinzugefügt. Anschließend mach' ich ein Truncate auf alle Tabellen die mit Posts, Comments, Links etc. zu tun haben und füge dort die Daten ein. Hat den Vorteil dass man auch gleich die ganzen Überreste alter Plugins und Einstellungen mit wegfegt. Danach kann man sauber neu konfigurieren.

Auf die Weise habe ich letztens eine Einzelseite zu einer Multisite-Installation hinzugefügt. Klappt super.
 
@TE wenn es ein 301 Redirect war kann der Client Cache noch eine "Fehlerquelle" sein. Ich persönlich setze nur 302 ein es sei denn die Domain ändert sich.

Desweiteren erzwingt deine Config HTTPS für wp-admin und login

Code:
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);
jeweils auf false setzen.

Falls ein Plugin HTTPS für die Frontpage erzwingt dürfte dies aber nicht schwer sein herauszufinden. Die Namensgebung der meisten WP-Plugins ist recht einleuchtend.

Um dem 404 entgegenzuwirken evtl. einmal RewriteBase abändern. Je nach Setup verlangt Apache hier einen relativen oder absoluten Pfad.
 
Last edited by a moderator:
Back
Top