WordPress 2.3 ще излезе скоро:)

Ще има някои симпатични нови неща – например, вградена поддръжка на тагове (ще се наложи обаче да си модифицирате темата на блога за целта), автоматична проверка за по-нови версии на plugin’ите, които използвате — uber-cool, както се казва;-)

Естествено, някои по-стари plugin’и пък ще спрат да работят (Google Sitemap Generator 3.0b8 или по-ниска версия, например), но няма да мине много време, и ще излязат по-нови версии и за повечето активно поддържани plugin’и — а ето списък с поддържащите и неподдържащите към момента версия 2.3.

Аз WordPress Upgrade Party няма да правя (както предлага Matt), но поне мисля да си обновя блоговете навреме, да си проверя всички версии на plugin’ите, които ползвам, да си направя backups на файловете и MySQL базите данни и да подредя, каквото има за подреждане.

Време е да си напиша/нарисувам и собствена тема за блога, но засега отлагам тази част от блогващия/дизайнерския процес нейде за неопределено време в бъдещето;-)

(О, и все още чакам някакво развитие по TRAC ticket #4427, за съжаление обаче, познанията ми по PHP не са толкова добри, че да предложа стабилно решение на бъга…)

9 thoughts on “WordPress 2.3 на хоризонта

  1. 100% са ти го вече предложили, но да кажа.. опита ли ln -s за #4427?

  2. Наистина, малко объркващо си писал, може би прекалено дълго ти е обяснението. За това с wp-upload имам предвид. Наистина, и в уеб си работят относителните пътища, сървърите ги разбират и URI от вида http://example.com/bg/../upload/file.jpg не е проблем да си е съвсем валиден.

    Тоест “/bg/../wp-uploads/” и “/wp-uploads/” са смислово напълно еднакви. Може да са малко тромави от SEO гледна точка, но това са URI за машинно четене, адреси на изображения са, а не са нещо, което ще се пише на ръка в браузъра, нали?

    Опиши всъщност кое не работи и как искаш да работи? Тук все ще има хора, които да помогнат. Ако няма — и аз съм бърникал немного в кода на WP, все ще мога да помогна някак ;)

  3. @Turin:

    Мерси за предложената помощ!!:)

    Дълго го обяснявах в ticket-а, за да няма неясноти… Бях писал и в техния support форум, ама нищо не стана.

    Накратко: При WP 2.0.5 можеше да се дефинира директория за uploads на едно ниво над тази, в която се намира блогът. Просто пишеш "../wp-uploads/" примерно в OPTIONS и готово, като качиш файл, в базата данни правилно се записва URL-то и двете точки се сменят с каквото трябва :-)

    След 2.1 нагоре, нещата вече не работят така. "../" си се разчита “директно” като .. и това е… И при всички случаи, WP добавя ABSPATH (http://…) отпред, така че никакъв начин да определиш директория за uploads, която ДА НЕ Е вътре в директорията на блога :(((

    Нали знаеш, че моята “двуезична” система ползва два блога и обща UPLOADS директория. Преди URL-тата за качени през WP снимки бяха от вида: https://www.optimiced.com/wp-uploads/2007/09/image.jpg а сега се добавят тези излишни две точки между тях в IMG SRC и въобще не е правилно така, и некрасиво даже:)))

    Между 2.05 и 2.1 нещо се е променило, но не знам какво… Рових в PHP-то на WordPress (дори ги сравнявах като код, онази част, която отговаря за качването на файлове, и тази за опциите за определяне на UPLOADS директория), без голям успех, нейде из функциите подозирах, че се крие разгадката на мистерията, но не намерих нищо… Хм…

  4. А… защо не напишеш в настройките път спрямо web-root? “/wp-uploads/”? Тоест абсолютен уеб-път; не абсолютен път от файловата система, както пишеш в билета че си опитвал, а директно от / в уеб — /wp-uploads/

    PS Искаш да кажеш, че WP винаги залепя отпред URI на блога, а не само домейна на блога?

    Ще погледна, имам WP някъде… Ще видя как е в UrbanStyle…

  5. @uv:

    Какво е ln -s? :-)

    @turin:

    Там е въпросът, че не позволява никакъв начин на посочване на директория за uploads, която която да не е вътре в самия WordPress! Което си е глупаво… Нито web root приема, нито absolute, нито relative path, нищо… Едниственият начин е да се напише нещо от рода на ../, WP тогава си добавя тези ../ към URL-то, но то някак сработва, макар че не е указано правилно… :-)

    Така или иначе, зарязах inline uploads, и качвам файлове през FTP и на ръка си пиша после URL-тата, не е ужасно трудно:) Но понякога ако качвам само една-две картинки, много по-лесно става през интерфейса на WP…

    Знам, че в 2.0.5 работеше нормално опцията за указване на UPL директория и вътре и извън WordPress… ако можеше някак да сравня 2.0.5 и примерно 2.2, ама само тази част, която се отнася до тази опция с UPL DIR…

  6. “ln” е gnu-програмата за създаване на връзки, съответно и командата е такава. “ln -s” е начинът за създаване на символна връзка между два обекта във файловата система. Надявам се, че си на линукс-хостинг, а не на някакъв изстрадал и измислен уиндоус ;) Символната връзка е нещо като “препратка” във файловата система. Файл или папка съществуват само формално, а съдържанието им всъщност е другаде, те са друга папка или друг файл.

    Например
    $ ln -s /home/optimiced/wp-uploads/ /home/optimiced/bg/wp-uploads/

    създава символна връзка “wp-uploads” в директорията “/bg/”, която сочи към горната директория. В списъка с директории в обвивката или във файловия ти мениджър символната връзка ще ти се показва по някакъв различен начин, за да знаеш, че е такава. Но съдържанието и правата на двете “директории” ще са абсолютно еднакви, нещо повече, съдържанието ще е едно, тоест само на едно място ще е.

    Това е при опцията “-s”, иначе без нея ln прави твърди връзки; на теб ти трябва символна. Влизаш през SSH и пускаш команда като горната, само си написваш твоя си път, какъвто е…

    И така после си посочваш за директория за качвания на българската версия на блога “wp-uploads” която се намира в “/bg”, а за английската — съответно тази в “/en”. И двете ще сочат към едно и също съдържание, това в /home/wp-uploads/ или както там се казва целевата директория на връзките.

  7. @turin:

    Интересен начин, и може и да проработи (хостингът ми е на DH, Linux, нали си спомняш, че дори ти ги хвалих като доста добър хостинг!;-) и мерси за идеята:)

    Но от друга страна, си мислех за някой начин, който да може да оправи самия код на WordPress, така че да работи за всички, без да се налага нещо допълнително:)

    А и бих се радвал да мога да предложа някакъв начин за това, но нещо не ми остават време и знания да сравня 2.05 и 2.1+ :)

  8. Сега хвърлям поглед във WP… Навсякъде в кода се ползва ABSPATH, което е пътят на инсталацията на WP. Тоест явно идеята е била точно WP да “вижда” само в инсталацията си, за да не стават каши навън. Ще видя дали има някакъв лесен начин за заобикаляне, но не ми се вярва. Най-малкото при първото обновяване ще стане пак като преди, понеже май това е стратегията на разработката, да се остава в средата на инсталацията…

  9. @turin:

    Ние тук как се разписахме в коментарите, по-добре да бяхме седнали на по бира някъде с един лаптоп и WiFi;-)))

    За WP: прав си. Въпросът е интересен, обаче, защото от опит знам, че в WP 2.0.5 дефинирането на ../ в OPTIONS -> MISC се “превеждаше” правилно от WP в “иди едно ниво нагоре, и смятай оттам за дефинирането на UPLOADS директория”. В 2.1+ това спря да работи и си мислех, ако може някак да се предложи patch, базиран на парченце код от 2.0.5, щеше да е супер:)

Leave a Reply

Your email address will not be published. Required fields are marked *