savek blog

Tak jak pisałem upgrade WordPress z 1.5.2 do 2.0 przeszedł bez najmniejszych problemów. Te pojawiły się dopiero podczas testowania funkcji galerii o której pisałem już wcześniej.

Sama obsługa załączników (jako plików na serwerze) także została bardzo usprawniona. Nie jest to tak jak do tej pory – jeden katalog z plikami, ale cała struktura z podziałem na rok, miesiąc etc. Teraz nareszcie będzie można zapanować nad większą liczbą załączonych obrazów.

Pliki ładwowane są do katalogu: “WP_root/wp-content/uploads/rok/miesiąc”. Gdzie rok to np. “2005″, a miesiąc “12″ (oczywiście jasne, że to przykład dla grudnia 2005). Zatem plik graficzny ładowany na serwer jest odpowiednio katalogowany, i wiadomo które załączniki są do jakich notek. W WP 1.5.x był to jeden globalny katalog do którego były ładowany wszystkie załączniki przez co powstawał ładnie mówiąc bałagan

Wszystko wygląda super, testowałem WP 2 RC 1 i 3 na moich lokalnym ale windowsowych serwerze (zamiast na Suse :/) i nie zauważyłem przez to pewnego zjawiska …

Wspomniany wyżej katalog “WP_root/wp-content/uploads/”, nie jest tworzony domyślnie przez WP, więc próba wysłania załącznika zakończy się komunikatem

Unable to create directory /home/user/domains/np.twoja.domena/public_html/np.katalog/wordpres/wp-content/uploads. Is its parent directory writable by the server?

Nie wiele myśląc utworzyłem katalog w odpowiedniej lokalizacji po czym dałem mu

$ chmod 777 uploads

Po czym ponowiłem próbę wysyłania załącznika zakończoną sukcesem. Wygląda piękne prawda… Plik został załadowany to katalogu w podanym wyżej schemacie “…/uploads/2005/12/plik_graficzny.jpg”, została też utworzona w tym katalogu miniatura pliku. Problem polega na tym, że katalogi utworzone przez WordPress “rok/mc” mają właściciela i grupę Apache.Apache. Co w praktyce uniemożliwia dostęp do takich katalogów i plików przez FTP, SSH. Tak więc każda próba ręcznego np. przez FTP, skasowania nawet pustego katalogu z mc. czy roku kończy sie informacją

550: Operation not permitted

to samo tyczy sie jakiekolwiek próby z komendami chmod i chown. Jedynie użytkownik root może zmienić prawa dostępu do tego pliku. Rozwiązaniem problemu jest ręczne tworzenie katalogów z rok/mc (format dla stycznia 2006: “2006/01″ itd.) dla uploadu załączników i za każdym razem nadawanie im z osobna

$ chmod 777 katalog

Trochę to nie wygodne, ale daje pełną kontrolę na struktura katalogów. Pliki ładowane przez WP do takich katalogów można kasować przez FTP, oraz także kontrolować za pomocą PA. Zastanawiam się czy nie dało by się teraz rozwiązać w nieco inny, przyzwoity sposób już w kodzie WP za pomocą http://pl2.php.net/manual/en/function.umask.php tak jak sugerował to admin mojego serwera. Oto zapis rozmowy z administratorem:

Piotrek 15:07:49 witam

Piotrek 15:08:31 chodzi o pewna sprawe ktora pojawila sie po instalacji WordPrss 2

Admin Linuxpl.com 15:08:53 no prosze pisac

Piotrek 15:09:27 minanowicie problem opisałem ten dla innego uzytkownika WP2 wiec zeby sie nie powratzac przepisze Panu to:

Piotrek 15:09:28 Komentarz autor Piotrek/savek — 28.12.2005 @ 02:48
Zastanawiam sie jak u innych osob wyglada sprawa z prawami do katalogu wp-content/uploads … u mnie program do upgradu nie utworzyl tego katalogu (do przechowywania zaladowanych obrazow) wiec stworzylem go sam i nadalem mu chmod 777, dziala obrazy sie laduja i moge nimi zarzadzac… z tym ze nie mam do niego dostepu dostepu (nie moge np. kasowac plikow wyslanych na serwer przez WP) przez ftp ani shell. Jedynie przez PA w WP … U Pana jest tak samo ?
Pozdraiam!
Komentarz autor Maciek — 28.12.2005 @ 09:24
Nie mam takowego katalogu, więc nie mam też problemu.
Komentarz autor Piotrek/savek — 28.12.2005 @ 14:37
Nie ma go gdy przez PA nie ładuje się obrazów do galerii. Pierwotnie też go nie miałem. Dopiero gdy testowałem galerię musiałem go utworzyć. WP wewnątrz utworzył katalog ‘2005? i mc. czyli ‘12? – do niego ładował zdjęcia. Całkiem dobry pomysł, bo można w końcu zapanować nad załącznikami graficznymi – wiadomo co jest od czego. W WP 1.5.x był od załączników jeden katalog.

Piotrek 15:10:19 z tego co widze to ow katalogi utworzeone przez WP maja usera i grupe Apache

Admin Linuxpl.com 15:10:45 tak

Admin Linuxpl.com 15:10:57 hmm w takim wypadku nie ma mozliwosci usuwania takich plikow

Admin Linuxpl.com 15:11:00 tylko przez administratora

Piotrek 15:11:12 nie moge ich kasowac przez panel na porcie …. ani tez przez ftp czy ssh

Admin Linuxpl.com 15:11:44 no nie mozesz bo maja prawa innego uzytkownika

Admin Linuxpl.com 15:11:51 chyba zeby sie tworzyly z prawami 666

Admin Linuxpl.com 15:11:59 czyli + rw to moze by byla mozliwosc usuniecia pliku

Piotrek 15:12:00 z 755 sa

Admin Linuxpl.com 15:12:29 czyli +r dla others

Admin Linuxpl.com 15:12:36 mozesz ustawic 666 i sprawdzic

Piotrek 15:13:29 to jest wlasciwe zachowanie sie WP ? czy mozna to jakos poprawic zeby katalogi nie twozyly sie z odp. prawami

Piotrek 15:13:39 probowalem juz

Piotrek 15:13:50 i chmod 666 i chown user.user

Admin Linuxpl.com 15:14:05 w kodzie

Piotrek 15:14:07 i zawsze 550 operation not permitted

Admin Linuxpl.com 15:14:11 umaskiem mozna

Admin Linuxpl.com 15:14:18 nadac prawa tworzacym sie plikow

Admin Linuxpl.com 15:14:21 w kodzie programu

Piotrek 15:14:51 no wlasnie to moze zachodzic na maly bug w kodzie nawet

Piotrek 15:15:03 wordpress 2 stabilny ukazal sie dop. wczoraj

Piotrek 15:16:17 mozna chy tez tworzyc te katalogi recznie i samemu madawac im prawa dostepu tyle ze to malo wygodne i z punktu widzenia nie doswiadczonego usera klopotliwe

Admin Linuxpl.com 15:16:48 http://pl2.php.net/manual/en/function.umask.php

Piotrek 15:18:09 oka dziekuje zobacze co do sie z tym zrobic

Co o tym sądzicie ? U Was też wystąpiły takie problemy ?
Czy wręcz przeciwnie, może jest to celowe zachowanie WP ?

BTW: Po edycji tej notki wyłączyłem edycję w trybie WYSIWYG, jest jak dla mnie mało wygodna … jedyny minus – brak możliwości skalowania wielkości obrazu.

Powiązanie wpisy:

1. WordPress 2.0 RC3
2. WordPress 2.0
3. WordPress 2.0.1 Release

komputery, ogólne, open source, wordpress