Александр

Бекап незабудь сделать!

-- Cleaning wp_commentmeta
SELECT *
  FROM wp_commentmeta
 WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);

DELETE FROM wp_commentmeta
 WHERE comment_id NOT IN (SELECT comment_id FROM wp_comments);

SELECT *
  FROM wp_commentmeta
 WHERE meta_key LIKE '%akismet%';

DELETE FROM wp_commentmeta
 WHERE meta_key LIKE '%akismet%';

-- Cleaning wp_postmeta table
SELECT *
  FROM wp_postmeta pm 
       LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
 WHERE wp.ID IS NULL;

DELETE pm
  FROM wp_postmeta pm 
       LEFT JOIN wp_posts wp ON wp.ID = pm.post_id
 WHERE wp.ID IS NULL;

Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.

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

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

Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

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

Вы можете начать погружаться в ООП с того, что разобраться "почему глобальные переменные это плохо", почему "состояние порождает сложность" и что такое эта "сложность" (многие почему-то думают что сложность выражается в написании кода а не в его чтении или поддержке), почему "изоляция" (и как следствие инкапсуляция) - это хорошо. Как это все соотносится с декомпозицией. Что такое "ответственность", что такое зависимости, связанности

Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.

Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

Сразу хочу отметить что это крайности. Упражнения же. Они должны ограничивать вас что бы заставлять думать и задавать правильные вопросы.

Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.

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

Тут нет лучшего решения или лучших практик. И быть не может. E-commerce отталкивается от потребностей бизнеса и аудитории и бывает настолько разный что обычные интернет-магазины становятся просто каплей а море, а решений на рынке на любой вкус и цвет

Определяетесь с функционалом которой вы чаща всего используете. Но которого нет из коробки. Или упощение вызова функций из коробки.
Затем пишете его.
На самом деле очень ускоряет работу, в процессе при необходимости дорабатываете модули.

У меня структура сдвоена, на большие проекты, требующие много функционала кастомного и библиотек ставлю целиком.

Для не крупных проектов в папку темы вычленяю mast-have


Если учтено все, то все очень просто обычно дальше.

например так выглядит настройка хлебных крошек под дизайн темы

function wpp_br_breadcrumbs_classes( $classes ) {
	$classes = [
		'wrap_class' => 'breadcrumb breadcrumb--overflow responsive-gutter section-padding-small',
		'item_class' => 'wpp_br_item',
		'link_class' => 'breadcrumb-item'
	];

	return $classes;
}

add_filter( 'wpp_fr_breadcrumbs_classes', 'wpp_br_breadcrumbs_classes' );

Вот так регистрация новой таксономии

function wpp_theme_register_taxonomy( $args ) {
		
		$args[ 'sliders' ] = [
			'hierarchical' => true,
			'post_types'   => [ 'slider' ],
			'single'       => 'Слайдер',
			'plural'       => 'Слайдеры',
			'genitive'     => 'Слайдер',
			'cir'          => true
		];


		return $args;
	}

ну и т.д.

Если есть доступ к ftp, то просто выполните код

$user = new CUser;
$fields = Array(
  "PASSWORD"          => "123456",
  "CONFIRM_PASSWORD"  => "123456",
  );
$user->Update($ID, $fields);
$strError .= $user->LAST_ERROR;

https://github.com/florinpop17/app-ideas

Сталкивался с таким дизайном и дизайнерами, которые такое рисуют - больше с ними не работаем

1. При входе на страницу сохранить исходное состояние всех инпутов
let initialState = $('#myForm').serializeArray();
2. При возвращении к началу - восстановить исходное состояние

let form = $('#myForm');
if (form.attr('name') in initialStates) {
    initialStates[form.attr('name')].forEach(item => {
        form.find('[name="' + item.name + '"]').val(item.value);
    });
}

работайте только по 100% предоплате.
Тогда уже заказчик будет вас подгонять, а не морозится...
Впрочем, достаточно и 50%, обычно
по пунктам
"- Заказчик очень долго проверяет (вплоть до неск. месяцев)
вписываем в договор что-то типа "заказчик должен подписать акт выполненых работ или выставить притензии не познее чем через 3(три) дня после выставления акта выполненых работ"

"- Заказчик не предоставляет контент очень длительное время. (так же вплоть до полугода. И это не про большие СЕО текста, а про какие нибудь контактные данные, пару фоток и т.д)"
та же фигня. все сроки вписываются в договор, оговариваются форс-мажоры, при условии соглашения сторон

"- Заказчик просит переделать одну и туже мелочь по 50 раз (какую нибудь ерунду, вроде поменять 2 слова, но в течении очень долгого времени и на одной и той же странице. Это как пример)"
сложный вопрос и самый труднодоказуемый. Единственный вариант - все под протокол разногласий, или как оно там правильно юридически.

"- Заказчик не объяснил что хотел, сказал делайте на своё усмотрение и сначала всем был доволен. Потом подключил еще проверяющего и тут же всё не нравится: переделывайте всё заново и бесплатно. (Естественно, на проверку скидывается каждый этап работ и только после одобрение идём дальше.)"
На этом этапе, обычно, заказчик посылается в арбитраж. После чего, как правило, несколько трезвеет и с ним уже можно договариваться. Как-то в таком случае, получили оплату за 3 сайта, вместо одного.

"- Заказчик просит добавить довольно серьёзный функционал, который не был обговорен и соответственно не был просчитан в цене. Доплачивать заказчик не желает."
тут все просто "Читайте согласованное с вами ТЗ".

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

PS. не работайте с мудаками.
PPS. Чуть не забыл. Все показывайте заказчику на своем хостинге. подписал акт выполненных работ - можно переносить к нему. Впрочем, я дожидался подтверждения из банка о поступлении средств.