Menu

проблем

Промяна на permalinks във wordpress

, , , , , 0

Привет,

Отдавна се каня да направя промяна на permalinks във wordpress блога ми. Това което ме притесняваше ( и се случи ), е евентуалните проблеми след това – а именно липсващи URL адреси които да водят до 404 :/

Досега използвах следният тип permalinks :

/%postname%/

и исках да премина към:

/%category%/%postname%/

Промяна на permalinks във wordpress

След въпросната промяна, обаче обикновенните линкове (от постове например) спряха да работят. Мислих си, че самият wordpress ще оправи този проблем – но уви..

Пробвах и няколко плъгина за redirect но с нито един от тях нямах успех.

Не съм сигурен дали причината за това, е използването на nginx като уеб сървър, но така или иначе се принудих сам да си напиша redirect-ите за всичките около 1000 поста в сайта :O

Използвах sitemap-a за постове от където взех линковете и ги завъртях с for за да си улесня работата. Всичко стана 6 с изключение на URL-ите които бяха с кирилица – при тях трябваше ръчно да се променят един по един 🙁

И в крайна сметка няколко часа след това си реших този скапан проблем – вече всички URL са оправени и не трябва да има 404.
Също така, още вчера съм пинг-нал google bot-а да провери блога на ново, за да вземе новите адреси от sitemap-овете, и да го индексира правилно.
До тогава обаче съм се застраховал чрез 301 redirect-ите за които написах по-горе.

Общо взето това ! 🙂

MySQL Too many connections

, , 0

Привет,

Често ми се случва да оправям проблеми с MySQL сървъри където по подразбиране max_connections е сложен на 125. Заради това, когато имаме по натоварена система (като в една laravel апликация) се получи следния проблем :
Fixing MySQL too many connections

Проблемът

Проблемът идва от запълване бройката на тези max_connections. За да се провери колко са използваните в момента се пише следната команда в MySQL терминала :

mysql> select @@global.max_connections;
Още..

Проблем с Java

, , , , , , , 0

От известно време се боря с един странен проблем в сайта на Търговския регистър – http://public.brra.bg . Проблема е, че вече немогат да се използват пълноценно услугите му. Бях им писал мейл но глас в пустиня..

Вчера реших да разследвам и звънях на фирмата доставчик на електронни подписи. Проблема ми е че тестовото подписване минава, при справка или качване на документи след цялата процедура излиза грешка : Грешка при подписването на цялата заявка!

проблем с Java

Оказа се, че проблема съществува и в сайта на НАП,НОИ и всички останали институции които ползват Java. След последният ъпдейт на Java – а именно версия Java 7 update 25 всичко спира да работи по сайтовете.

Предполагам че е необходимо самите сайтове да си обновят системите, но за сметка на това, от IT отдела на Търговския регистър ме посъветваха да си сваля версията на Java – колко прозорливо нали?

Е ок, но се оказа, че примерно версия 7 21 има автоматичен ъпдейт и не става да се използва. За това се натъкнах и на временно решение на проблема – а именно Java 7 Update 17 . Може да се изтегли от адрес : oldapps.com като преди това трябва да се деинсталира всичко що е Java от пц-то. Полезно е също така да се изключат ъпдейтите (обновяванията) на самата Java от Control Panel, Java.

И вече можем да използваме отново услугите на Търговския регистър! Ура! Да видим само, кога ли ще спре нещо друго, след поредната нова версия от Oracle 🙂

20.09.2013 – Проблемът отново се появи!!

Днес се установи че проблемът с Java и сайта на Търговския регистър отново е на дневен ред! Решението е ъпдейт на Java до – Java 7 Update 40 (последната актуална версия)

– Извода: От Търговския регистър най-накрая са си обновили сайта и явно много хора са изревали заради този проблем!!

 

Последна промяна : 20.09.2013 – Николай

 

Странен проблем с lighttpd

, , , , 0

От няколко дни наблюдавам странен проблем при lighttpd-то което обслужва статичните съдаржания по сайта. Всички снимки от галерията се отварят доста тромаво , все едно не ми е локално ами се намирам в Танзания.. преставям си хората които наистина се намират на далече какво им е на тях. Тъй като ми е дерт да го направя хубаво и снимките най-вече да се отварят мега бързо от 2-3 дни изпробвам разни опции .. Уви не е от тях, не е и от опциите в sysctl-то. Общо взето незнам от къде е проблема.. много странно. Явно нещо се е омазало , но тъй като е 1:16АМ и не ми се занимава да разнищвам , смених cdn-то да работи на nginx и .. :shocked: всичко си работи повече от отлично вече. Този проблем за мен не е решен и ще го разнищя и ще споделя съответно от къде е бил проблема , съмнявам се че трябва да ребуутна сървъра заради многото промени по sysctl-то но едва ли ще е от това.. Утрото е по-мъдро от вечерта казали умните глави и легнали да спът :biggrin:

Пробем с блога

, , , 0

Вчера аз големия акъл реших да продължа мисия „внедряване на cdn в блога“ като не мислих че нещата ще се объркат толкова 🙂 Няма да изпадам в подробности , само ще споделя че усрах базата и се оказа че последния бекъп е от 29.12.2012 . Всички бекъпи на бекъп сървъра са на другия mysql сървър, а блога нали работи на localhost … защо да има бекъп и той 🙂 Е вече има. Загубата не е кой знае каква , снимки и тн всичко се пази. Днес започвам новата мисия „възтановяване на сайта“ Ще се опитам да извлека всичко от sql-а който имам за 24.03.2012 . Това което разбрах е че backup-а който прави wordpress-a за един … не става и че ще си я карам с bash скрипта ръчно с кронтаб. Надявам се до няколко дни всичко да си бъде по старо му , а вчера за малко да спра блога завинаги. Проблема е , че той работи от много години , че в него има много интересни случки и мисли които съм писал. Всяко зло за добро:) Айде до следващия пост!