Максим Е

Считаю важным упомянуть, что jQuery в WP по дефолту работает в режиме noConflict, который отключает использование символа $ в качестве шортката функции jQuery().
Ответ, который вы отметили правильным, таковым не является, в отличие от ответа Сергей. Действительно, лучший выход - это инкапсуляция. Хотя есть и другие способы. К примеру, можно в начале вашего скрипта написать одну строчку:
var $ = jQuery;

Самое простое что вы можете делать в этой ситуации обновлять версию файла каждый раз при изменении чего-то в коде. Например так:
<link rel="stylesheet" href="style.css?v=1" />
внесли какие-то изменения, обновили версию:
<link rel="stylesheet" href="style.css?v=2" />
и т.д.

Этот нехитрый прием позволит вам говорить пользовательским браузерам, когда именно нужно перезаписать файл в кеше.

Весьма глупо оценивать "говнокодерность" вашего подхода только потому, что вы храните массив в ненормализованном виде. Чтобы это увидеть, достаточно вспомнить само понятие нормализованных данных и подумать о его сути. Вот вам пример в лоб: вы же почему-то не говорите, что хранить строку в БД это плохо. А ее, в теории, можно представить как массив символов и нормализовать так, что одна строка некоторой таблицы будет хрнить ОДИН символ. Чушь, скажете вы? Да, для большинства задач это чушь (хотя, возможно не для всех). Просто потому, что НИКОМУ не нужно извлекать из базы ЧАСТЬ строки, какое-либ подмножество ее символов. В большинстве задач строка берется как атомарное (!) значение и именно _поэтому_ ее никто не пытается хранить посимвольно. У нас есть лишь один полезный критерий - что для вашей задачи есть атомарные значения? Все. Если вы ваш массив всегда будуте записывать и извлекать сразу целиком, то и хранить его как единственное значение в поле одной записи - совершенно не проблема.
Почему-то все считают, что пока не нормализуешь "до чертиков", спроектированная база никуда не годится. Да, конечно нормализация важна, есть смысл даже нормализовать "с запасом", как уже сказали выше - на случай, если какие-то данные впоследствии также будут фильтроваться и обрабатываться на уровне БД с помощью SQL. Однако если вы четко осознаете, что в ближайшем будущем вы не собираетесь работать с массивом поэлементно (на уровне SQL), то хранить его целиком пойдет только пользу.
Все же юзают JSON и XML-типы данных в SQL базах, и ничего. И блобы юзают. Потому что если проектировщик знает, что планируется обрабатывать в запросах, а что - нет, то он знает и до какой степени нужно нормализовать данные.
trevoga_su привел великолепный пример с конфигом пользователя. Зачем пытаться его навороченную структуру (например, иерархическую) спроецировать на реляционную БД, если проще хранить его в естественном виде (JSON/XML/plaintext) и писать в БД целиком?
P.S. Массив кстати можно хранить не в текстовом виде, а в двоичном в BLOB-е, тогда и места займет меньше, и никаких вопросов с кодировками.

В идеальном мире, где пони какают бабочками, так делать конечно нельзя.
В нашем мире, такое есть, к примеру, в Wordpress - самой популярной CMS в мире.
Разумеется, у вордпресса весьма уродливый код, но это не мешает им быть сверхуспешными.

Давайте по чесноку. Нормализированная таблица это круто, но зачастую очень дорого. Кинуть данные сериализированного массива в ячейку и потом ее достать - 10 минут работы программиста.
Проектировать хорошую БД - на порядки сложнее (и требует программистов более высокой квалификации).
И самое печальное, второй вариант на 1500 записей не нужен. Можно и в файлах хранить, в общем то. Но с БД будет несколько прикольных фич из коробки. Если хранить в файлах, нужно писать ORDER или SELECT самим, что занимает некоторое время.

Поэтому, с точки зрения бизнеса, подход "и так сойдет" более выгоден по деньгам, хоть и оскорбляет ваше чувство прекрасного.

Alexander-K

• Проведите аудит сайта на предмет косяков (инструменты вебмастеров Вам в этом помогут)
  
• Если сайт еще не добавлен в гугл и яндекс вебмастер, то добавьте.
  
• Исправьте косяки, sitemap, robots.txt, meta-теги, описания страниц, заголовки, оптимизация содержимого страниц, перелинковка и т.д.
  
• Скормите карту сайта поисковикам

  http://google.com/webmasters/sitemaps/ping?sitemap=ссылка на Ваш sitemap
  http://www.bing.com/webmaster/ping.aspx?siteMap=ссылка на Ваш sitemap

  
  Для того чтобы яндексу карту отправить, придется зайти на страницу вебмастера. И до кучи можете воспользоваться сервисом пинга в 40 поисковиков.
  
• Если сайт региональный, то задайте регион.
  В яндекс вебмастере задается в настройках сайта, География сайта → Регион сайта
  В гугловских инструментах вебмастера, Поисковый трафик → Таргетинг по странам и языкам → Страна
  
• Составьте семантическое ядро
  
• Напишите SEO тексты заточив под ключи по которым будете двигаться
  
• Если сайт не статичный, зарегайте его в соц сетях и постите туда новости со ссылками на свой сайт
  
• Регайтесь на крупных форумах, с ссылками не закрытыми от индексации и напишите там про Ваш сайт
  
• Оставляйте комменты в dofollow-блогах
  

"Тупо регится на площадках" и спамить ссылку на Ваш сайт, не зная ключей по которым двигаетесь, бесполезно и вредно.

У меня есть действующая доменная почта для гугла и яндекса. Если кратко:
Google Apps — Яндекс
Платно — бесплатно
Фильтры плохи — хорошие
Скорость загрузки низкая — высокая
Возможность пересылать несколько писем отсутсвует — присутсвует
Удобство гугл аккаунта как единственного аккаунта — нет такой опции
Интерграция с гугл диском и гугл докуементами есть — жалкое подобие в виде яндекс диска
Синхоронизация контактов с телефоном отличная — через жопу
Интерфейс ногу сломаешь — отличный
Встроенный календарь отличный — говно
Возможность встраивать приложение для почты (например плагины для систем управления проектами) прямо в веб-морду gmail — нет таких опций (насколько мне известно).
Возможность отправлять письма с задержкой с помощью сторонних платных приложений — бесплатная встроенная возможность.
Возможность создавать любое количество псевдонимов для почты — можно использовать в качестве псевдонима формат типа <номертелефона>yandex.ru
Приятный интерфейс написания нескольких писем без закрытия основного веб-интерфейса — нет такого интерфейса.
Нет уведомления получателя по СМС — есть такое уведомление.

Функциональность Gmail огромна, но во многих местах реализована не шибко юзерфрендли.

1) Почему не взять отдельный слабенький десктоп и из него сделать сервер?
2) Для хостинга сайтов ставите apache, nginx или что вы еще хотите.
3) Для mail-сервера что нагуглите, на ваш вкус (их много).
4) Для FTP та же история, ставите хоть ProFTPD, хоть что другое.
5) Для удаленного рабочего стола в зависимости от ОС выбираете нужный протокол и используйте (обычно с коробки уже всё есть)
6) VirtualBox и на нее окна
7) С wifi нужно будет повозиться - можете почитать статьи в интернете.

Если кого не затруднит, как можно более подробнее опишите пожалуйста, я понимаю что в гугле много всего можна почитать, но как это все вместе связать и чтобы заработало я пока не понимаю

Вы сначала начните ставить по статьям. Вот когда не будет что-то получаться, тогда и пишите сюда. А так - это ответ, который не вложится в быстрый.

У Яндекса проще интерфейс настройки. Значительно проще. В Гугле мне надо было сменить днс… С тех пор я пользуюсь Яндексом )

Пользуюсь яндекс почтой, не могу сказать какие-то его плюсы, просто мне он удобнее. На счёт вложений, яндекс не раз выручал, когда я забывал прикрепить файл к письму — пруф.

Уважаемый автор вопроса, конечно, написал, что не хочется ставить apache+php+mysql по отдельности, но я все же позволю себе заметить, что это совсем не проблема, нужно только чуть-чуть потрудиться.

На самом деле сейчас установка этой связки по отдельности занимает от силы 15 минут + еще столько же времени — конфигурирование. Безусловно, для определенного набора задач быстрее скачать готовый пакет вроде денвера и не париться, но, с моей точки зрения, проще и эффективнее зайти на соответствующие сайты, скачать там нужные версии MySQL, PHP и Apache под win и спокойно все это дело установить. А работают самостоятельно установленные «куски» сервера все же заметно быстрее, чем готовый пакет (если речь конкретно про винду).

Еще один плюс — мне, например, категорически не нравится то, что делает разного рода денверы с моим компом без моего ведома.

P.S.
На виндузовой машине стоит Apache 2.2, PHP 5.4 и MySQL 5.6, все установлены и настроены по отдельности, тормозов не замечено.

Имел дело, выхода нет. Капчу просит только тогда, когда пользователь и сервер с которого пробуете использовать токен из разных стран/регионов. Проверено более чем на 50к аккаунтах.
Пример:
Пользователь давший права из украины + сервер получающий данные по токену тоже в украине = капчу не просит.
… из украины + сервер получающий данные по токену тоже в украине = капчу не просит.
… не из украины + сервер в украине = капчу просит даже при первом запросе.
… из россии + сервер в украине = капчу просит даже при первом запросе.
… из россии + сервер в россии = капчу не просит.
… из россии (Сибирь) + сервер в россии (МСК) = капчу просит.

Несколько недель пробовали как-то обойти но ничего не вышло, вариант только парсить капчу через какой-то онлайн сервис. Но это долго и проблемно при большом количестве пользователей.
Для себя выбрали решение когда пользователь сам парсит данные из вк и отправляет нам на сервер. При таком раскладе капчу не просит.

Если Вам нужно делать запросы когда пользователь оффлайн, можно перекинуть эту работу на пользователей которые онлайн :). Смотря какое у Вас приложение.

" Кто-то может забить диск, кто-то сожрать трафик, а кто-то повесить проц… " — панель это не решит. Квоты нужно вводить на все.

Очередь задач решается с помощью Gearman, тут вы совершенно правы.

Если требуется же запустить просто параллельный процесс — вы можете его форкнуть или создать новый.