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

Посмотрите сборки Open Y и Open Social, в них много социальщины реализовано - узнаете как что можно устроить.

Не нравится гирлянда из 90х? Получи еще и смайлы из 00х!
Таащииии!!!
Ннада бы аську раскопать, судя по тенденциям...

Я, если что, об этом:

Приложенные требования, например, у Вас отлично получилось "обезопасить" от лишних глаз

В том-то и беда - напридумали своих логик, а другие спецы как не возьмутся - все им "позор".
Не думаю что это показатель разработчика, только его степени вовлечения в Drupal.

ЗЫ - а подходы, как-раз, на ВПшные похожи. Там и шорткоды, и func.php присутствуют.

Да, тут по истории ясно уже будет. На будущее...

Вот, ясности хотел.

"Переупаковал для версии 7.67" - звучит совершенно не понятно. Ни целей, ни результата этой "перепаковки" - ни о чем этом не сказано. Целевая система - одного разлива. Странный, непонятный архив на какой-то файлопомойке. Все это вызывает недоумение.

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

Так, а что из изначального модуля не работает? Для чего нужна была эта "перепаковка"?

А в чем заключаются эти изменения? И почему сделано не хук_апдейтом, а отдельной версией (выходит, не совместимой с предыдущими сборками)?

А в чем смысл "переупаковки"?
Платформа, вроде, одна. Или есть отличия между минорными версиями в этом функционале?

Все верно выше написали. Поле должно быть в материале, если оно относится к материалу.
Для условного отображения поля загрузки попробуйте Conditional Fields.

Работает в одинаковой степени для всех типо-размеров.

Правки есть и на мелких сайтиках. И боль от таких правок - так же неприятна.

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

Но, да, я понимаю о чем ты. Есть такое.

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

Оооу... По моему личному мнению, а оно наверняка не сойдется с кучей других, возможность задавать верстку с админки - одна из худших фич Друпала.

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

Кроме того, если верстальщик сидит и только верстает - это не просто его "зона комфорта" (что в само по себе ничем не плохо), а прежде всего, его основная сфера деятельности. Никто же не свистит вслед пилоту, который сидит в своей зоне комфорта и то и делает, что самолеты сажает, не развиваясь совсем. 

Если коротко - верстка "по Друпалу" это колхоз.

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

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

Вот точно не "самый правильный". А скорее, даже, наоборот.

https://www.drupal.org/docs/8/theming/twig

Все верно. Плюс, нужно учитывать еще один аспект - необходимость сортировки.

По числу:

• 1
• 25
• 125

По строке:

• 1
• 125
• 25

А еще, со строкой возможны такие значения как "000025".

Нет даже аналогии, не то что корреляции. И прямо противоречит нити суждений.

С одной стороны написано о том что "делай маленькие и хорошо работающие штуки", с другой - о том, что нужно иметь одну штуку "на все случаи жизни".

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

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

Вполне обоснован. Функционал не дублируется, он просто схож в некоторых аспектах (в том что может являться "страницей", если исходить из примера).

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

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

Юникс-вей, в данном случае, выполняет апи сущностей, который должен делать хорошо свою работу - быть способным обеспечить достаточную расширяемость и поддерживаемость.

Опять таки, я не знаю истинных причин, только предполагаю, с какой то долей вероятности быть правым.

Думаю, правильно ставить вопрос не "почему не ноды", а "почему ноды", т.к. в проектировании не очень приветствуются практики многоцелевых сущностей.

Зачем использовать для товаров что-то, что товаром изначально не являлось?