Open Source · Ata
Mehr Power für Ihr WordPress-Plugin.
Mit MVC-S-Struktur.
ATA hilft Entwicklern von WordPress-Plugins, wachsende Codebasen mit dem MVC-Entwurfsmuster übersichtlich und wartbar zu halten.
Für WordPress-Plugin-Entwickler
Ein Ordner für alles.
ATA gibt jedem Plugin dieselbe vorhersehbare Struktur, so bleiben wachsende Codebasen übersichtlich und wartbar.
ATA Folder STRUCTURE
your-plugin-name/
├── app/
│ ├── apis/ # REST API endpoint classes
│ ├── controllers/ # Controller classes
│ ├── helpers/ # Global helper functions
│ ├── models/ # Data logic (database interaction)
│ │ └── structures/ # Optional: DTOs/data structure classes
│ ├── routes/ # API and custom URL definitions
│ ├── services/ # Business logic layer
│ └── views/ # View files (HTML/PHP templates)
│
├── base/ # Base classes your app classes extend
├── config/ # Plugin-wide configuration
├── constants/ # Custom constant definitions
├── inc/ # Bootstrapping and initialization files
├── vendor/ # Composer dependencies (includes the core ATA framework)
│
└── your-plugin-name.php # The main plugin entry file
Die Grundprinzipien von Ata.
Strukturiert ab Werk
ATA bringt eine vordefinierte Verzeichnisstruktur mit, die die einzelnen Bereiche Ihres Plugins logisch trennt.
Objektorientiert zuerst
Code entsteht in Klassen statt in prozeduralen Funktionen, für bessere Wiederverwendbarkeit und Ordnung.
Klare Trennung der Zuständigkeiten
Eine Variante des MVC-Musters sorgt dafür, dass Logik, Daten und Darstellung sauber getrennt bleiben.
Einfaches Routing
ATA enthält einen integrierten Router, mit dem Sie eigene REST-API-Endpunkte oder URLs einfach und deklarativ registrieren.
Die wichtigsten Unterschiede
Was ist MVC-S?
ATA setzt auf eine Variante des Model-View-Controller-Musters (MVC), die wir MVC-S (Model-View-Controller-Services) nennen.
Controller (die zentrale Steuerung)
Der Controller ist das Herzstück Ihres Plugins. Er verarbeitet eingehende Anfragen, registriert alle WordPress-Hooks und -Filter und steuert den Ablauf der Anwendung. In einfachen Plugins kann der Controller die gesamte Logik und den Datenzugriff selbst übernehmen. In komplexeren Anwendungen wird er zum Dirigenten: Er ruft einen Service für die Geschäftslogik oder ein Model für die Daten auf und übergibt die Ergebnisse dann zur Darstellung an eine View.
View (die Darstellungsschicht)
Die View ist eine optionale Schicht zur Erzeugung der HTML-Ausgabe. Sie erhält Daten vom Controller und stellt sie dar. Eine View sollte nur minimale PHP-Logik enthalten und sich ganz auf die Anzeige der übergebenen Daten beschränken.
Model (die Datenschicht)
Die einzige Aufgabe des Models ist der direkte Zugriff auf die Datenbank. Innerhalb einer Model-Klasse erreichen Sie das WordPress-Datenbankobjekt über $this->db (z. B. $this->db->get_results(...)). Diese Schicht ist optional: Greift Ihr Plugin nicht auf die Datenbank zu, brauchen Sie sie nicht.
Service (die Logikschicht)
Die Service-Schicht ist der optionale, aber empfohlene Ort für die zentrale Geschäftslogik Ihres Plugins. Wird die Logik für einen Controller zu komplex, lagern Sie sie in einen Service aus. So bleiben Controller schlank und auf die Verarbeitung von Anfragen fokussiert.
Beispiel-Plugin
Polylang RestAPI Helper
Das Plugin polylang-restapi-helper ist ein perfektes, kompaktes Beispiel für das ATA-Framework.
So bringen Sie ATA MVC in Ihr WordPress-Plugin
Dokumentation
ATA im eigenen Plugin einsetzen, schnell und einfach
Plugin-Lebenszyklus & Main Controller
Jedes ATA-Plugin wird von einem zentralen Root-Controller gesteuert. Dieser Main Controller ist der Einstiegspunkt für sämtliche Plugin-Funktionen und verwaltet den Lebenszyklus des Plugins.
1. Die Haupt-Plugin-Datei (your-plugin-name.php) Diese Datei ist sehr schlank. Sie definiert lediglich die wichtigsten Konstanten, lädt das ATA-Framework und instanziiert Ihren Main Controller.
// in your-plugin-name.php
namespace YourPluginNamespace;
// ... define constants ...
// Load the framework and all its dependencies
require_once PLUGIN_PATH . '/inc/main.php';
// Instantiate the one and only root controller
$my_plugin = new MainController();
// Hook into WordPress's activation/deactivation events
register_activation_hook(PLUGIN_FILE, [$my_plugin, 'activate']);
register_deactivation_hook(PLUGIN_FILE, [$my_plugin, 'deactivate']);
2. Der Main Controller (app/controllers/main-controller.php) Dieser Controller enthält die Logik für Aktivierung und Deaktivierung und lädt vor allem alle anderen Controller. Hier können Sie Funktionen abhängig davon laden, ob andere Plugins aktiv sind, das spart Speicher und verhindert Fehler.
// in app/controllers/main-controller.php
namespace YourPluginNamespace;
class MainController extends Controller
{
public function __construct()
{
parent::__construct();
$this->load_features();
}
// Load other controllers for specific features
private function load_features()
{
// Always load the admin UI and asset controllers
(new AdminUiController())->main();
(new AssetsController())->main();
// **Conditionally load features**
// Only load the WooCommerce compatibility layer if WooCommerce is active
if (is_plugin_active('woocommerce/woocommerce.php')) {
(new WooCommerceController())->main();
}
}
// Logic for when the plugin is activated (e.g., create DB tables)
public function activate()
{
// ... your activation code ...
}
// Logic for when the plugin is deactivated (e.g., remove DB tables)
public function deactivate()
{
// ... your deactivation code ...
}
}
Eine Seite oder einen Tab im WordPress-Adminbereich hinzufügen
ATA bietet ein Fluent Interface, mit dem Sie mühelos Admin-Seiten mit mehreren Tabs erstellen. Gesteuert wird das aus einem Controller.
// in app/controllers/admin-ui-controller.php
namespace YourPluginNamespace;
class AdminUiController extends Controller
{
public function main()
{
$this->add_wp_admin_pages();
}
private function add_wp_admin_pages()
{
// Create a top-level page titled "My Plugin"
$this->admin_page('My Plugin')
// Only users who can 'manage_options' can see it
->permission('manage_options')
// Add a "Dashboard" tab (calls the 'dashboard_page' method)
->add_tab('Dashboard', 'dashboard_page')
// Add a "Settings" tab (calls the 'settings_page' method)
->add_tab('Settings', 'settings_page')
// Register the page and all its tabs
->register();
}
// This method is called when the 'Dashboard' tab is active
public function dashboard_page()
{
$this->view = 'dashboard'; // Renders views/dashboard-view.php
}
// This method is called when the 'Settings' tab is active
public function settings_page()
{
$this->view = 'settings'; // Renders views/settings-view.php
}
}
An einen WordPress-Hook andocken (Action)
Der Basis-Controller von ATA bietet die praktische Hilfsmethode on(), um Action-Hooks zu registrieren. Der ideale Ort, um alle Hooks zu registrieren, ist der Konstruktor oder eine main()-Methode in Ihrem Controller.
// in app/controllers/footer-message-controller.php
namespace YourPluginNamespace;
class FooterMessageController extends Controller
{
public function main()
{
// Hook into 'wp_footer' to call the 'add_message' method
$this->on('wp_footer', 'add_message');
}
public function add_message()
{
echo "";
}
}
WordPress-Filter verwenden
Analog zu Actions können Sie mit der Hilfsmethode filter() Daten verändern.
// in app/controllers/content-controller.php
namespace YourPluginNamespace;
class ContentController extends Controller
{
public function main()
{
// Hook into 'the_content' to modify post content
$this->filter('the_content', 'add_author_bio');
}
public function add_author_bio($content)
{
if (is_single() && in_the_loop() && is_main_query()) {
$author_bio = '';
return $content . $author_bio;
}
return $content;
}
}
Einen WordPress-REST-API-Endpunkt hinzufügen
Schritt 1: Route registrieren in app/routes/main-routes.php. Damit weiß WordPress, dass Ihre URL existiert und welche Methode sie verarbeitet.
// in app/routes/main-routes.php
namespace YourPluginNamespace;
$ata_router->api_version('my-plugin/v1');
$ata_router->api_method('GET')->api('/products')->call('ProductsApi::get_all_products');
Schritt 2: API-Klasse anlegen in app/apis/, die die Logik des Endpunkts enthält.
// in app/apis/products-api.php
namespace YourPluginNamespace;
class ProductsApi extends Api {
public function get_all_products() {
// ... logic to get products ...
return $this->send_success('Products retrieved.', ['products' => '...']);
}
}
Wie funktioniert das Routing?
Die Routendatei (app/routes/main-routes.php) ist eine leistungsstarke, aber optionale Funktion. Sie dient einzig als Schaltzentrale und teilt WordPress mit, wie bestimmte eigene URLs zu behandeln sind. Braucht Ihr Plugin weder eigene URLs noch eine REST API, müssen Sie sie nicht verwenden.
- Für REST APIs: Verwenden Sie die Methode
api(). Sie registriert einen neuen Endpunkt unter/wp-json/.// Registers: example.com/wp-json/my-plugin/v1/orders $ata_router->api_version('my-plugin/v1'); $ata_router->api('/orders')->call('MyOrdersApi::get_orders'); - Für eigene Frontend-URLs: Verwenden Sie die Methode
page(). Sie erzeugt eine virtuelle Seite, ganz ohne WordPress-Seite als Beitrag.// Registers: example.com/my-custom-url/ $ata_router->page('/my-custom-url')->call('MyPageController::show_page');
Wofür sind die optionalen Kernverzeichnisse da?
app/views
In diesem Verzeichnis liegen Ihre HTML-Templates. Es ist nur dann nötig, wenn Ihr Plugin eine Benutzeroberfläche erzeugt, etwa eine Einstellungsseite im Adminbereich oder eine eigene Frontend-Seite. Plugins, die nur im Hintergrund arbeiten oder eine REST API bereitstellen, haben in der Regel kein views-Verzeichnis.
models/structures (DTOs)
Dieses Verzeichnis ist für Data Transfer Objects (DTOs) gedacht. Ein DTO ist eine einfache Klasse, die die Form der weitergereichten Daten festlegt. Das Verzeichnis ist optional und für viele Plugins nicht nötig. Am nützlichsten ist es, wenn Sie eine strikte Datenstruktur erzwingen müssen, vor allem bei der Kommunikation mit einer externen API.
Ihre Erfolgsgeschichte könnte die nächste sein.
Noch Fragen? Wir helfen Ihnen, die richtige Entscheidung zu treffen.