Beiträge von websupporter

Na, freut mich, dass es geklappt hat :)

"Habe dann noch deinen Code eingebaut, da zeigt er aber immer nur das implementierte Datum an, was muss ich da noch verändern?"
Kannst Du mir mal den Output schicken von

<?php echo get_field('date_picker'); ?>

Dann kann man sehen, in welchem Format das Datum eigentlich abgespeichert ist.

Bzgl. der Umlaute. Autsch. Hmmm... Also im HTTP-Header wirds via ISO übertragen. Im meta-tag wird UTF8 angegeben. Denke mal, Du hast die Standart-Einstellungen, also in der Datenbank UTF8. Wieso der HTTP-Header ISO-Schriftsatz übergibt ist mir nicht ganz klar. Ich glaube WP sorgt normalerweise für die korrekte Übertragung auch im HTTP-Header.

Da dank WP_DEBUG relativ viele Fehlermeldungen noch vor der doctype-Deklaration kommen hmm... Vielleicht einfach mal probieren WP_DEBUG auszuschalten, obs dann klappt?

Anderer Versuch falls es nicht klappt: Also der Server gibt jetzt über HTTP ISO aus, während du UTF8 brauchst. Vielleicht einfach die htaccess entsprechend erweitern: http://stackoverflow.com/questions/7963…response-header

Klappt es dann wieder?

createDateFormat gibt es seit PHP Version 5.3. Wahrscheinlich läuft auf dem Server eine ältere Version. Kannst Du mit phpinfo() checken.

Lösung 1: Update PHP auf eine aktuellere Version.
Lösung 2: Du musst das Formatieren selbst übernehmen:

Du kriegst ja wahrscheinlich mit get_field() einen String wie den folgenden 20150228 für den 28. Februar 2015. Den willst Du bspw. in 28.02.2015 verwandeln? Guck Dir mal diesen Code an:

<?php
$string = '20150228';
$jahr = substr( $string, 0, 4 );
$monat = substr( $string, 4, 2 );
$tag = substr( $string, 6, 2 );
echo $tag . '.' . $monat . '.' . $jahr;
?>

Mach mal den WP_DEBUG Modus an. Du wirst wahrscheinlich genau an der Stelle einen Fatal Error haben. Tippe schlicht auf eine unterschiedliche Server Einstellung.

Noch ein Schuss ins Blaue: Hast Du ACF auch online aktiviert?

Ja, warum nicht? Klingt so, als müsstest Du dann für jeden externen einen normalen WP User anlegen.

Hmmm... so in die Richtung links ist der Slider mit großen Bildern, rechts Thumbnails? Ist das erste Thumbnail-Bild identisch mit dem ersten Slider-Bild etc?

Ich meine:

<ul class="slider">
    <li>1. Bild</li>
    <li>2. Bild</li>
    ...
    <li>5. Bild</li>
</ul>


<ul class="thumbnails">
    <li>1. Thumbnail</li>
    <li>2. Thumbnail</li>
    ...
    <li>5. Thumbnail</li>
</li>

Könntest Du es dann nicht doch in Javascript einfach lösen? Mit indexOf den Index des Thumbnails ermitteln, dieser ist dann gleich der Index des Sliderbildes, oder?

Hi,
wp_signon() ist die Funktion, in welcher auch der Filter 'wp_authenticate' ausgeführt wird. Deshalb kommst Du in eine Endlosschleife. Wenn Du über einen Radiobutton gehst, welchen Du auf der wp-login.php mit Hilfe des Hooks 'login_form' einbinden könntest, kannst Du im 'wp_autenticate' dann prüfen, ob die Box gecheckt ist und in diesem Fall Deine API-Abfrage machen und in WordPress sagen wir einen Standard-User anlegen.

Grob in die Richtung:

<?php
add_filter( 'authenticate', 'api_abfrage', 10, 3 );
function api_abfrage( $user, $username, $password ){
    if( !isset( $_POST['api_login'] ) )
        return $user;


    //API Abfrage
    $url = 'http://example.com/?mail=' . $username;
    $response = wp_remote_get( $url );
    $json = json_decode( $response['body'] );


    if( $json->failed )
        return null;


    //Sagen wir die ID Deines Standard-Users wäre 1
    $user = new WP_User( 1 );
    return $user;
}
?>

Alle externen Logins würden dann im selben User landen.

Codex:
https://codex.wordpress.org/Plugin_API/Act…ence/login_form

Hmmm... Hast Du schonmal in die .htaccess geschaut, beziehungsweise die Permalinks aktualisiert?

Freut mich :)

Ah, und Du solltest auch einen Blick auf die Funktion [FONT=courier new]wp_signon()[/FONT] werfen:
https://codex.wordpress.org/Function_Reference/wp_signon

Hallo cokodeluxe,
verstehe ich Dich richtig, Du möchtest wenn sich jemand einloggt anhand von dessen Email-Adresse eine API Anfrage starten?
Wenn dann die entsprechenden Daten von der API zurückkommen, kann sich der User einloggen, ansonsten schlägt der Login fehl?

Du musst über die entsprechenden Filterhook [FONT=courier new]'authenticate[/FONT]' gehen. Also, nur mal so ganz grob hingeschrieben:

<?php
add_filter( 'authenticate', 'api_abfrage', 10, 3 );
function api_abfrage( $user, $username, $password ){
    //Email Adresse ermitteln
    $user_object = get_user_by( 'login', $username );
    $email = $user_object->data->user_email;


    //API Abfrage
    $url = 'http://example.com/?mail=' . $email;
    $response = wp_remote_get( $url );
    $json = json_decode( $response['body'] );


    if( $json->failed )
        return null;


    return $user;
}
?>

Hilfreiche Codex-Seiten:
https://codex.wordpress.org/Function_Reference/add_filter
https://codex.wordpress.org/Plugin_API/Fil…ce/authenticate
https://codex.wordpress.org/Function_Reference/get_user_by
https://codex.wordpress.org/Function_Reference/wp_remote_get

Ich hoffe, dass ich Dich richtig verstanden habe und die Richtung stimmt :)

Komisch, ich hatte es gerade mal bei mir probiert, da funktioniert es. Die entscheidende Zeile ist dabei 302. Benutz mal den Backslash: \

Vielleicht liegts bei Dir daran?

$IRjsjs = $IRjsjs . "<a target=\'_blank\' href=\'$rssslider_link\'>";

Suche mal in dem Plugin nach der Funktion [FONT=courier new]init()[/FONT]. Vermutlich findest Du etwas wie

[FONT=courier new]function init()[/FONT]

solltest aber etwas wie
[FONT=courier new]
[/FONT][FONT=courier new]public static function init()[/FONT]
[FONT=arial]
finden.[/FONT]

Wenn es darum geht, bestimmte Widgets nicht anzeigen zu lassen, wenn ein bestimmter GET-Parameter übergeben wird:

Ich habe mir den Code des Plugins mal ein wenig angeschaut, dieser nutzt [FONT=courier new]get_queried_object_id()[/FONT] um die Post ID zu ermitteln. Wenn Du über die globale [FONT=courier new]$post[/FONT] gehst kommst Du da nicht weiter, da hier direkt auf [FONT=courier new]$wp_query[/FONT] zurückgegriffen wird.

Ich habe mal ein bißchen gespielt und folgendes ausprobiert:

add_filter( 'sidebars_widgets', 'blende_aus_wenn_get' );
function blende_aus_wenn_get( $sidebars_widgets ){
    //Wenn der Parameter nicht uebergeben wird, einfach alle zurückgeben
    if( ! isset( $_GET['ausblenden'] ) )
        return $sidebars_widgets;


    //Array mit den Widgets, welche ausgeblendet werden sollen
    //In meinem Beispiel das Archiv, welches als "archives-3"
    //hinterlegt ist
    $widgets_ausblenden = array( 'archives-3' );


    //Wie findet man heraus, welche? Benutze
    #echo '<pre>';print_r( $sidebar_widgets );echo '</pre>';


    //Die Sidebars durchlaufen, und die gewuenschten Widgets
    //herausnehmen
    foreach( $sidebars_widgets as $sidebar_id => $widgets )
        foreach( $widgets as $widget_id => $widget )
                if( in_array( $widget, $widgets_ausblenden ) )
                    unset( $sidebars_widgets[ $sidebar_id ][ $widget_id ] );


    return $sidebars_widgets;
}

Dieser Code würde das Widget "archive-3" ausblenden, wenn der GET-Parameter "ausblenden" übergeben wird. Ich hoffe, Du kannst damit was anfangen.

Also, so ganz verstehe ich nicht was Du machst. Soweit ich es verstehe.

Wenn die URL einen bestimmten GET-Parameter transportiert willst Du eine bestimmte Post ID anzeigen. Also beispielsweise:

http://www.example.com/?p=1&spezial_param=x und http://www.example.com/?p=2&spezial_param=x sollen zum Schluss auf den gleichen Post führen?

Oder geht es nur darum, dass wenn der Parameter übertragen wird soll ein bestimmtes Widget nicht angezeigt werden?

Hm... Das ist ein bißchen stochern im Nebel: Kann es sein, dass Ihr die Einstellung habt, dass die Sprache automatisch nach Browser ausgewählt werden soll, oder dass sich die bevorzugte Sprache des Nutzers gemerkt werden soll und die entsprechende Beitragsprache gewählt werden soll?

Bezüglich Yoast. Da bin ich mir nicht ganz sicher, was Du meinst. Guck mal, wenn Du die Seite nicht mehr als Startseite deklarierst und dann auf mysite.de/startseite gehst ob Du dan andere Title, Meta-Description etc. bekommst als wenn die Seite als Startseite deklariert ist.

Wenn Du eine Seite als Startseite definierst, so wird diese natürlich auf die Homepage linken und nicht auf eine Unterseite. Aus mysite.de/startseite wird deshalb mysite.de/

Einen Font von einer anderen (Sub-)Domain zu holen gilt als Cross Site und wird unterbunden, es sei denn der Server erlaubt dies ausdrücklich. Erweitere Deine .htacess mal entsprechend:

<FilesMatch "\.(ttf|ttc|otf|eot|woff)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>

Ich habe das jetzt noch nicht ausreichend getestet, aber guck Dir mal dieses Codefragment an:
[FONT=lucida console] add_filter( 'script_loader_src', 'relative_path', 10, 2 );
add_filter( 'style_loader_src', 'relative_path', 10, 2 );
function relative_path( $src, $handle ){
$url = get_bloginfo( 'url' );
$src = preg_replace( '^' . preg_quote( $url ) . '^', '/wp/', $src );
return $src;
}[/FONT]

Das könnte Dich schon ein Stückchen weiterbringen. Diese Filter werden verwand, um die Source-Dateien nochmal zu filtern.