Hinzufügen von admin-ajax.php zum Frontend. Gute oder schlechte Idee?

Ich liebe admin-ajax.php. Aber ich hasse es, lokalisieren zu müssen, um Frontend-Skripte darauf zu verweisen, und ich wünschte, es gäbe eine äquivalente, leicht zu findende Datei für Themen. (Es stört mich auch nur, wenn Frontend-Anfragen "/ wp-admin /" durchlaufen. Kein praktischer Grund, sieht nur hässlich aus, IMO.)

Also habe ich einfach admin-ajax.php in das Stammverzeichnis unter "/ajax.php" kopiert, die Include-Pfade angepasst und die WP_ADMIN-Konstantendefinition entfernt. Scheint wie ein Gangbuster zu funktionieren (ich kann jetzt alle meine Frontend-AJAX-Anfragen an /ajax.php richten! Und ich kann immer noch die normalen wp_ajax-Hooks in meinen Plugins verwenden!).

Aber ist das sicher? Was könnte schief gehen? Da dies nicht in den Kern eingebaut ist, gibt es wohl einen guten Grund, warum nicht. Wenn ich mir den Code ansehe, sehe ich keine unmittelbaren Probleme.

Du bist schlau - sag mir, ob dieser Ansatz verrückt ist. Oder ob es eine einfachere Methode gibt, die ich übersehen habe.

Sie können einfach eine RewriteRule für Ihren .htaccess verwenden, die über den regulären Regeln für das Umschreiben von Permalinks liegt:

RewriteRule ^ajax$ /wp-admin/admin-ajax.php [L]

Senden Sie jetzt Ihre AJAX-Anforderungen an example.com/ajaxund verpassen Sie nach Upgrades keine grundlegenden Änderungen an dieser Datei mehr.

Erstens: Standardisierung. Wenn Sie Community-Plugins verwenden möchten, kümmern sich diese möglicherweise nicht um Ihre /ajax.phpDatei im Dokumentenstamm. Also werden sie es nicht benutzen.

Wenn Sie alles selbst rollen, ist dies kein Problem.

Zweitens: Was ist, wenn der Core aktualisiert wird? Überwachen und ändern Sie Ihre Ajax-Datei?

Drittens : Trotz des admin-ajax.phpWohnsitzes in wp-adminlädt es keine Admin-Bereiche (z. B. Listentabellen usw.). Es überprüft auch nicht die Authentifizierung und macht keine sensiblen Daten für nicht angemeldete Benutzer verfügbar. Es ist mit anderen Worten wie eine Front-End-Datei. Nichts, über das man sich sorgen sollte.

Viertens: In Bezug auf das erste Problem überprüfen einige Plugins, bevor sie blind Ajax-bezogene Funktionen laden. Ein Beispiel ist unten. Deine modifizierte ajax.php wird das wahrscheinlich nicht laden.

<?php
if (is_admin() && defined('DOING_AJAX') && DOING_AJAX) {
    //  load ajax stuff
}

Schließlich: Was Sie beanstanden, ist eine gute Sache, die Lokalisierung zu verwenden, um die Ajax-URL zu erhalten. Warum? Weil Ihre JS-Dateien nichts von den serverseitigen Dingen mitbekommen. Sie werden es schwer haben, eine URL zu finden, die kaputt geht, wenn sich die Site bewegt? Scheint eine schlechte Wahl zu sein.

Wenn Sie wirklich nicht jedes Skript lokalisieren möchten, das Ajax verwendet, schließen Sie sich einfach wp_headsehr früh an und geben Sie die Ajax- URL des Administrators aus. Problem gelöst (genau so macht es übrigens der Admin-Bereich).

<?php
add_action('wp_head', 'wpse83650_lazy_ajax', 0, 0);
function wpse83650_lazy_ajax()
{
    ?>
    <script type="text/javascript">
    /* <![CDATA[ */
    var ajax_url = "<?php echo esc_js(admin_url('admin-ajax.php')); ?>";
    /* ]]> */
    </script>
    <?php
}

Wie bei vielen Dingen in WordPress gibt es unendlich viele Möglichkeiten, die Katze zu häuten. Während alle akzeptierten Methoden funktionieren, habe ich festgestellt, dass sie weniger "ordentlich" sind als die Verwendung von wp_localize_script , um Ajax-Funktionen im Front-End einzuschließen .

Überprüfen Sie dies heraus:

add_action( 'wp_enqueue_scripts', 'se83650_js' );
function se83650_js()
{
    wp_enqueue_script( 'se83650-js', plugin_dir_url( __FILE__ ) . 'js/se83650.js',  'jquery', '1.0.0', true );
    // First param is the name of the script you are attaching it to - in this case
    // it is the name of the custom script we added.  Second param is the name of 
    // the javscript Object that will be attached with your information.
    // Third param is an array of attributes, in this case, ajaxurl
    wp_localize_script( 'se83650-js', 'se83650Ajax', 
        array(
            // You can put any variables here you want for your script
            // such as plugin-specific variables or nonces, etc.
            'ajaxurl'    => admin_url( 'admin-ajax.php' )
        )
    );
}

Und dann würden Sie in der se83650.jsDatei auf Ihre Variable mit verweisen se83650Ajax.ajaxurl.

Der Vorteil dieser Technik besteht darin, dass viele Plugins, die versuchen, diese Funktionalität zu duplizieren, nicht dieselbe Variable einschließen oder überschreiben. ajaxurlEs ist ziemlich generisch, um es einzuschließen, dies verschafft Ihnen mehr Eindämmung und es spielt besser mit anderen Entwicklern.