Switch74

http://htmlbook.ru/css/value/media

всем } добавляете перенос строки, если нужно, можете так же добавить и ; и {

$('#form').submit(function(){ $.post('http://site.ru/',{'name':$(this).find('#name').val(),'number':$(this).find('#phone-namber').val(),'email':$(this).find('#email').val(),'message':$(this).find('#massage').val()},function(data){ alert(data); }); return false; });

В вашем случае что-то вроде $('form').submit(function(){ $.post('http://site.ru/',{'name':$(this).find('@name').val(),'number':$(this).find('@phone-namber').val(),'email':$(this).find('@email').val(),'message':$(this).find('@massage').val()},function(data){ alert(data); }); return false;});но лучше использовать id для получения данных из полей и форме присвоить какой-нибудь идентификатор, а то у вас все формы будут так пытаться работать

посмотрите в сторону $.post отправите свои данные, получите и обработаете ответ

если sortFunction(a, b) - это сортировка по возрастанию, то sortFunction(b, a) - убыванию

а после вы должны начать проходить массив сначала, сравнить 9 и 10, ничего не изменить и идти дальше, сравненивая 10 и 4, получим массив [9, 4, 10, 5], после чего вы должны проводить сравнения сначала. А вообще алгоритмов сортировки очень много.

Сразу про все не помню. Выше указанная статья сравнивает по сути block и inline могу посоветовать посмотреть http://habrahabr.ru/post/161581/- подробно про inline и float + http://stackoverflow.com/questions/11805352/floatleft-vs-displayinline-vs-displayinline-block-vs-displaytable-cell ну и как это все в купе работать должно http://habrahabr.ru/post/9476/

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

нужно понять, что block - это блок, который пытается занять все пространство по ширине и не пускает другие элементы слева и справа от себя inline-block работает как inline, т.е. в одну строку, но отличается поведением при указании каких либо габаритных размеров так же на всех них влияют такие свойства как float, position, margin, clear и в определенных комбинациях может быть разный результат

Посмотрите внимательно роли пользователей, подозреваю, что у первого Супер Администратор (Super Administrator) а у второго Администратор (Administrator)

я у вас вижу что первый смотрит "Категории товаров", а второй "Страницы"

любой прайс лист в xls - это табличка из которой вам нужный как минимум наименование и цена (две колонки) обычно в таких ситуациях у меня отрабатывало так: загрузив xls отображаем его содержимое (структуру), галочками отмечаем какие строчки и колонки нам нужны, после подтверждаем выбор и нужные данные записываются и так делаем со всеми прайсами поставщиков приводя их разрозненные данные к нашему единому и красивому формату так же можно создать id для каждой позиции, чтобы в будущем они загружались автоматически, но для этого требуется условие того, что в прайсах будет колонка с каким-то уникальным параметром который не будет изменяться у поставщика если не хочется сильно париться каждый отдельный прайс - это отдельная страничка со своей структурой

я обычно делал php парсер на основе simple-excel-php (сейчас подобных скриптов очень много), а там уже формируйте страницы как вам удобно или заводите все в БД...

Мне понравился проект https://www.ispyconnect.com/, возможно вам подойдет

Смущает только фраза: "Только в Hostinger и на ограниченный срок!" как бы не забрали потом

Могу предложить WinSCP синхронизирует папки по ftp - маленький, бесплатный и очень не плохой продукт на мой взгляд

1. Например при забивке товаров сделали ошибку и написали "Малаток" (думаю стоит исправить и в заказах подобную оплошность) Или например добавляется расширенные характеристики для данного товара, по которым потом можно было бы отфильтровать позиции (как это делается например на яндекс маркете). Раньше было указано например ручка деревянная, а теперь еще и ее длинна, было бы не плохо, чтобы данные о товаре из заказа совпадали с данными в каталоге. 2. у вас 100500 заказов с этим товаром, сейчас он занимает в базе 1 строку, если вы его в каждый заказ пропишете - это в 100500 раз больше места занимает Если вы хотите его удалить из каталога, скройте его там, но в базе он остается

На мой взгляд оно так и должно быть (в смысле работать через ссылку из заказа на товар). Рассмотрите ситуации на вашем интернет магазине, предположим есть у вас n-количество товаров, скажем по k-штук зарегистрировалось x-клиентов и купили у вас часть товара (регистрация естесно не обязательна) 1. теперь вдруг по какой-то причине вы изменили что-то в товаре - в случае если информация о заказанном товаре будет храниться в заказе, вам придется менять его и во всех уже сделанных заказах + если эта информация большая это все будет очень много места занимать. - если хранится только ссылка на товар, то достаточно отредактировать в одном месте. 2. хотите вы удалить скажем товар из базы и возникает сразу вопрос, а зачем вам это нужно? Много места занимает? Мне кажется все копии этого товара в каждом заказе будут весить больше. Если вы конечно предусматриваете для клиентов историю их заказов на сайте. Если же у вас заказы будут удаляться или переноситься куда-то в архив по истечении какого-то времени после его исполнения, то и товар можно будет удалить вместе с последним ссылающимся на него заказом. ... можно продолжить этот список и дальше

Можно сделать ключ переменную, которая будет проверяться и устанавливаться в разрешающее значение при клике на overlay, а при клике на frame устанавливаться в блокирующее значение

в таком случае я бы сделал все ж таки таблицу с вашими месяцами, а из текущей делал ссылку на нее: там можно хранить нужный формат отображения и латиницы и кириллицы одним простым запросом будут легко создаваться табы и одним не сложным запросом делался бы контент для них month id|name|class events id|name|date|website|details|approved|month_id база будет чуть больше, но работа с ней будет быстрее

по сути там есть уже такое поле. по созданию еще одной таблицы: во многих случаях бывает смысл так сделать и не вижу смысла вычленять дубли и т.п. что вы описали выше. 1 запрос для создания табов 2 запрос для создания контента для них где связанный запрос из двух таблиц по id

первый вариант на мой взгляд вполне норм

1. <?php elseif($currentlang=="en-US"): ?>а не <?php elseifif($currentlang=="en-US"): ?>2. удобнее было бы держать данные строки в базе данных или в файлах, которые исходя из выбранного языка и будут подгружаться

А что именно вам не нравится в вашем примере, я понять не могу?