Сейчас я на маке работаю, но когда начинал, то работал на винде, код во время разработки хостил на виртуалке под виртуалбоксом Работало всё достаточно быстро.
Вам нужна не авторизация, а аутентификация.
Самая простая аутентификация - это http-auth. Примеров в инете огромное кол-во.
Или всё таки авторизация нужна по логину-паролю ?
Правда не понимаю, что Вы хотите писать на php абсолютно в нём не шаря.
я Вам объясню еще почему я считаю затею "писать свой движок/cms/..." очень нелепой в моих глазах.
Проблема php-сообщества в том, что пхп очень многое позволяет делать криво-косо, да и вообще не правильно. На данный момент существует просто нереально огромное кол-во всевозможных готовых решений под любые типичные задачи(и большинство из них ужасно написаны и спроектированы, но это др. история). Но всё ровно, каждый, кто узнал, как соединиться с БД и несколько циклов, решает, что пхп-сообществу не хватает cms. Хотя на самом деле пхп-сообществу не хватает просто программистов, которые знают основные паттерны программирования и используют их с умом.
Дк вот, я бы Вам настоятельно посоветовал сперва изучить ООП, MVC и вытекающие из него выдумки, основные шаблоны проектирования(синглтон, фабрики, ...), глянуть GRASP, SOLID, KISS. Это только для начала. Затем глянуть, как написаны некоторые качественные фреймворки, например симфони, yii, ларавель.
Поработать немного в какой-нибудь веб-студии за опыт и еду, с пол годика, а потом уже поймете нужна ли миру очередная cms на php и что она может хорошего предложить.
Если Вы реализуете cms с использование ContentRepository для хранения контента, а также удобный инлайновый визивиг, то думаю, что Ваша cms будем многим полезна.
оооой, дк так всё сложно чтоли ...
Ладно, в качестве начального вклада в Ваше начинание, подскажу пример хорошей архитектуры, который позволит Вам хотя бы не сделать сайт с кучей бэкдоров и sql-инъекций. Хотя на счет последнего сомневаюсь.
Есть такое понятие, как front controller. Это единая точка входа в Вашу программу.
Архитектура должна выглядеть так:
Веб-сервер(nginx/apache) принимают запрос, если запрашиваемый файл существует в вебруте, то отдает его клиенту, если нет, то выполняет скрипт фронт котролера(например index.php), передавая ему в get-параметр(например параметр route) uri запроса.
Итого, когда мы запрашиваем на сервере папку "/ru" и у нас данной папки не существует, то вызывается скрипт index.php?route=/ru.
В index.php Вы должны скормить url-запроса классу Router, который его обработает и установит текущий язык в сессию, а также роутер должен определить, как дальше обрабатывать этот запрос. Хорошо, если роутер сфомирует объект Request, который будет хранить максимум информации о запросе.
В идеале Ваш index.php должен после роутера знать, какой именно метод должен обработать данный запрос, вызвать этот метод и получить объект класса Response, содержащий максимум информации об ответе(содержимое, content-type, заголовки кеша и многое другое).
Далее нужно этот объект Response преобразовать уже в привычный нам вывод, добавив нужные заголовки и куки(хотя куки это тоже заголовок).
Может всё таки сперва попробуете хотя бы в каком-нибудь простеньком фреймворке разобраться ?
Я бы конечно посоветовал тебе проверить, включен ли опкеш и еще что-то подобное. Это сильно влияет на производительность.
Но поскольку я не желаю людям ничего плохого, то всё же посоветую поднять сервер с линуксом для локальной разработки и разрабатывать через него. А винду начинать воспринимать, как просто какую-то "хрень" с привычным интерфейсом, кучей багов, лагов, бэкдоров и прочего. Вообщем понимать, что веб-разработка и винда находятся в несколько иных плоскостях.
И нужно начинать понимать настройку веб-стека чуть поглубже, хотя бы уметь настраивать всё это дело на линуксе.
Сказать по правде, то заниматься веб-разработкой из-под винды - это мазохизм. Когда начинал и сидел тоже на винде, у меня был в виртуалбоксе сервер с расшаренной папкой, сейчас докер позволяет сделать это примерно так же, но чуть красивее и перспективнее.
Если отбросить разные доп. технологии, то просто ставьте себе виртуалбокс, на ней поднимайте машину, прокидывайте сеть(про сеть мне помогает эта статья), затем расшариваете папку с проектами, в файле hosts прописываете домены с указанием на ip-адрес вашей виртуальной машины с сервером.
На сколько изменится скорость, сказать сложно, но под виндой с роду всё всегда лагает :)
Это было во-первых. Теперь во-вторых: Вы уверены, что рендеринг долгий из-за веб-сервера ?
Подобные вопросы всё чаще и чаще стали поступать мне от знакомых, кто начал веб-программирование изучать.
Планирую в ближайшее время снять пару небольших уроков и осветить наконец эту тему для начинающих, потому что это очень важный базис в веб-программировании. Так же в будущем это понимание очень помогает оптимизировать инфраструктуру сайта, быстрее находить ошибки и повышать отказоустойчивость.
Хранить всё придется в бд, ведь взаимодействуют 2 и более клиента, а их синхронизировать придется через какой-то сервер, иначе будет много уязвимостей и багов. Я не знаю всей специфики игры, но суть такая, что после отправки аяксом действия игрока нужно в ответ с сервера получить необходимые данные и уже на клиенте анимировать, как нужно, скорее всего через библиотечку, которой скармливаешь какие-то данные, она анимирует, как нужно.
OnYourLips: Сплю действительно мало, сейчас стараюсь больше. Давайте тестовые задания и вакансию "со средней з/п 3500$" и уже более предметнее будем общаться о моих навыках.
NikitaTkachev: Фул-стек сильный разработчик, 2 джуниора, 1 верстальщик-дизайнер, 1 верстальщик со способностью потестить функционал. Вместо последнего можно не верстальщика, а кодера джуниора с функцией ручного тестирования. Я стандартно такой комплект заказываю под крупные проекты. Но конечно есть специфика, может у вас очень много графики в проекте, или нужны программы для устройств каких-то, может еще что-то. Я привел пример для стандартного крупного сайта/веб-приложения. OnYourLips: Я, например, хорошо знаю и бекенд, и фронтенд, фотошопом и axure пользоваться умею, разбираюсь в сео и арбитраже. Зачем я тратил тысячи часов на всё это ? Да просто интересно что-то новенькое было, да еще и платили за это.
Всё так!
На будущее, если хотите подобного эффекта, то можете спросить - "какой фреймворк более крутой: yii2 или симфони2", так же можете еще спросить что-то типа - "Что лучше взять обычный эйсер или мак" :)
Анатолий K: Уточнений про МПК(раз вам не нравится оригинальное "иностранное" словечко) не было, но из исходных данных нам известно только про наличие модели, контролера и формы, которая наверняка является представлением, а так же упомянут некий "вообще отдельный класс". Походу это МПК с DI или сервис локатором :)
Ну смотрите. В первом случае мы можем более "тонко" реагировать на процесс. Например, у нас есть совершенно разные варианты использования модели: где-то она лишь поле в составе некой сложной формы, где-то целая форма, где-то еще что-то. В первом случае контролер лишь спрашивает модель - "Пойдут такие данные?". Причем, даже в случае утвердительного ответа модели, дальнейшие действия могут быть самые разные, не обязательно нам нужно будет сразу сохранять, могут быть другие данные, которые еще тоже следует проверить, в зависимости от запроса. В этом случае всё это мы должны учесть в рамках модели, что будет слишком сложно и неудобно.
В контролере всё проще - мы узнали у модели примет ли она такие данные, она сказала, что да, мы затем узнали у следующей модели что-то, затем сопоставили это как-то с информацией о запросе/клиенте(эта информация в компетенции контролера), и если надо, то говорим моделям сохранить, или что-то сохраняем, на что-то определенным образом отвечаем клиенту.
Для примера давайте приведем экшн, который принимает некую форму. Если к нему обращаемся аяксом, то он валидирует и отдает json-ответ, если обычным запросом, то валидирует, сохраняет и отдает хтмл-ответ. В случае первого примера делается просто - мы валидируем через модель, затем проверяем запрос и либо сразу отвечаем, либо говорим модели сохранить и затем отвечаем с хтмл-рендером. А если в модели ? То мы начинаем перекладывать на модель немного лишнее, хотя опять таки, это можно сделать в рамках парадигмы, но реализация, согласитесь, не самая красивая получится. Таких примеров в построении бизнес-приложений сплошь и рядом.
