[3.2] diverse URLs werden nicht mehr geöffnet

Beitrag von **Mahony** » 13.03.2017 07:32

Hallo
Du schreibst

Jörg-CH hat geschrieben:ich bin mir nicht ganz sicher , aber könnte dies auch an der originalen .htaccsess zu tun haben ?

Dann vergleiche doch mal die neue .htaccess mit der alten. Ich denke mal, der Fehler könnte dort zu finden sein.

Grüße: Mahony

Jörg-CH · Beitrag von **Jörg-CH** » 13.03.2017 09:49

puuuuhhhh...
so wieder etwas weiter gekommen...
bevor ich den Fehler 500 erhalten , werden mir folgende Debug-Fehler ausgegeben:

Code: Alles auswählen

[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 182
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 182
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 909: Undefined offset: 0
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 184
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 184
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 909: Undefined offset: 0
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 183
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 183
[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 909: Undefined offset: 0

In der .htaccess steht :

Code: Alles auswählen

<IfModule mod_rewrite.c>
RewriteEngine on

#
# Uncomment the statement below if URL rewriting doesn't
# work properly. If you installed phpBB in a subdirectory
# of your site, properly set the argument for the statement.
# e.g.: if your domain is test.com and you installed phpBB
# in http://www.test.com/phpBB/index.php you have to set
# the statement RewriteBase /phpBB/
#
#RewriteBase /

#
# Uncomment the statement below if you want to make use of
# HTTP authentication and it does not already work.
# This could be required if you are for example using PHP via Apache CGI.
#
#RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

#
# The following 3 lines will rewrite URLs passed through the front controller
# to not require app.php in the actual URL. In other words, a controller is
# by default accessed at /app.php/my/controller, but can also be accessed at
# /my/controller
#
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ app.php [QSA,L]

#
# If symbolic links are not already being followed,
# uncomment the line below.
# http://anothersysadmin.wordpress.com/2008/06/10/mod_rewrite-forbidden-403-with-apache-228/
#
#Options +FollowSymLinks
</IfModule>

# With Apache 2.4 the "Order, Deny" syntax has been deprecated and moved from
# module mod_authz_host to a new module called mod_access_compat (which may be
# disabled) and a new "Require" syntax has been introduced to mod_authz_host.
# We could just conditionally provide both versions, but unfortunately Apache
# does not explicitly tell us its version if the module mod_version is not
# available. In this case, we check for the availability of module
# mod_authz_core (which should be on 2.4 or higher only) as a best guess.
<IfModule mod_version.c>
	<IfVersion < 2.4>
		<Files "config.php">
			Order Allow,Deny
			Deny from All
		</Files>
		<Files "common.php">
			Order Allow,Deny
			Deny from All
		</Files>
	</IfVersion>
	<IfVersion >= 2.4>
		<Files "config.php">
			Require all denied
		</Files>
		<Files "common.php">
			Require all denied
		</Files>
	</IfVersion>
</IfModule>
<IfModule !mod_version.c>
	<IfModule !mod_authz_core.c>
		<Files "config.php">
			Order Allow,Deny
			Deny from All
		</Files>
		<Files "common.php">
			Order Allow,Deny
			Deny from All
		</Files>
	</IfModule>
	<IfModule mod_authz_core.c>
		<Files "config.php">
			Require all denied
		</Files>
		<Files "common.php">
			Require all denied
		</Files>
	</IfModule>
</IfModule>

DirectoryIndex index.html intro.php portal.php index.php index.htm

und der Link zum aktivieren der Ext so:

Code: Alles auswählen

http://forum.bulldog-bt1100.de/adm/index.php?i=acp_extensions&sid=cff5657e0ca196d725753c13460703d6&mode=main&action=enable_pre&ext_name=o0johntam0o%2Farchive

Auffällig hier ist für mich dieser Part:
ext_name=o0johntam0o%2Farchive

ist dies evtl das Problem zum nicht aktivieren der Ext???

Beitrag von **Mahony** » 13.03.2017 10:40

Hallo
Nimm mal Testweise das hier aus der .htaccess

DirectoryIndex index.html intro.php portal.php index.php index.htm

Dann würde ich mal testen, ob das Problem auch mit prosilver auftritt.

Das hier

Code: Alles auswählen

[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 182

deutet eigentlich auf Probleme mit den Berechtigungen hin.

Grüße: Mahony

Beitrag von **Melmac** » 13.03.2017 10:59

Ich mische mich ja nur ungerne ein ...

Mahony hat geschrieben: Dann würde ich mal testen, ob das Problem auch mit prosilver auftritt.

Nicht nur testen, sondern definitiv auf prosilver wechseln und we_universal deinstallieren:

Melmac hat geschrieben:Dennoch mal ganz hiervon abgesehen bleibt immer noch das Thema, dass Du einen Style für die 3.1-Linie einsetzt, der, auch laut aktuellem Maintainer, eben nicht wirklich kompatibel mit 3.2.0 is

Code: Alles auswählen

# General Information about this style
name = we_universal
copyright = Â© INVENTEA
style_version = 2.4.5
phpbb_version = 3.1.8

Jörg-CH · Beitrag von **Jörg-CH** » 13.03.2017 12:32

Einmischungen sind gewollt , aber ich habe das Style deinstalliert und ohne Erfolg...selbe Meldungen

Nach der Bereinigung der DB bekomme ich zum Schluss ebenfalls die folgenden Meldung angezeigt:

Notfall-Reparatur

[phpBB Debug] PHP Notice: in file [ROOT]/phpbb/auth/auth.php on line 908: Undefined offset: 182

FILE: [ROOT]/phpbb/auth/auth.php
LINE: 908
CALL: stk_msg_handler()

FILE: [ROOT]/phpbb/auth/auth.php
LINE: 881
CALL: phpbb\auth\auth->_set_group_hold_ary()

FILE: [ROOT]/phpbb/auth/auth.php
LINE: 419
CALL: phpbb\auth\auth->acl_raw_data_single_user()

FILE: [ROOT]/phpbb/auth/auth.php
LINE: 67
CALL: phpbb\auth\auth->acl_cache()

FILE: [ROOT]/stk/common.php
LINE: 55
CALL: phpbb\auth\auth->acl()

FILE: [ROOT]/stk/index.php
LINE: 18
CALL: require('[ROOT]/stk/common.php')

Klicke hier um das STK neu zu laden.

Wenn ich die Option "Doppelte Berechtigungen bereinigen" auswähle passiert nach dem OK nicht ausser das ich auf die Startseite des STK komme....

Gibt's noch andere Möglichkeiten die Berechtigungen zu korrigieren oder sogar komplett zu löschen und neu anzulegen ????

Beitrag von **Mahony** » 13.03.2017 12:55

Hallo

Jörg-CH hat geschrieben:Gibt's noch andere Möglichkeiten die Berechtigungen zu korrigieren oder sogar komplett zu löschen und neu anzulegen ????

JA - siehe http://phpbb3.pytalhost.com/viewtopic.php?f=11&t=211

Grüße: Mahony

Beitrag von **vfrblue** » 13.03.2017 13:15

Jörg-CH hat geschrieben:Nunja bei 30ext war es über die dB einfacher
Danach habe ich das automatische Update gemacht mit diversen Timeouts beim Update der Datenbank .
Danach habe ich m acp wieder die ext aktiveren wollen. Aber schon da danach habe ich die Fehler bekommen .

Nach dem ich 19ext deinstalliert habe bin ich nicht mehr ins adm gekommen und musste den Cache über Ftp leeren und die anderen Ext über die Ext
deaktivieren........dann bin ich in wieder ins ADM gekommen....

Nun nachdem ich alles deaktiviert habe erhalte ich die Meldung :

No route found for "GET /"

auf der Hauptseite....

Gruß Jörg

Wenn ich mal was dazu schreiben darf:
Bei Wiederherstellungen der Datenbank mit PHPMyAdmin, die ich lokal und auf dem Webspace durchgeführt habe, hatte ich auch des öfteren Timeout-Fehler. Das hat dazu geführt, dass die gleichen Probleme mit dem Update auf phpBB 3.2 auftraten.
Ich habe dann die Wiederherstellung der Datenbank über Putty mit Mysql serverseitig durchgeführt. Das hat ohne Timeout-Fehler geklappt, und das Update ist auch sauber durchgelaufen.
Ähnliche Fehler treten, nach meinen "Erfahrungen", auch auf, wenn die Datenbank-Aktualisierung der Installationsroutine nicht sauber durchläuft.
Wollte ich nur mal anmerken.

Jörg-CH · Beitrag von **Jörg-CH** » 13.03.2017 17:53

Also Datenbank einmal auf alte Version zurücksetzten und dann über putty das Update starten....

Danke dir...

Beitrag von **vfrblue** » 13.03.2017 18:13

Jörg-CH hat geschrieben:Also Datenbank einmal auf alte Version zurücksetzten und dann über putty das Update starten....

Danke dir...

Wenn du über die normale Installationsroutine bei der datenbankaktualisierung Timeout-Probleme hast, dann kann man über Putty die Aktualisierung starten. Hier hast du noch mehr Infos: viewtopic.php?f=145&t=239187

Jörg-CH · Beitrag von **Jörg-CH** » 13.03.2017 20:03

edit.....

nach dem ich die bemängelten auth_option_id gelöscht habe läuft das Forum nun ohne ext wieder mit prosilver...
wenn ich nun aber die original ext "viglink" deaktivere, kann ich sie nicht mehr aktivieren....und erhalte immer die servermeldung error 500...
im Log file da finde ich keinen eintrag der mimr weiter helfen würde.........

lg Jörg

phpBB.de

[3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet

Re: [3.2] diverse URLs werden nicht mehr geöffnet