Persze a js pluginek pontosan azok, amiket magad is letöltöttél a ckeditor.com-ról. Viszont ezek drupal-ban nem töltődnek be maguktól sajna. Ezért nem elég csak a js fájlok bemásolása.

A php fájlok teszik elérhetővé a js plugineket és jelenítik meg a gombokat, amelyeket a ckeditor eszköztárába téve elérhetővé válik az adott funkció.

A drulpalhoz, már megírt kiegészítő például a beágyazott youtube, vimeo, stb. videók beillesztésére jó Video Embed Field modul.

Ha nem akarsz külön modult írni, hanem csak a plugint szeretnéd beilleszteni. Akkor a már meglévő pluginek php fájljait megvizsgálva és kicserélve logikus módon a neveket az új js plugin nevére. Elkészíthető a szükséges php fájl.

Tehát van egy funkciógombot hozzáadó plugined. Annak mappáját bemásolod a:
ckeditor/js/plugins
mappába.

Így bekerül a plugined mappája a plugins mappába.
A mappa a plugin nevét viseli. Ezen a néven létre kell hozni egy php fájlt a:
ckeditor/src/Plugin/CKEditorPlugin
mappában.

Ahhoz, hogy ebbe mit írj, javaslom például vizsgáld meg az itt lévő DrupalImage.php, DrupalLink.php fájlokat, amelyek alapján létrehozhatod a te pluginedhez szükséges php fájl tartalmát a megfelelő részeket felhasználva és átnevezve a te plugined nevével.

Ez persze nem elegáns megoldás, de ekkor nem kell külön modult írnod.

Szerintem nem valószínű, hogy a HTTPS-átirányítással függ össze, inkább a rendszernaplót nézném meg, ott nem ír-e ott bővebben róla?

„Ugyanez a honlap egy teszt helyre költöztetve [...]”

Az éles és a teszt tárhelyen megegyezik a PHP verzió, az engedélyezett PHP-bővítmények, a le- és feltöltési korlátok, stb? Ezt úgy tudod a legkönnyebben ellenőrizni, ha mindkét webhelyed állapotjelentés oldalán a PHP sorában megnyitod a „további információk” hivatkozást. Egy lila fejléces oldalt fogsz látni, ami rengeteg részletet felsorol az aktuális PHP-környezetről. Ha csak szemre átfutod őket és hosszra sem stimmelnek, akkor érdemes tüzetesen is összehasonlítani őket és megszüntetni a különbségeket. Csak így garantálható, hogy ugyanaz a Drupal-webhelyed 2 külön tárhelyen futtatva összehasonlítható legyen.

Ami viszont a HTTP-átirányítást illeti, gondolom ezt nem a saját .htaccess-edből másoltad, mert nincs benne a saját doménneved:

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\.example\.com*
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Kipróbáltam, nálam mixed content-re figyelmeztet:

A vegyesen kiszolgált tartalomról itt olvashatsz bővebben.)

A 7-es vonalat a backdrop cms viszi tovább egy kisebb közösséggel.

A 8-as vonal mögött egy jóval nagyobb közösség áll, ráadásul az unió is támogatja a hibakeresést. (Indult egy uniós program több nyílt forráskódú projekt támogatására, ahol pénzt fizetnek a feltárt komolyabb hibákért.)

Ha nem nagyon írtál saját modulokat, akkor nem lesz nagy változás egy saját rendszer összelegózásában. A sminkrendszerben használt twig nyelv is könnyen tanulható, ha saját magad készíted az oldalad sminkjét.

Arra érdemes figyelni, hogy csak olyan modulokat használj egy új rendszer összerakásánál, amik viszonylag frissek, illetve rendszeresen frissítik őket, hogy jó eséllyel a 9-es esetén is használhasd őket.

Mivel, még 7-et használsz nem hajt a tatár. Lassan elkészül a 8-ban az új média rendszer. Érdemes lesz ezzel megismerkedni. Sajnos, még nem kész. Talán a 8.8-ra meglesz. A legegyszerűbb composer-rel frissíteni, de tudom, hogy ennek kivitelezése nem mindenhol megoldható. Talán lesz erre megoldás a jövőben. Manuálisan persze továbbra is ugyanúgy frissíthető a rendszer mint korábban.

A rendszer erőforrásigénye magasabb, mint a 7-es rendszeré, de, ha egy modernebb szolgáltatónál vagy és van elegendő tárhelyed, akkor nem lehet gond. Érdemes lehet egy aldomain-en esetleg tesztelni.

Tanulni mindig érdemes -szerintem -és lehetőségekben, biztonságban előremutatóbb a 8, mint a wordpress. A 9-es a régi kódok eltávolítása után "könnyedebb" is lesz.