Сергей Еремин

Давайте я погуглю за вас:
https://webref.ru/recipe/2687
Правда это не по числу символов, а в размер блока... но тем не менее... Для обрезки по числу символов, по хорошему, для корректной орфограии надо городить скрипт расстановки переносов &shi; и вычислять на каком месте сделать "обрезание" и установку многоточия...

Судя по принтскрину, в таблице для разных столбцов используются разные кодировки. Проблема может быть в этом. Не знаю, поможет это в твоем случае, но стоит попробовать:

Сделай дамп базы. Открой его в текстовом редакторе. Глазками посмотри что у тебя в тех полях которые идут умляутами и прочими квадратиками и вопросиками. Попробуй разобраться где какая кодировка образовалась и совпадает ли она с тем, что указано при создании таблиц и полей (вполне подходящий инструмент FAR Manager, в нем можно менять кодировки при просмотре и редактировании. Напиши скрипт, который унифицирует кодировки при создании таблиц и полей, а так же сделает перекодировки значений полей при их заполнении данными. Если данных в табличках не много -- все можно даже руками сделать в текстовом редакторе.

После залей этот исправленный дамп на сервер.

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

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

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

Если нужно что-то не связанное с персональными данными, то лучше искать альтернативные источники. Многое открыто. Например, Иван правильный ресурс посоветовал. Многое оттуда можно вытянуть.

По-моему логичнее:

/uploads/images/id_post/tort_minutka.thumb.jpg
/uploads/images/id_post/tort_minutka.main.jpg
/uploads/images/id_post/tort_minutka.original.jpg

Зачем плодить папки? А так глазом еще и намного проще обнаружить недостачу картинок...

Поменяйте отображение калькулятора с iframe на $('#id').load(...). Так вы получите доступ к Dom калькулятора и сможете в нем менять все что угодно.

Зависит от того какие и сколько запросов на чтение и запись будете строить.

Вопрос примерно так звучит:

В какую религию перейти из Язычества? В Буддизм или Конфуцианство?

Я бы в Буддизм пошел... Тьфу... То есть на Python. У него паства побольше и распространен он поболее. Последователи учения -- не злобливые, и помогут. А Ruby как конфуцианство как-то слишком узковатое... Хотя, может просто мало его последователей встречал.

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

Через jQuery. Получить куку:
var cook = $.cookie("citi");
Установить куку (с временем жизни 10 дней):
$.cookie("citi", "Moscow", { expires : 10 });
Можно куки и через мета в HTML-е установить

<META HTTP-EQUIV="SET-COOKIE" CONTENT="name=имя;expires=дата; domain=имя домена;path=путь;secure">

И вообще погугли. Примеров масса.

А как-нибудь иначе, например прям из брокерского терминала не проще брать котировки? Многие дают с радостью, только попроси.

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

если записей и тегов много, то SQL будет тормозить. Запросы тяжелые, кешируются слабо (особенно если строить облака не по календарным месяцам, а по минус-N-дней-от-текущей-даты). Собирать и облака тегов ежемесячно (еженедельно, ежедневно… как там у вас в задумке), формировать из них статичные структуры (HTML, например) и отдавать по запросу.