Wordpress: .htaccess-Datei und Umschreiberegeln: Custom Post Type (CPT)-Seiten geben 403/404-Fehler zurück [geschlossen] ⇐ Php

[Anonymous]

Während viele sagen: CPTs stellen keine ungewöhnlichen oder spezifischen Server-Hardwareanforderungen dar – ich denke, dass ein Standard-WordPress-Hosting für die meisten Anwendungsfälle ausreichend ist
Ich habe die Frage: Was sind die Bedingungen, die Ihrer Meinung nach am wichtigsten sind?
Übrigens; in Bezug auf die PHP-Umgebung und für die Bedingung: Ich denke, dass wir sicherstellen, dass auf dem Server eine aktuelle, unterstützte Version von PHP für optimale Leistung läuft Sicherheit.
bezüglich URL-Rewrite (Permalinks): CPTs verwenden WordPress-Rewrite-Regeln, um saubere, benutzerfreundliche URLs (Permalinks) zu erstellen, wie zum Beispiel auf my_site.com.
Bedingung: Der Webserver (normalerweise Apache oder Nginx) muss für die korrekte Verarbeitung der WordPress-.htaccess-Datei oder äquivalenter Rewrite-Regeln konfiguriert sein. Bei CPT-Seiten 404-Fehler zurückgeben, weist dies oft auf ein serverseitiges Rewrite-Konfigurationsproblem hin, das normalerweise durch einfaches erneutes Speichern der Permalink-Einstellungen im WordPress-Administrationsbereich behoben werden kann.
Was ist, wenn die erstellten URLs https://www.my_site.com/cpt/addsmart/
https://www.my_site.com/cpt/ nicht (!) zugänglich sind!
Nun – glauben Sie mir: Das Verhalten ist lustig.
die beiden URLs https://www.my_site.com/cpt/addsmart/
https://www.my_site.com/cpt/ geben beide einen Zugriff verweigert aus
Übrigens: Ich habe Folgendes in die .htaccess-Datei geschrieben

Code: Select all

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .  /index.php [L]

# END WordPress

aber ich vermute, dass dies aufgrund einiger Konfigurationsprobleme nicht verarbeitet wird.
Update: Sehen Sie sich weitere Informationen an
und sehen Sie dies - was ich der .htaccess hinzugefügt habe

Code: Select all

Permalink-Struktur: Plain
WordPress does not create any Rewrite-Regeln
all the "pretty URLs"  run over:
mod_rewrite (Apache) or
Nginx Rewrite Rules

but well my server Server says:

❌ „these URLs could not be executed“

einige Einblicke in die Konfiguration:
Fazit: PHP & Apache sind korrekt gebaut, mod_rewrite scheint geladen zu sein
Befehl konfigurieren:

Code: Select all

'./configure' '--prefix=/usr/local/php-8.4.14' '--with-apxs2=/usr/local/apache/bin/apxs' '--without-snmp' '--disable-ipv6' '--enable-sigchild' '--with-pear' '--with-mysql-sock=/var/run/mysql/mysql.sock' '--enable-calendar' '--with-zlib' '--enable-mbstring' '--with-pdo-mysql' '--with-mysqli' '--disable-mbregex' '--with-openssl=/usr/local/' '--enable-shmop' '--enable-sysvshm' '--with-pdo-sqlite' '--enable-gd' '--with-mm=/usr/local/mm/' 'OPENSSL_CFLAGS=-I/usr/local/include' 'OPENSSL_LIBS=-L/usr/local/lib -lssl -lcrypto' '--with-openssl-argon2' '--enable-static=NO' '--with-curl=/usr/local/' 'CFLAGS= -O2 -march=native -Wno-erro '

Geladene Module:

Code: Select all

'http_core mod_authn_file mod_authn_dbm mod_authn_socache mod_authz_host mod_authz_groupfile mod_authz_user mod_authz_core mod_access_compat mod_auth_basic mod_auth_digest mod_socache_shmcb mod_watchdog mod_ratelimit mod_reqtimeout mod_filter mod_deflate mod_mime mod_log_config mod_env mod_mime_magic mod_expires mod_headers mod_usertrack mod_setenvif mod_version mod_session mod_session_cookie mod_ssl prefork mod_unixd mod_autoindex mod_dir mod_alias mod_rewrite mod_php'

Update 2 Nun, noch ein paar Anmerkungen:

Code: Select all

mod_rewrite ✔ loaded

Code: Select all

WordPress Plain-Links ✔ running well

Code: Select all

Pretty Permalinks ❌ 403

Code: Select all

Theme - tt3 tt4 tt5 - each time the same behavior

Code: Select all

Plugins - they do not play a vital role

es scheint das einzige zu sein, was fehlt:

Code: Select all

❌ Apache blocks .htaccess or the Paths

nun ja, das könnte bedeuten:
Fall 1: AllowOverride None
Apache liest die .htaccess-Datei nicht, obwohl die Datei existiert.
Beispiel – problematisch:

Code: Select all

AllowOverride None

WordPress kann einige (keine) Rewrite-Regeln aktivieren
Apache antwortet mit 403 Access denied
Fall 2: Restriktive - oder -Regeln
zum Beispiel

Code: Select all

Code: Select all

Require all denied

Code: Select all

oder:

Code: Select all

Require all denied

nur explizit erlaubte Dateien waren sichtbar (index.php?p=123)
virtuelle Pfade (/my_slug/) wurden blockiert
und - einige weitere Erkenntnisse:
Warum ?p=123 angezeigt wird (wichtiger Punkt - !!)

Code: Select all

?p=123:

wird direkt an die index.php übergeben - es wird an die index.php „übergeben“

Code: Select all

no Rewrite

kein Test des Pfades

Code: Select all

/my_slug/:

Apache prüft:
a. könnte dieser Pfad „wahr“ sein – könnte dieser Pfad existieren?
b. Gibt es irgendwelche Regeln?
Darf .htaccess hier „alles“ tun?
und genau hier kommt der 403 ....
nun – ich muss das beheben – ich muss das auf jeden Fall „beheben“ und diese Probleme loswerden
Diagnose (endgültig):
Ihr Server blockiert alle „pfadbasierten URLs“ (/foo, /edih/, /sample-post/) auf Apache-Ebene, bevor WordPress Maßnahmen ergreift.

Code: Select all

+------------------------+-----------------+------------------------------------+

|          Test          |     result      |              meaning               |

+------------------------+-----------------+------------------------------------+

| /?p=POST_ID            | ✔ visible        | PHP + WordPress OK                |

| /permalink-test/       | ❌ Access denied | Rewrite-URLs blocked              |

| /this-should-not-exist | ❌ Access denied | Apache blockt Patgs               |

| /wp-content/           | blank            | Directory Listing deaktiviert (ok)|

| /wp-includes/          | ❌ Forbidden     | closed  (normal)                  |

| /rewritetest.php       | ❌ Access denied | critical                          |

+------------------------+-----------------+------------------------------------+

und jede Idee – wir waren sehr dankbar
Grüße
neues Update: Empfehlung:
Ich habe gerade Ihr Beitrags-Update zum Testen von URLs gesehen. Auf welche Einstellung sind Ihre Einstellungen > Permalinks eingestellt? Es muss „Beitragsname“ lauten
,,,, ich habe mich an die Arbeit gemacht und wie empfohlen gearbeitet: Aber sehen Sie, was passiert ist: Nachdem ich in den „Permalinks“ auf die empfohlene Option umgestellt hatte, wurde ich ausgesperrt. Ich konnte keine Seite erreichen:
es hat nicht geholfen, die wp_options über Datenbank zurückzusetzen:
ich wollte die Rewrite-Regeln zurücksetzen: über DB:
step1
UPDATE wp_options
SET option_value = ''
WHERE option_name = 'permalink_structure';
step2
UPDATE wp_options
SET option_value = ''
WHERE option_name = 'rewrite_rules';
diese oben genannten Schritte – sie haben überhaupt nicht geholfen – ich bekomme immer einen verbotenen Zugriff zurück
id hat nicht geholfen – es hat auch nicht geholfen, diese Zeilen in die Konfigurationsdatei einzufügen:
define('WP_HOME', 'https://www.my_site.com');
define('WP_SITEURL', 'https://www.my_site.com');
Dies verdeutlicht einen sehr wichtigen Punkt: (scheint alles etwas seltsam zu sein)
WordPress läuft derzeit überhaupt nicht.
Der Code in wp-config.php funktioniert nicht → Apache blockiert PHP.
Dies ist nicht mehr der Fall WP-, ACF- oder CPT-Problem.
Wir sind zu 100 % auf der Apache-/Serverebene.
Ich verfolge einen strengen Diagnoseansatz – ich denke, dass der Serveradministrator etwas auf dem Server testen oder ändern muss.
siehe den vorherigen Test – die Ergebnisse und so weiter.:

Code: Select all

+-----------------------------+----------------+--------------------------------------+
|     Test                    |Result          |  Meaning;                            |
+-----------------------------+----------------+--------------------------------------+
|                             |                 |                                      |
| /?p=ID                      | (previously) ✔ | WordPress was running;               |
| /index.php                  | ❌ Forbidden    | PHP is blocked;                      |
| /wp-login.php               | ❌ Forbidden    | WordPress is not running;            |
| /rewritetest.php (physical) | ❌ Forbidden    | Apache is blocking paths in general; |
| Change in wp-config.php     |  ❌ Ineffective | WordPress is not reachable;          |
+-----------------------------+----------------+--------------------------------------+

Eines (oder mehrere) dieser Probleme ist aktiv:
Falscher DocumentRoot
Falscher Pfad (sehr häufig!)
Eine globale Require all denied-Regel
Sicherheitshärtung wie:
mod_security
mod_evasive
paX / CageFS
Plesk / ISPConfig-Einschränkung
Eine .htaccess-Datei wird überhaupt nicht gelesen, obwohl AllowOverride All eingestellt zu sein scheint.
Der Serveradministrator muss dies testen:
ls -la /PFAD/ZU/WORDPRESS/index.php
Wenn diese Datei nicht existiert oder ein anderer Pfad angezeigt wird,
dann zeigt der VirtualHost auf den falschen Verzeichnis.
Dies ist der häufigste Fehler.
TEST 2 – Apache-Config: falscher Verzeichnispfad
sehr oft der Fall (falsch):

Require all denied

oder so:

Require all denied

Dann reicht eine einzige falsche Einstellung, um alles zu blockieren. hmm – die Minimalkonfiguration – sollte so aussehen /(irgendwie)

Code: Select all

ServerName my_site.com
DocumentRoot /PFAD/ZU/WORDPRESS


AllowOverride All
Require all granted

Der Pfad musste identisch sein – kein Symlink-Konflikt
Test 4 (der brutale)

Code: Select all

Require all granted

Wenn es danach gut läuft, dann blockiert eine Verzeichnisregel WordPress.
TEST 4 – mod_security / WAF
wahrscheinlich ist eine Firewall aktiv
Ist mod_security oder eine Web Application Firewall aktiv?
Wenn ja, deaktivieren Sie diese vorübergehend oder schließen Sie sie für VHost aus – mit
SecRuleEngine Off
um zu summieren up:

WordPress ist nicht mehr zugänglich; sogar /index.php gibt einen 403
Fehler zurück. Die folgenden Prüfungen müssen ausgeführt werden: Ob der VirtualHost tatsächlich auf das Verzeichnis mit index.php verweist informiert..