Problem z przyjaznymi adresami i locale po aktualizacji z 3.x

[wify]

Witam,

 

Konfiguracja: IPB 4.3.5, Windows Server 2008 R2, PHP 7.2.7, MySQL 5.6.14

 

Po aktualizacji z IPB 3.4.9 do 4.3.5 wystąpiły dwa problemy, które wg IPS (mam ciągle otwarty ticket) są wynikową "błędów konwersji UTF8". Cytuję z supportu:

 

Cytat

This indicates that your utf8 conversion didn't process properly in this case, do you have a full backup from before you processed this? as you may need to restore to 3.4.9, then our developers and process the utf8 conversion for you to work out any issues with your special characters. 

 

Cytat

You are going to need to revert back to the 3.4 instance from your backup first of all, so we can fix the issues with the database. They need to be resolved prior to the upgrade unfortunately. 

 

Cytat

I'm very sorry, but unfortunately, our support for Windows environments is limited. While we can access the site, I'm afraid we cannot work as you're requesting -- take a database, fix it, give it back to you and work within the confines of the Windows environment.

 

[Ostatnia odpowiedź dopiero po dwóch dniach, choć podane było od razu, że działam na Windows Server!]

 

Szukam pomocy i tutaj na forum, gdyż mam pewne wątpliwości co do tej diagnozy. Forum nie było konwertowane na UTF8 przed aktualizacją (od lat działało w tym kodowaniu bez błędów), a pierwszy z problemów opisanych poniżej nie wystąpił na lokalnej testowej instalacji (ta sama baza danych).

 

 

1. Przyjazne linki zawierające Polskie znaki produkują błąd:

 

"Pętla przekierowań

Podczas łączenia z serwerem wystąpił błąd."

 

Błąd przestaje się pojawiać po wyłączeniu opcji IPB4 Rewrite URLs.

 

Nie działa:

https://www.fixitpc.pl/forum/38-dzia%C5%82-pomocy-dora%C5%BAnej/

Działa:

 

https://www.fixitpc.pl/index.php?/forum/38-dzia%C5%82-pomocy-dora%C5%BAnej/

 

Zawartość pliku web.config  (IIS, Windows Server 2008 R2):

 

<rule name="pretty urls" enabled="true" stopProcessing="true">
                    <match url="." ignoreCase="false" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="/index.php" appendQueryString="true" />
</rule>  

 

Jak zaznaczone, ten problem ujawnił się dopiero podczas upgradu na żywo, na localhoście nie było problemu.

 

 

2. Podobny problem jak tutaj, tzn. brak określonych fraz w widoku forów (typu Dziś, Piątek) + polskie czcionki zastąpione pytajnikami w niektórych frazach Kalendarza + ale dodatkowo też symbol zastępczy w numerach postów.

 

 

 

Jest wgrane locale "pl" na serwerze. Po wgraniu "en" (było potrzebne, by z powrotem przestawić język domyślny na angielski) menu języków przestało także pokazywać angielską flagę.

 

 

 

 

Czy ktoś ma jakiś pomysł?

 

 

 

 

 

Edytowane 7 Sierpnia 2018 przez wify

[wify]

Aktualizacja do punktu 2 (na bazie ciągów w dokumentacji MS) :

- Flaga angielska w menu języków została naprawiona. Wystarczyło wpisać "usa" zamiast "enu" jako locale.

- Również brakujące polskie frazy w widoku forum oraz zastępowanie polskich czcionek pytajnikiem zostało naprawione poprzez wpisanie jako locale "plk" lub ew. "polish".

Pozostaje jednak problem z formatowaniem separatora w numerach, nadal jest ten zastępczy symbol � oraz oczywiście problem numer 1 z przyjaznymi linkami.

 

 

 

Edytowane 7 Sierpnia 2018 przez wify

[wify]

Bardzo przepraszam za podbijanie tematu, ale czas edycji jest tu ograniczony. Zastępczy symbol � został naprawiony na podstawie dokumentacji MS.  W pliku IPB4 ...\system\Lang.php kod:

 

$this->locale = localeconv();

... został zastąpiony przez:

$locale_info_from_windows = localeconv();
$locale_info_from_windows['thousands_sep'] = iconv('Windows-1252', 'UTF-8', $locale_info_from_windows['thousands_sep']);
$this->locale = $locale_info_from_windows;

 

Dla porównania podobny problem z Windows Server w tym wątku, tylko rzecz jasna o inną definicję rzecz się rozbijała.

 

Czyli problem numer 2 został przeze mnie samodzielnie naprawiony. Zostały mi te nieszczęsne przyjazne linki. Bardzo proszę o jakiś pomysł...

 

 

 

 

[Ernislav002]

Nie jestem pewny, ale w sprawie przyjaznych linków po zmieniaj patterny w IIS bo masz trochę dziwnie ustawione.

 

[wify]

Dzięki za odpowiedź. Co masz konkretnie na myśli? Oryginalny plik htaccess generowany przez IPS posiada następującą definicję, odpowiadającą regule zdefiniowanej w moim pliku web.config:

 

RewriteRule . /index.php [L]

 

Problem z przyjaznymi linkami występuje tylko i wyłącznie dla adresów posiadających znaki Unicode. Ta sama zasada działa też na IPB 3.x.

 

[Ernislav002]

3 godziny temu, wify napisał:

Dzięki za odpowiedź. Co masz konkretnie na myśli? Oryginalny plik htaccess generowany przez IPS posiada następującą definicję, odpowiadającą regule zdefiniowanej w moim pliku web.config:

 

RewriteRule . /index.php [L]

 

Problem z przyjaznymi linkami występuje tylko i wyłącznie dla adresów posiadających znaki Unicode. Ta sama zasada działa też na IPB 3.x.

 

IIS ma od dawna problem z kodowaniem znaków w URL-ach.

Tutaj znalazłem coś co może ci pomóc.  

https://forums.iis.net/t/1229593.aspx?URL+Rewrite+Module+decodes+UTF+8+encoded+querystring+as+if+it+were+iso+8859+1

PS. podrzuć logi z IIS gdy wykonujesz URL co ci w logach zwraca. 

Edytowane 8 Sierpnia 2018 przez Ernislav002

[wify]

Dzięki. Ustawienia IIS oraz testy z (de)kodowaniem URL mam już dawno za sobą, bez rezultatu. Natomiast przejście na ISAPI Rewrite z htaccess IPSu mam w planie, dziś wieczorem będę to testować. Na localhoście był bowiem Windows w kombinacji z Apache i tam nie było problemu.

[Ernislav002]

okej, a jeszcze podpytam php TS czy NTS?

[wify]

Niestety. Po wyłączeniu reguły w IIS URL Rewrite na korzyść ISAPI Rewrite ten sam błąd. Nie rozumiem dlaczego ten sam konfig na IPB 3.x nie produkuje błędu z linkami Unicode.

 

Support IPS nie ma mi nic do powiedzenia, poza ... przeniesieniem się na Linuxa, by mogli "wykonać diagnostykę".

 

 

Cytat

okej, a jeszcze podpytam php TS czy NTS? 

 

NTS.

[Ernislav002]

57 minut temu, wify napisał:

Niestety. Po wyłączeniu reguły w IIS URL Rewrite na korzyść ISAPI Rewrite ten sam błąd. Nie rozumiem dlaczego ten sam konfig na IPB 3.x nie produkuje błędu z linkami Unicode.

 

Support IPS nie ma mi nic do powiedzenia, poza ... przeniesieniem się na Linuxa, by mogli "wykonać diagnostykę".

 

 

 

NTS.

A spróbuj tego kodu

<rule name="Remove index" stopProcessing="true">
               <match url=".*" />
               <conditions logicalGrouping="MatchAll">
                 <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                 <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
               </conditions>
               <action type="Rewrite" url="index.php" />
            </rule>

 

[wify]

Ten kod nie powoduje żadnych zmian. Wcześniej była już próbowana masa kombinacji i nici. Mój web.config działa za to poprawnie na IPB 3.x.

 

Dla porządku dodam, że plik z ISAPI Rewrite miał postać:

 

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [NE,L]

[Na początku tylko flaga L, potem próba z innymi]

[Ernislav002]

Musiałbyś spróbować przechwycić link jaki odczytuje IP.Board i wtedy jakoś to wydebugować? hmm

[wify]

Problem rozwiązany. Nie mogę uwierzyć jak proste to było, siedziałam nad tym od niedzieli! Rozwiązanie jest w KB2277918. Hotfix się nie aplikował, bo pliki na serwerze były w nowszej wersji, ale ta opisana na spodzie prosta edycja rejestru (utworzyć wartość FastCGIUtf8ServerVariables ustawioną na REQUEST_URI) załatwiła sprawę od ręki.

 

Mam nadzieję, że moje znaleziska pomogą innym użytkownikom Windows Server, bo na support nie ma co liczyć (ticket był już w Tier II i kicha). Nie dość, że powierzchownie i całkowicie błędnie sklasyfikowali problemy, to jeszcze mnie wpuszczali w bardzo gęste maliny, tzn. downgrade do IPB 3.x (podczas gdy wiedzieli, że i tak nie przetworzą bazy, bo nie pracują pod Windows Server), a już hitem była namowa na przeniesienie bazy danych pod Linuxa, by mogli wykonać diagnostykę. Wszystkie problemy zostały rozwiązane przeze mnie samodzielnie. Jak już się wie w czym rzecz, sprawa jest banalna.

 

Bardzo dziękuję za próby pomocy. Temat można zamknąć.

[DawPi]

Rozwiązania zwykle są "proste" jak się je zna.

[DawPi]

Problem ROZWIĄZANY. Jeśli są jakiekolwiek wątpliwości, pytania proszę o założenie nowego tematu.

Wszelkie uzasadnione reklamacje/pretensje/sugestie/rady przyjmuje ekipa forum.

[DawPi]

Dodatkowe wyjaśnienia przesłane przez @wify (dzięki!):

Cytat

Thank you for bringing this issue to our attention! I have submitted a potential fix and pending approval from our development and QA teams, this should make its way to an upcoming release. Unfortunately, I do not have an ETA for that at present and apologize for any inconvenience this issue has caused.