Ресърч - Колко пари бихте вземи за изработка на фирмен wordpress сайт

ReminD

Well-Known Member
От скоро правя един сайт на колега от форума за Обяви - Laravel stack - от 0. Админ панела е MIT html template, фронт енда също. В началото изглежда просто - няколко контролера, модела, админ контролери с друг неймспейс, 5-6 вюта ( идентични) и това е. Да ама на пръв поглед изглежда много просто, но като се замислиш, сайта е завършен на 90%, но -> просто просто, колко да е просто, едни обяви нали...

Моделите по мои сметки бяха 5-7. Да ама, нали на потребителя трябва да е удобно. Да има състояния, тип доставки, ТИП на обявата , dashboard panel, статус активни / неактивни, редакции, качвания на изображения, оферти , лични съобщения, области, любими обяви, и разни други неща. Та, от 5-7 контролера, накрая излязоха ей толкова. Също толкова има и в \Admin




И моделите



Действаш по HTML темплейта, който е предоставен, изглежда окей, казваш си не е много работа, ще режеш разни елементи, ще нагласяш - те елементите си ги има в демото на темплейта, няма да има ядове. Да ама не - вмомента в който почнеш да режеш сайта на components/ views и нещата винаги се омазват някъде -> дали някой div.row, дали някой контейнер, дали нещо друго стои на грешно място -> изключително не си прецених времето, за колко време ще се оправя с view-тата.

Та пак бях преценил, че 5-8 вюта, които са идентични ще бъдат достатъчни. Е, нещата изглеждат така:

И тук не броим админ вютата, които са малко повече, защото всички имат редакция.
Доста са идентични някои, защото рендерират обяви, обаче пък трябва да има SEO, трябва да минеш по тези страници и да рендерираш някакви данни по мета в хедъра.

Преживявам го някак, бая писане падна да се нагласят нещата в що годе приличен вид. В един момент обаче се замисляш, че ти трябват Middleware-и и то не само isAdminMiddleware и isAuth middleware. По security reasons -> Дали потребителя може да редактира дадена обява, дали може да чете съобщението, дали може да праща оферта, дали офертата е приключила и т.н. и т.н... Сложете още 5-7 middleware, които ги закачаш по рутовете. Че иначе ще е резил някой да намери такъв пропуск в сигурността - сменяш id-то на съобщението и на юзера и четеш друго съобщение.. Not Gonna Happen buddy. Та към писането добавяме и няколко middleware от тоя род


Рутинга и web.php файла, отговарящ за адресите. Админ рутинга е лесен, понеже се възползваш от готиния ларавел, и можеш да си действаш с Grouped Routes by middleware и да ползваш ресурс контролери.



Хубаво де, ама при Front end routes не можеш да ползваш ресурс контролери на повечето места, защото адресите са специфични, има custom неща при имената, пък и потребителя не му трябва да редактира повечето неща във фронт енда.

Та рутинга от 20-тина преценени за фронт енда, стана около 40 , с различните GET/POST/PUT/ и т.н..


Прибавяме разни валидации, custom message components, дали нещо е успешно, дали не е, качване на файлове, оправяне на директории, триене на файлове след като нещо се изтрие и т.н... Добавете още време. Като се добави и няколко бъга, които ти отнемат време да ги откриеш, или неща, които се чудиш как ще стане -> за справка личните съобщения бяха най-голямата мъка. Лесна работа нали, модел Message, и модел Conversation, message пази съобщението и conversation_id, пък Conversation пази sender_id, receiver_id -> хубаво, написах го, само че какво се получава -> потребителя натиска на съобщение, изпраща го, онзи го получава, дотук всичко работи, само че вмомента в който натисне втори път на съобщение до дадения потребител -> създава нов Conversation.
Колко му е една проверка нали, е ето колко:


И това е що годе the Laravel Eloquent Way, без raw DB:Query

Друго, което отне бая време -> разни проверки по views -> дали потребителя е логнат, ако е логнат еди какво си, ако не е друго, дали може да изпраща оферта до себе си, дали може да рипортва собствена обява и т.н.. И понеже нещата в един момент стават големи, колкото и да се мъчиш да ги опроставяш и да разделяш по компоненти -> грешки винаги има, трябва да обикаляш по файловете и да преглеждаш за разни малко проблемчета -> пък дали нещо има релация, дали няма, дали потребителя има добавени обяви в любими, ако няма да не гърми сайта, и т.н.. и т.н...


Та на пръв поглед едно лесно проектче, може да отнеме бая време, бях преценил нещата за седмица, две, пък мина около месец. Lesson learned. Спазваш конвенции, гледаш имената да са на английски, променливите евентуално ще ги чете друг човек, пак да са адекватни, да има коментари тук там ако кода не е self explaining и т.н..
 
Последно редактирано:

John Galt

Well-Known Member
@ReminD
Готов ли си за следващото Laravel начинание, че търся кой да ми надгради един онлайн магазин правен на Laravel? :D
 

Noke

Well-Known Member
С Django това горе щеше да ти отнеме няколко пъти по-малко код. По-малко мислене и много по-малко писане и тестване. Да не говорим че някои от нещата като личните бележки м/у юзърите ги има готови.

И по-малко главоболие, причинено от гледане на рошавия PHP синтаксис.

Минусът е че губиш повечето cPanel-only клиенти, което може и да не е чак такъв минус, което пък е друга тема...
 

SoloContraTutti

Well-Known Member
Въпреки че не се придържам толкова по темата, няма как да не благодаря на @ReminD, както за подробното описание /писмено/, така и за визуалната презентация + споделения опит. Едно от малкото наистина полезни неща във форума последните седмици (че и месеци). :)
 

Горе