Идеята е таблицата "articles" да бъде копирана като "articles_bg" + съдържанието в таблицата "articles":

Ето го и сложното решение от две заявки:

CREATE TABLE articles_bg LIKE articles; INSERT articles_bg SELECT * FROM articles;

Имаме архивирана папка "site" разбита на 2 части от по 15 MB т.е. "site.z01" и "site.zip"

Когато опитаме обаче:

unzip site.z*;

Archive:  site.z01
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of site.z01 or
        site.z01.zip, and cannot find site.z01.ZIP, period.

За да се получи правим следното :) :

cat site.z* > combined.zip && unzip combined.zip;

Това е :)

apt-get update && apt-get install postfix-policyd-spf-perl -y

vim /etc/postfix/master.cf

…
policy-spf  unix  --       n       n       --       --       spawn
user=nobody argv=/usr/bin/perl /usr/sbin/postfix-policyd-spf-perl
vim /etc/postfix/main.cf
…
smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,check_policy_service unix:private/policy-spf
…

Важно: check_policy_service да се намира непосредствено след permit_mynetworks

Системата е prestashop и проблема е, че когато се направи поръчка (order) излиза бял екран (blank page). След debug(показване на грешките) се видя следното:

…
Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 32 bytes) in /home/arogans/public_html/classes/CartRule.php on line 263
…
Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 89 bytes) in /home/arogans/public_html/classes/db/DbPDO.php on line 101
…

Проблема очевидно е, че се ползва повече memory_limit от колкото е позволено. В този момент е позволено да се ползва 512 MB което не е никак малко.

Разгледах за решения от други колеги, но решението беше да се увеличи на повече. Пример: Имаме разрешен 128 MB memory_limit и за да решим проблема трябва да го увеличим на 256MB . До кога с това "решение" … ? Както и да е за мен това не е решение, а по- скоро задълбочаване на проблема.

Както и да е понеже не съм разцъквал особено prestashop направих следното(Изчистих следните таблици, че всяка таблица имаше няколко милиона реда):

truncate ps_connections;
truncate ps_connections_page;
truncate ps_connections_source;
truncate ps_guest;
truncate ps_pagenotfound;
truncate ps_page_viewed;
truncate ps_referrer_cache;
truncate ps_date_range;

Проблема не се оправи :), но все пак се оптимизира сайта и работи далеч по- бързо от преди;

Проблема се оказа в следното: В таблицата където са описани ваучерите имаше изкл. голям брой редове(автоматично се генерират от фейсбук приложение което явно е прекалило с броя ). За да се реши проблема тествах да премахна първо неактивните ваучери т.е. изтеклите:

delete FROM ps_cart_rule WHERE date_to < NOW();

, но това не помогна. За целта премахнах всички ваучери:

truncate ps_cart_rule;

Вярно е, че ваучерите ги няма, но всичко си работи. Сега ще се генерират наново НЕОБХОДИМИЯ БРОЙ ВАУЧЕРИ и всичко ще си е наред :)

PS: Не препоръчвам употребата на готови системи, но няма как те също имат предимстава… макар и не толкова колкото custom системите.

Идеята е, че имаме списък с имейл адреси и фирми , но понеже има вероятност да бъдат дублирани затова се налага да ги премахнем. За целта използваме openoffice.Казвам "електронни таблици" защото това не е excel, но да и в excel също ще работи :)

Може да се премахне през mysql, но тук става по- лесно защото не е въпроса просто да се махнат дублиращите , а да се определи кои ред ще остане като критериите не са особено ясни( т.е. не са известни всички вариации на колоните и затова се налага човешки интелект . Затова не може да се автоматизира така лесно).

Вместо куп обяснения, ще има малка шепа снимки:

Фиг. 1

Фиг. 2

Фиг. 3

Фиг. 4

Фиг. 5

Става ясно, че калкулира дублите и оцветява тези стойности които са по- големи от 1 ;)