Тарас Варварич

Если всю жизнь хочешь заниматься такими задачами - то да, учи и PHP и Wordpress.
Если хочешь стать фронтом и разрабатывать на React, то лучше потрать время на обучение этому, а для задачи найди кого-другого или откажись.

А так для этой задачи, в твоем случае, только Wordpress. Даже не рыпаться с другими вариантами

В дополнение к другим ответам, постараюсь пояснить более просто.

Чтобы пробросит порт, его требуется прописать в 2х местах:
1. Filter rules - разрешаем форвард этого порта из внешки
2. Непосредственно проброс порта в NAT - dstnat на нужный ip

чтобы работал проброс портов у вас еще должен быть маскарадинг
chain=srcnat action=masquerade out-interface=ether1
где ether1 это порт к провайдеру
а также этот микротик должен быть шлюзом для пк в lan

В forwarding-е разрешить трафик на этот хост, или вообще во внутреннюю сеть, плюс все established соединения.

В консоли
# это уже сделано:
/ip firewall nat
add action=dst-nat chain=dstnat comment=for_tcp_3998 dst-address=_white_ip_ dst-port=3998 in-interface=ether1-gateway protocol=tcp to-addresses=192.168.0.x

# например, разрешим форвардинг просто в сторону сетки
# как один из вариантов
/ip firewall filter
add action=accept chain=forward connection-state=established
add action=accept chain=forward connection-state=related
add action=accept chain=forward in-interface=ether1-gateway out-interface=bridge-lan connection-state=new
add action=accept chain=forward in-interface=bridge-lan out-interface=ether1-gateway connection-state=new
### другие правила ###
add action=drop chain=forward log=yes log-prefix=DROP_FORWARD_

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

Если есть пробелы по используемым технологиям, то лучше сразу об этом заявить хотя бы личному руководству, а может и заказчику.

Если проект автономен (не требует поддержи 24/7), то документация ваш лучший друг, в противном случае времени на документацию не будет, это обычная практика в больших проектах.

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

1) Нужно понимать что делает этот проект, и выполняет ли задачи которые на него возложили. Нет ли еще не реализованных фич, незакрытых багов, про которые знает только пара людей. Потому что на бумаге фича есть, а по факту она, еще не на 100% сделана, а только заложили на будущие какие то модули, или баг который воспроизводится в определённой последовательности, но вероятность попасть на неё крайне мала. Так же нужно понимать кол-во пользователей у этого проекта, чем больше тем хуже для Вас т.к доступность проекта должна быть не менее 99.95%

2) Если бы я принимал проект с таким стэком технологий и всё сопровождение ложись бы на меня, я бы потребовал документацию по этому проекту, всё что только есть, чего нет должны будут дописать старые сотрудники. И дополнительно поддержка не менее 6 месяцев(возможно платная-тут нужно рассматривать варианты).

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

4)Обязательно заказать аудит от незаинтересованных лиц. Если бюджет позволяет, то от двух компаний. Так же проверить модули/код которые используются в проекте на "юридическую чистоту", что бы не было ограничений на продажу проекта, предоставление проектом коммерческих услуг(платные подписки и т.п) т.к есть модули которые бесплатны для собственного использования, но платные для коммерческого использования(тут подпадает и продажа проекта, и предоставление платных опций пользователям проекта и т.п). Ну и что бы в случае чего проблемы легли на разработчика либо компанию которая делала аудит.

5)Понимать свою компетенцию, насколько Вы готовы отвечать за то что Вам передают. Опять же проект разрабатывала целая команда, а сейчас его вешают целиком на Вас. Вы в состоянии поддерживать этот проект? А развивать, фиксисть баги? Если нет, то тогда первым делать искать людей которые это могут, и принимать всем в месте. Делить проект на части и делить эти части между компетентными сотрудниками которые в состоянии в случае чего аргументировать своё решение/мнение.

Ну для начала как то так, то что пришло в голову сразу, на самом деле там еще очень много всего. Всё зависит от конкретной ситуации.