Владимир Болиев

недобросовестного бесплатного

ну-ну

google: best practice + php java javascript итд.

github: opensource проекты )

Вы меня простите, но вряд ли вам дадут совет, как наиболее оптимизированно сломать себе руку - в большинстве своем люди либо не ломали себе рук, либо это было очень неприятно.
Надеюсь, метафора вам понятна.

Вам надо запускать по крону регулярно скрипт, который будет смотреть, есть-ли какая-нибудь задача и подошло-ли время её выполнения. И Если да, выполнять. Если в процессе выполнения произошла ошибка куда-нибудь сохраняется время(файл, база, key-value), когда надо будет повторить попытку.

Т.е. вам не надо из php создавать задания крон, вам надо создавать здания для своего периодически выполняющегося скрипта.

Сервер не в Австрилии?

$imagepath = "<FILE FILEPATH=\"http://blabla.ru/$element/"$image['name']"\" />"  ;

Каждый раз значение $imagepath перезаписывается. Как вариант можно сделать добавление в конец строки:

$imagepath .= "<FILE FILEPATH=\"http://blabla.ru/$element/"$image['name']"\" />"  ;

А смысл? В чем задача? Вы хотите уйти от jQuery ради того чтобы уйти от jQuery?

Честно, вы написали полнейший бред.
Деньги, Деньги, везде деньги. А как же расти духовно?

P.S.
PHP - есть шанс зарабатывание денег - пишите различные штучки -дрючки для CMS, так же, всякие сайты предпринимателей Вась из губерний X-ы. (Этот уровень содержит большое количество конкуренции со стороны школоты)
Python - Мощный инструмент. Есть мозги и прямые руки, то найдете работу как и в фрилансе так и в офис.

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

Просто говорите "я не могу ответить на этот вопрос по телефону, напишите на e-mail". Или как есть "простите, но ваши звонки отнимают у меня слишком много времени. пишите на e-mail". Будьте поувереннее в себе. Хамить не надо, а в остальном говорите как есть.
Ну, трубку всегда надо брать, а если отключаете - поставьте голосовой автоответчик "вы позвонили в нерабочее время, перезвоните во столько-то".

Начинать учить лучше с Java. На нём можно хорошо объяснить базовые вещи и принципы. А дальше студент сам выберет, что ему интереснее — веб, мобильные приложения и т.д.

1 млн. позиций само по себе не страшно, страшно количество возможных свойств, по которым должен быть доступен поиск. 2-3 свойства — одна ситуация, 20-30 — другая ситуация, 200-300 — третья.

Готовые цмс из коробки такой объем не потянут, однако разумным вариантом будет взять готовую цмс за основу как «обвес», то есть: платежи, статические страницы, статистика, категории, бакэнд, доставка, шаблонный движок и прочее.
А вот конкретно плагин/модуль каталога — написать полностью свой, с прямым доступом к базе (единственная завязка на ИД товара что бы была для остальной цмс-ки), при грамотном проектировании на 100 евровом хетзнеровском сервере даже самый сложный поиск будет укладываться секунд в 10 (если не плэин текст), а набор более или менее стандартных фильтров (стандартный поиск в магазинах) — секунды в 2-3, категории же и тэги просто летать будут.

Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

Поэтому в нашем случае напиливание своего показывает себя оправданной стратегией. Я вот не вижу, каким образом можно было бы получить подобные показатели на коробочных решениях, пусть даже и допиленных. Потому как пилить ядро коробочного продукта нет смыла, а без его запилки архитектуру не изменить. Ну и модифицировать свой продукт все же проще, чем супортить чужое + дописывать под него модули.

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