Witam
Podczas używania na hostingu AZ.pl wspomnianego edytora zauważyłem brak uploadu plików do katalogu przez ów skrypt. Zwykły upload pliku (input z parametrem file) na serwerze działa, działa także tworzenie, usuwanie katalogów przy użyciu owego edytora i pluginu. Błąd jednak wyrzuca przy próbie wgrania zdjęcia na serwer (zmienna TB_MSGUPFAIL, czyli upload failed). Ścieżki ustawiłem i prawidłowo wskazują miejsce, bo ów komunikat je wyświetla tak jak być powinny. W skrypcie browsera nawet ryzykownie ustawiłem Unixowe prawa jako 777 i katalog obrazów wraz z podkatalogami także mają ręcznie zmienione prawa na 777, a mimo to skrypt dalej wywala błąd. Czy ktoś korzysta z hostingu AZ i natknął się na ten sam problem?
Jeśli zaś rozwiązał, lub mu działa owa kombinacja, to czy mógłby rzucić mi na nią nieco światła?

Nieco grzebałem przez ostatnie godziny i zauważyłem w logach, że następuje zamotanie przy pluginach. Logi wskazują bowiem ciekawą rzecz. Następuje próba załadowania /tiny_mce/plugins/tinybrowser/editor_plugin.js co jest niemożliwe z prostej przyczyny: plik ten jest plikiem innego plugina, advimage. To z tego plugina tinybrowser jest wywoływany między innymi. W funkcji init TinyMCE załączam oba pluginy jak w jakimkolwiek przykładzie na necie i wskazuję na tinyBrowser jako file_browser_callback. Błąd do loga wpisuje się w momencie załadowania strony, czyli wynika z tego, że w momencie inicjalizacji edytora na stronie "myli" ścieżki do tego pliku, chcąc pobrać go z całkiem innej lokalizacji.

Kolejny trop... Do wielkości pliku około 50kB wyświetla tylko info związane z TB_MSGUOFAIL... Powyżej tej wartości wyskakuje popup "Error404 Upload failed". Zauważyłem także, że na AZ domyślnie są włączone opcje: Magic Quotes gpc oraz Register Globals, czego nie miałem na localu. Zmiana jednak ich na włączone nie spowodowała błędnego działania na localhost, więc raczej to nie to :/ Zmieniłem na localu także wersję php na tę co na serwerze - bez rezultatu. Po prostu zaciąłem się :/

Dałem sobie spokój z tym i przeniosłem na inny hosting bo nie widzę sensu wgrywania plików i ich miniatur za każdym razem ręcznie na serwer przez ftp lub sprawdzania, które zmienne serwera są ustawione nie tak jak być powinny :/ Już i tak 2-3 dni ten błąd próbowałem zlokalizować bez powodzenia i jedyne co mogę powiedzieć to -> omijać AZ z daleka bo nie można dojść co mają tak naprawdę w domyślnej konfiguracji powłączane, co nie i w jakim trybie. Ja doszedłem, że serwer chodzi w FastCGI, nie jako moduł Apache'a (errory 500 przy ustawianiu zmiennych php poprzez htaccess), z powłączanymi magic quotes i register globals mimo PHP5, gdzie domyślnie są one przecież wyłączone. O bezpieczeństwie mniej doświadczonych webmasterów można zapomnieć. A gdyby nie fakt, że się googlało to nigdy bym się chyba nie doczekał zmiany w php.ini (w katalogu domeny jest on dostępny), gdyż trzeba ich o tym poinformować i łaskawie czekać godzinę na jakąkolwiek zmianę. A teraz zrób literówkę w tym pliku i czekaj kolejną godzinę aż Ci system stanie znów "na nogi" :/ O jakości zaś tego hostingu nawet nie piszę, bo już wystarczająco wielu napisało. Człowiek myśli, mota się gdzie błąd, a ostatecznie okazuje się, że hosting ma coś w ustawieniach zrąbane. Dodam tylko, że kod testowałem nie tylko na AZ i localhoście (jeszcze kilka innych hostingów mam w dostępie) i jedynie AZ cyrki powodował.