## TL;DR

Hier ist das git Repo in dem ihr den Kompletten Code Findet der in diesem Blog Verwendet wird.
[beardcoder/webpack_typo3](https://github.com/beardcoder/webpack_typo3)

## Vorbereitung

Als aller erstes Brachen wir eine lauffähige TYPO3 Instanz. Viele von euch haben vielleicht schon ein Vorhanden Projekt das sie Umbauen möchten. Auch dies kann einfach realisiert werden.

Ich verwende für diesen Blog Artikel Composer und Docker um schnell eine kleine TYPO3 Instanz zu erstellen

### TYPO3 installieren

Mit diesem Befehl installieren wir uns TYPO3
`composer create-project typo3/cms-base-distribution webpack_typo3`

Nach der Ausführung dieses Befehls finden wir im Ordner `webpack_typo3` unsere installation.

Jetzt brauchen wir nur noch eine Datenbank die wir uns entweder Local aufsetzen können oder mittels Docker starten.
Ich verwende hier an dieser Stelle Docker um schnell ein Ergebnis zu erhalten. Wer mehr wissen möchte über Docker und TYPO3 wird bei [https://typo3worx.eu/](https://typo3worx.eu/) fündig.

Mit diesem Befehl starten wir unsere Datenbank

```bash
docker run --name typo3_db \
    -e MYSQL_DATABASE=dev -e MYSQL_USER=dev -e MYSQL_PASSWORD=dev -e MYSQL_RANDOM_ROOT_PASSWORD=1 \
    -p 13306:3306 \
    -d mariadb --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
```

### TYPO3 Starten

mit dem in PHP Integrierten Webserver Starten wir unsere Instanz um eine Extension zu entwickeln

Der Befehl `php -S localhost:8080` wird im Verzeichnis `public` von TYPO3 Ausgeführt.

Danach Steht unsere TYPO3 Instanz unter http://localhost:8080 zur Verfügung. Weiter gehe ich hier nicht auf die Installation von TYPO3 ein. Wenn ihr dazu Mehr erfahren Wollt schreibt mich einfach an.

### Erstellen einer Design und Frontend Extension

Um Unser Webpack Setup zu erstellen und mit TYPO3 zu verbinden brauchen wir in erster Linie eine kleine Extension um das nötige TypoScript zu laden.

Ich nenne sie der Einfachheit halber `design`.
Dazu erstellen wir einen Ordner im Root unseres Projektes names `packages`.
in diesem erstellen wir eine Ordner mit dem Namen der Extension. In unserem fall `design`.

Das Setup der Extension basiert auf dem Setup von Helmut Hummel <https://github.com/helhum/ext_scaffold>. Ich werde die hier erstellte Extension Euch am ende des Beitrags verlinken.

### Setup der Seite.

Diesen Bereich halte ich sehr kurz. Es geht lediglich darum das wir danach eine Möglichkeit haben unsere Daten einzubinden. Darum an dieser Stelle nur ein Minimal Setup im TypoScript

```js
page = PAGE
page {
    typeNum = 0

    100 = CONTENT
    100 {
        table = tt_content
        select {
            orderBy = sorting
            where = {#colPos}=0
        }
    }
}
```

Danach sollten wir die Möglichkeit haben unser Frontend aufzurufen und auch schon mal Content anzulegen.

## Setup Webpack

Um jetzt unser Frontend zu bauen brauchen wir natürlich erst einmal einen Platz wo wir anfangen.
Hierfür erstellen wir in unserer Extension einen Order. `Resources/Private/Frontend`

Wir verwenden hierfür den Private Ordner da dieser normalerweise geschützt ist und wir unser Setup natürlich nicht im Browser aufrufen müssen.

### Initialisieren von Yarn

Über den Befehl `yarn init` in unserem neuen Ordner erstellen wir eine `package.json` die alle Abhängigkeiten enthält die wir später für unser Frontend und zum Bauen des Frontends benötigen.

Die `package.json` sollte dann in etwa so aussehen.

##### package.json

```json
{
  "name": "frontend",
  "version": "1.0.0",
  "private": true
}
```

### Installieren von Webpack und Webpack CLI

Mit dem Befehl `yarn add -D webpack webpack-cli cross-env` fügen wir unseren Abhängigkeiten Webpack hinzu.
Ich teile meine Abhängigkeiten immer auf in Dev `-D` für den Build Prozess und Normal für Abhängigkeiten die ich im Frontend benötige.

Nach der Installation fügen wir einen `scripts` Bereich in der `package.json` ein um webpack staten zu können.

Danach sollte die `package.json` in etwa so aussehen

##### package.json

```json
{
  "name": "frontend",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "private": true,
  "scripts": {
    "build": "cross-env NODE_ENV=production webpack",
    "dev": "cross-env NODE_ENV=development webpack --colors --watch"
  },
  "devDependencies": {
    "webpack": "^4.43.0",
    "webpack-cli": "^3.3.11"
  }
}
```

### Webpack Config

Für Webpack brachen wir jetzt eine Konfigurationsdatei um anschließend alle Einstellungen vorzunehmen.

Hierfür erstellen wir eine Datei namens `webpack.config.js` im Ordner `Resources/Private/Frontend`.
Die Konfiguration beinhaltet weitere Pakete die wir benötigen.

- Das _clean-webpack-plugin_ das dafür sorgt das unser „Output“ Ordner immer sauber ist.
- Das _mini-css-extract-plugin_ das wir dazu benützen unser CSS in eine Seperate Datei zu extrahieren.
- Den _css-loader_ der dafür sorgt das wir innerhalb unser JS Dateien CSS importieren können
- Den _PostCSS-loader_ den wir dazu benützen um unser CSS z.b. zu minimieren und zu Optieren
- Den _babel-loader_ der dafür sorgt das wir TypeScript in JavaScript umwandeln können und anschließend unser JavaScript für mehrere Browser Optimieren können.
- Das _terser-webpack-plugin_ um unser JavaScript zu minimieren.

Die Abhängigkeiten dafür installieren wir wieder über Yarn als Packetmanager

`‌Yarn add -D mini-css-extract-plugin clean-webpack-plugin terser-webpack-plugin css-loader PostCSS-loader`

Die vollständige Konfiguration sieht dann im Ende so aus

##### webpack.config.js

```js
/* eslint-disable @typescript-eslint/no-var-requires */
const webpack = require('webpack')
const path = require('path')
const MiniCssExtractPlugin = require('mini-css-extract-plugin')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const TerserJSPlugin = require('terser-webpack-plugin')

const isDev = process.env.NODE_ENV !== 'production'
module.exports = {
  mode: process.env.NODE_ENV,
  devtool: isDev ? 'source-map' : 'cheap-source-map',
  entry: {
    main: './src/main.ts',
  },
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          {
            loader: MiniCssExtractPlugin.loader,
            options: { sourceMap: isDev },
          },
          {
            loader: 'css-loader',
            options: {
              url: false,
              import: false,
              importLoaders: 1,
              sourceMap: isDev,
            },
          },
          { loader: 'PostCSS-loader', options: { sourceMap: isDev } },
        ],
      },
      {
        test: /\.tsx?$/,
        use: [
          {
            loader: 'babel-loader',
            options: {
              extends: './.babelrc',
            },
          },
        ],
      },
    ],
  },
  output: {
    path: path.resolve(__dirname, '../../Public/Frontend/'),
    filename: 'Scripts/[name].js',
    chunkFilename: 'Scripts/[name].[contenthash].js',
    publicPath: '/typo3conf/ext/design/Resources/Public/Frontend/',
  },
  optimization: {
    minimize: !isDev,
    minimizer: [new TerserJSPlugin()],
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: 'Styles/[name].css',
      ignoreOrder: false, // Enable to remove warnings about conflicting order
    }),
    new CleanWebpackPlugin(),
  ],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, 'Scripts/'),
      '~': path.resolve(__dirname, 'Scripts/'),
    },
    extensions: ['.js', '.jsx', '.ts', '.tsx', '.json', '.vue'],
  },
}
```

Wir haben Webpack an dieser stelle Ebenfalls gesagt wo wir unsere JavaScript und CSS Daten haben möchten. Nämlich unter `Resources/Public/Frontend`. Diesen Pfad müssen wir anschließend in Unser TYPO3 Setup integrieren.

### PostCSS für CSS

Um PostCSS betreiben und Konfigurieren zu können brauchen wir diese Datei `packages/design/Resources/Private/Frontend/postcss.config.js`.

Ich habe in meinem Beispiel schon einige Praktische Plugins für PostCSS. Diese werden ebenfalls über Yarn installiert.
Was die Plugins im Einzelnen machen kann an auf der Seite der Plugins Nachlesen.

##### postcss.config.js

```js
const config = {
  plugins: [
    require('PostCSS-import'),
    require('precss'),
    require('PostCSS-preset-env'),
    require('cssnano'),
  ],
}

export default config
```

### TypeScript und Babel

Jetzt brauchen wir nur noch 2 Sachen einrichten und zwar Babel und TypeScript.
Ich verwende hier absichtlich Babel um TypeScript zu Kompilieren da wir dadurch auch Zugriff auf viele Babel Funktionen haben.

#### TypeScript Konfiguration

Hier passiert nicht viel 🙂.
wir erstellen eine Datei `packages/design/Resources/Private/Frontend/tsconfig.json` die für TypeScript eine art Konfigurationsdatei ist. Was die einzelnen Settings machen kann man auf der Seite <https://www.TypeScriptlang.org/docs/handbook/tsconfig-json.html> nachlesen.

##### tsconfig.json

```json
{
  "compilerOptions": {
    "allowJs": true,
    "alwaysStrict": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true,
    "lib": ["dom", "es2017"],
    "module": "esnext",
    "moduleResolution": "node",
    "noEmit": true,
    "noFallthroughCasesInSwitch": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "strict": true,
    "jsx": "preserve",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "~/*": ["./src/*"],
      "@/*": ["./src/*"]
    }
  },
  "exclude": ["node_modules"],
  "include": ["**/*.ts", "**/*.tsx"]
}
```

#### Bable config

In dieser Datei Konfigurieren wir das Verhalten von Babel. dafür benötigen wir ein par Abhängigkeiten.

Diese Abhängigkeiten fügen wie wieder mit Yarn hinzu `yarn add -D @babel/core @babel/preset-env @babel/preset-react @babel/preset-TypeScript`

Konfiguration Datei `Resources/Private/Frontend/.babelrc`

##### .babelrc

```json
{
  "presets": ["@babel/env", "@babel/react", "@babel/TypeScript"]
}
```

### Entrypoint und erste Funktionen

Nachdem wir alles eingerichtet haben können wir unsere erste kleine Application Schreiben um sie anschließen in TYPO3 Einzubinden.
Erstellen wir die Datei `packages/design/Resources/Private/Frontend/src/main.ts` mit Folgendem Inhalt

##### main.ts

```ts
import React from 'react'
import ReactDOM from 'react-dom'

const helloElement = document.getElementById('hello')

// Webpack lädt diese Daten asynchron wenn das Element vorhanden ist. Damit kann man sicherstellen das die JS Dateien immer so klein wie möglich gehalten werden
if (helloElement) {
  import(/* webpackChunkName: "hello" */ './components/Hello').then(
    ({ default: Hello }) => {
      ReactDOM.render(React.createElement(Hello), helloElement)
    }
  )
}
```

### Erste React App

In der Datei `packages/design/Resources/Private/Frontend/src/components/Hello.tsx` erstellen wir nun unsere Kleine React App die wir später über TYPO3 Einbinden wollen.
Ich habe hier einfach mal die Ausgabe eines kleinen Strings gebaut. Natürlich kann man hier sehr viel einbinden und erstellen. Ich habe im Laufe dieses Blogs auch Tests gemacht wie man Slider oder andere Elemente umsetzen kann.

##### Hello.tsx

```tsx
import React from 'react'

export default function Hello() {
  return <div>TYPO3 + Webpack + ☕️ = ❤️</div>
}
```

### TypoScript erweitern für React App

Jetzt müssen wir natürlich nur noch um das Element auch ausgeben zu können unser TypoScript erweitern.

Ich habe dies einfach in der setup.txt gemacht.

```js
page = PAGE
page {
    typeNum = 0

		# Einbinden der Hauptdatei alle weiteren werden asynchron geladen
    includeJSFooter {
        main = EXT:design/Resources/Public/Frontend/Scripts/main.js
    }

		# Hier wird die React App geladen
    10 = TEXT
    10.value = <div id='hello'>React App</div>

    100 = CONTENT
    100 {
        table = tt_content
        select {
            orderBy = sorting
            where = {#colPos}=0
        }
    }
}
```

## Ideen

Mit dieser Technik kann man ohne Problem alle Elemente abbilden die man bei einem Modernen Frontend Braucht.
Ich habe mir im laufe des Blogs ein Contentelement mit einem Slider gebaut. Die Bilder werden über das FAL ans Frontend als JSON übergeben und anschließend von React als Slider gerendert.


Webpack Integration in TYPO3 mit Code Splitting und PostCSS. Dieser Beitrag ist vor allem für Frontend Spezialisten gedacht die selbst ein Webpack setup aufbauen möchten. Damit lassen sich viele verschiedene Setups Realisieren. React und Vue.js lassen sich einfach Integrieren und sogar AngularJS kann mit etwas aufwand zum laufen gebracht werden. In diesem Beispiel benütze ich React und TypeScript um auf die Eigenheiten von verschiedenen Technologien einzugehen

TYPO3 mit webpack und Code Splitting

typo3 und webpack

Das VueJS Plugin vue-i18n könnt ihr euch auf GitHub ansehen <https://github.com/kazupon/vue-i18n>.
Dort findest du schon mal die Dokumentation <http://kazupon.github.io/vue-i18n/> und erste Informationen zu dem Projekt. Diese Sind im Repo selbst leider sehr Spärlich aber, sobald man auf die Dokumentation geht, merkt man das Hier sehr viel Zeit und Liebe hineingeflossen ist.

## Installation

Die Installation des Plugins gestaltet sich erst einmal sehr einfach. Man kann es mittels Paketmanager yarn oder npm installieren.

```bash
yarn add vue-i18n # für VueJS
# oder
npm install vue-i18n # für VueJS

yarn add nuxt-i18n # für Nuxt
# oder
npm i nuxt-i18n # für Nuxt
```

Wenn man die vue-cli verwendet dann kann man das Plugin auch hier recht einfach Integrieren.

```bash
vue add vue-i18n
```

## Integration in VueJS

In einer normalen VueJS Applikation geht das sehr einfach.

Du brauchst lediglich ein Plugin anzulegen mit diesem Inhalt

```js
// plugins/vue-i18n.js
import Vue from 'vue'
import VueI18n from 'vue-i18n'

Vue.use(VueI18n)
```

Danach einfach das Plugin in Vue laden.

```js
// ./main.js
import '~/plugins/vue-i18n'

new Vue({
  render: (h) => h(App),
}).$mount('#app')
```

## Integration in Nuxt

Hier geht das um einige einfacher denn ein Entwickler hat schon ein fertiges Modul bereitgestellt das wir nach der Installation einfach in der Datei nuxt.config.js integrieren können. <https://github.com/nuxt-community/nuxt-i18n>

```js
export default {
  /*
   ** Nuxt.js modules
   */
  modules: [
    // Doc: https://axios.nuxtjs.org/usage
    '@nuxtjs/axios',
    // Doc: https://github.com/nuxt-community/nuxt-i18n
    'nuxt-i18n',
  ],
}
```

## Konfiguration

Jetzt gehts ans Eingemachte 😀. Da ich sehr gerne die Übersetzungen in eigenen Dateien vorhalte, damit ich sie einfach von Projekt zu Projekt übernehmen kann, oder zu den Übersetzern schicken kann, habe ich hier in diesem Artikel auf diese Option gewählt.

### Konfiguration Datei

Zuerst erstellen wir uns eine Konfiguration für unser Projekt damit wir definieren können welche Sprachen wir verwenden und wie sich vue-i18n verhalten soll.

```js
// ./i18n/index.js
export default {
  locales: [
    {
      code: 'de',
      iso: 'de-DE',
      name: 'Deutsch',
      file: 'de.js', // hier wird definiert wie die datei heißt aus der er die sprache importieren soll
    },
    {
      code: 'en',
      iso: 'en-US',
      name: 'English',
      file: 'en.js', // hier wird definiert wie die datei heißt aus der er die sprache importieren soll
    },
  ],
  defaultLocale: 'de',
  langDir: 'i18n/', // hier liegen unsere Sprachen
  lazy: true,
  vuex: {
    moduleName: 'i18n',
    mutations: {
      setLocale: false,
      setMessages: false,
    },
    preserveState: false,
  },
  vueI18n: {
    fallbackLocale: 'de',
  },
}
```

Diese Konfigurationsdatei wird nun einfach in die Integration unseres Plugins importiert. Dies sieht bei VueJS etwas anders aus als bei Nuxt.

```js
// plugins/vue-i18n.js
import Vue from 'vue'
import VueI18n from 'vue-i18n'
import i18n from '~/i18n'

Vue.use(VueI18n, i18n)
```

```js
import i18n from '~/i18n'
export default {
  /*
   ** Nuxt.js modules
   */
  modules: [
    // Doc: https://axios.nuxtjs.org/usage
    '@nuxtjs/axios',
    ['nuxt-i18n', i18n],
  ],
}
```

## Benutzung

Die Benutzung des Plugins unterscheidet sich nicht zwischen VueJS und Nuxt solange es nur um die Lokalisierung geht.

```html
<p>{{ $t('message.hello', { msg: 'hello' }) }}</p>
```

### VueJS

Wenn es aber jetzt um den Switch der Sprache geht, sieht das schon anders aus. In einer normalen VueJS Anwendung geht das über die globale Variable `$i18n.locale`
Wichtig ist zu wissen das, wenn man sich in einer Komponente befindet man `$root` aufrufen muss da ansonsten nur die Komponente in der Sprache gewechselt wird.

```js
$root.$i18n.locale = 'de'
```

### Nuxt

In einer Nuxt Anwendung stehen uns für das Ändern der Sprache hier 2 Möglichkeiten zur Verfügung

Einmal das Wechseln der Sprache über einen Nuxt Link

```html
<nuxt-link
  v-for="locale in availableLocales"
  :key="locale.code"
  :to="switchLocalePath(locale.code)"
>
  {{ locale.name }}
</nuxt-link>
```

```js
export default {
  computed: {
    availableLocales() {
      return this.$i18n.locales.filter((i) => i.code !== this.$i18n.locale)
    },
  },
}
```

Die andere Variante ist das Wechseln der Sprache über die Routen. Denn das Nuxt Module erweitert die Routen um einen Sprachparameter.

```js
;[
  {
    path: '/',
    component: _3237362a,
    name: 'index___de',
  },
  {
    path: '/en/',
    component: _3237362a,
    name: 'index___en',
  },
  {
    path: '/about',
    component: _71a6ebb4,
    name: 'about___de',
  },
  {
    path: '/en/about',
    component: _71a6ebb4,
    name: 'about___en',
  },
]
```

Wenn man eine Neue seite erstellt oder eine Bestehende Seite Neu aufbaut stellt man sich zu beginn der Arbeit meist die Frage: „Ist die Zielgruppe meiner Webseite National oder International“. Wenn die Antwort „International“ lautet oder du von beginn an Flexibel bleiben Willst dann habe ich hier genau den Richtigen Artikel für dich. Denn das Projekt vue-i18n von Kazuya Kawaguchi hat hat mittlerweile über 120 Contributors und wird stetig weiter Entwickelt.

Mehrsprachigkeit in VueJS und Nuxt

mehrsprachigkeit-in-vuejs-und-nuxt

## Vorbereitung

### Die App

Zuerst brauchen wir eine nuxt Applikation, die wir ausliefern möchten.
Diese können wir relativ einfach über einen Terminal Befehl erstellen.

```bash
npx create-nuxt-app my-website
```

### Das Repository

Um den CI Prozess von Gitlab zu nutzen, reicht ein Kostenloser Account, in dem man ein Neues Repository anlegt oder ein bestehendes benutzt.

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/3j0m2pr0yn2wf6x6qt8x.jpg)

Wie man ein neues Anlegt kann man auf der Seite <https://docs.gitlab.com/ee/user/project/repository/#create-a-repository> nachlesen

Nachdem man dies erledigt hat, muss man einen Private Key hinterlegen. Die CI braucht diesen um Daten via rsync ausliefern zu können.

Wie man ein Key Paar erstellt findet ihr hier.<> https://help.github.com/en/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key>

In meinem Fall wird die Variable SSH_PRIVATE_KEY genannt. Diese Bezeichnung brauchen wir später in unserer Konfiguration

![Alt Text](https://thepracticaldev.s3.amazonaws.com/i/ix24yyppgtjru8gq3bj9.jpg)

Den Public Key müsst ihr dann auf Euerem Server hinterlegen. **Wichtig** ist hier das der **Key** auch dem **Benutzer zugeordnet** wird der später auch von nginx benutzt wird, um die Seite auszuliefern. Meistens ist dies der www-data Benutzer.

### Abschluss der Vorbereitung

So mehr müsst ich auch schon nicht machen denn ab jetzt kommt es nur noch auf die Konfiguration an.

## Gitlab CI

Um die Gitlab CI anzusprechen brauchen wir eine Datei im root unseres Projektes.

Diese Datei trägt den Namen .gitlab-ci.yaml.

Sobald Gitlab diese Datei erkennt, wird der CI Runner Aktiv und führt die Darin enthaltenen Befehle aus.

### Image

Das Image, dass wir definieren wird für alle Befehle verwendet die nicht ein Explizites image besitzen. Wir verwenden des Node image da dies alles hat was wir zum Bauen unserer Applikation benötigen.

```yaml
image: node
```

### Variablen

Hier Definieren wir weitere Variablen um sie nicht immer wieder eingeben zu müssen und unsere Datei auch in anderen Projekten verwenden zu können.

```yaml
variables:
  RSYNC: rsync -rtqx --links --safe-links --chmod=Du=rwx,Dgo=rx,Fu=rw,Fog=r --delete

  PROD_URL: https://creativeworkspace.de/
  PROD_USER: web_www
  PROD_SERVER: 159.69.21.63
  PROD_PATH: /var/www/clients/client1/web1/web
  PROD_PORT: '22'
```

### Cache

Damit gitlab zwischen den Stages die Daten nicht immer neu herunterladen muss und auch ein erneutes Ausführen schneller geht. Lassen wir gitlab den node_modules Ordner speichern. Dies spart uns sehr viel zeit, wenn wir mehrere Builds in kurzen abständen machen.

```yaml
cache:
  paths:
    - node_modules/
```

### Die Stages

Damit wir eine Kontrolle haben welcher Prozess von Gitlab in welcher Reihenfolge ausgeführt wird erstellen wir 2 Stages.
Diese Referenzieren wir in unseren Aufgaben die, die Gitlab CI Ausführen soll

```yaml
stages:
  - build
  - deploy
```

### Die Aufgaben

Die erste Aufgabe die Gitlab für uns erledigen soll ist das Bauen der Application. Wir speichern uns danach den ordner _dist_ als Artefakt damit wir diesen dann im 2. Schritt deployen können.

```yaml
build:
  stage: build
  before_script:
    - npm install
  script:
    - NODE_ENV=production npm run build
    - NODE_ENV=production npm run generate
  environment:
    name: production
  artifacts:
    expire_in: 1 hour
    name: '${CI_COMMIT_REF_NAME}'
    paths:
      - dist/
```

Als nächstes soll Gitlab für uns die Code Ausliefern.
Für diesen Schritt benutze ich nun ein anderes Image das eine RSYNC Kompenente besitzt.

Hier passiert jetzt sehr viel auf einmal. Zuerst Fügen wir unseren generierten SSH Key zum Image hinzu. Anschließend führen wir einen RSYNC auf unseren Server aus. Somit haben wir dann den Inhalt des \*_dist_ Ordners auf unserem server in dem Pfad den wir in den Variablen angegeben haben.

```yaml
deploy:prod:
  stage: deploy
  image: 1drop/php-73-docker-utils
  environment:
    name: production
    url: https://creativeworkspace.de
  before_script:
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add - > /dev/null
    - mkdir -p ~/.ssh
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - cd dist/
  script:
    - $RSYNC -e "ssh -p $PROD_PORT" . $PROD_USER@$PROD_SERVER:$PROD_PATH
  only:
    - master
```

## Abschluss

Ab jetzt brauchen wir unserem nginx nur noch sagen, dass er die Daten aus diesem Verzeichnis ausliefern soll und fertig :)


In diesem Artikel zeige ich euch wie ihr eine Nuxt Application mit der Gitlab-CI bauen und auf dem Server ausrollen könnt.

Deploy nuxt.js static mit gitlab-ci

deploy-nuxt-js-static-with-gitlab-ci

Ebenfalls werden Seiten, die aktualisiert werden, schneller in den Index der Suchmaschinen (z.b. Google, Yahoo, DuckDuckGo, usw.) aufgenommen.

TYPO3 gibt dem Programmierer oder Integrator viele Möglichkeiten zur Hand um diverse Seitentypen zu erstellen (z.B. dynamische Seiten über Extensions wie news), was aber leider die Erstellung einer Sitemap erschwert.

Dafür gibt es jetzt eine Abhilfe. Mit meiner Extension, dem Sitemap Generator für TYPO3, war es noch nie einfacher eine Sitemap zu erstellen. Einfach die Extension aus dem TER oder via Composer laden und aktivieren [https://extensions.typo3.org/extension/sitemap_generator](https://extensions.typo3.org/extension/sitemap_generator/) Danach steht ein neues Template zur Verfügung, welches über den Template Editor eingebunden werden kann.

Mit einem einfachen TypoScript kann anschließend jeder Datensatztyp eingebunden werden.

Siehe: <https://docs.typo3.org/>

Die Sitemap ist danach über die URL deiner Website aufrufbar. <https://www.deine.domain/index.php?id=1&type=1449874941>.

Man kann sich die URL auch von RealURL bauen lassen. Dann ist sie auch für Suchmaschinen sehr schön lesbar.


Eine Sitemap hat viele Vorteile, vor allem im Bereich der Suchmaschinenoptimierung (SEO). Sie ist hilfreich um eine Seite schnell von einem Crawler indexieren zu lassen und auf neue Seiten hinzuweisen.

Sitemap in TYPO3 leicht gemacht

2018-10-10-sitemap-fuer-typo3-leicht-gemacht-full

Wikipedia bescheib das Problem folgendermaßen:

Webseiten können aktive Inhalte beispielsweise in Form von JavaScript-Code enthalten. Wenn die Webbrowser diesen Code ausführen, erzwingen sie die Einhaltung der Same-Origin-Policy. Dies bedeutet, dass Code von einer Quelle nicht auf Inhalte einer anderen Quelle zugreifen darf. So darf beispielsweise der Code in der Webseite eines Angreifers nicht auf die Elemente einer Onlinebanking-Webseite zugreifen.

In der Praxis sind jedoch Cross-Site-Scripting-Schwachstellen sehr verbreitet, wodurch die Same-Origin-Policy ausgehebelt wird. Eine Cross-Site-Scripting-Schwachstelle entsteht, wenn sich eine Webseite durch fehlerhafte Maskierung Code unterschieben lässt. Aus Sicht des Browsers kommt dieser untergeschobene Code aus der gleichen Quelle wie die angegriffene Webseite.

## Die Lösung

Mittels Header Variable wird der Browser dazu veranlasst Scripte und Anweisungen im Quelltext zu Prüfen und gegebenenfalls nicht auszuführen.

Dies Bedeutet aber auch das viele Funktionen die eine Website benutzt wie z.b. Google Fonts oder Externe Bibliotheken oder CDN's in Ausnahmen definiert werden müssen. Um das Ganze zu vereinfachen gibt es die Webseite <https://www.cspisawesome.com/>. Diese ermöglicht uns für unsere Seite die Passende Content Security Policy zu generieren.

## Einbindung

Als erstes kommt uns natürlich in den Sinn das ganze über unseren Webserver einzubinden. Z.b. über den Apache (.htaccess)

```
Header set Content-Security-Policy "default-src 'none'"
```

Es gibt dabei leider das Problem das es bei jedem Request eingebunden wird. Also auch bei jedem Bild oder aber auch im Backend. Was es danach leider unmöglich macht das Backend zu bedienen außer man gibt alles wieder Frei. Was ja auch nicht der Sinn der Sache ist.

TypoScript: die bessere alternative
TypoScript erlaubt uns das ganze sehr einfach zu erstellen. Hier können wir nämlich nur unsere TYPO3 Frontendausgabe mit der Content Security Policy versehen. Ohne das unser TYPO3 Backend oder die Assets beeinflusst werden.

```js
config.additionalHeaders {
    10.header = Content-Security-Policy: default-src 'none'
}
```

Sobald wir das ergänzt haben wird ab jetzt im Frontend immer dieser Header mit ausgegeben.

Was ist eigentlich die Content Security Policy und warum sollte ich sie einsetzen? Eine integration in TYPO3

TYPO3 und die Content Security Policy

2018-02-10-typo3-und-die-content-security-policy-full

Wer hat nicht schon mal das Problem gehabt das ein Kunde oder man selbst ein youtube Video oder einen Button gebraucht hat. Dafür aber gleich eine Extension einbauen? Sein TYPO3 CMS mit zusätzlichen Features belasten, obwohl man diese vielleicht gar nicht braucht?

Was wir als Erstes brauchen ist eine eigene Extension als Grundlage. Diese muss nicht viel enthalten. Es reicht, wenn sie lediglich aus folgender Struktur besteht.

```
eigene_inhaltselemente
    Configuration
        TypoScript
            setup.txt
    TCA
        Overrides
            tt_content.php
    Resources
        Private
            Templates
                NameDesContentEmementes.html
    ext_tables.php
    ext_emconf.php
```

Ich beziehe mich hier auf die Extbase Struktur. Jedem ist aber selbst überlassen wie er seine Extensions aufbaut. Falls man an größeren Projekten arbeitet sollte man sich auf alle Fälle auf eine Struktur festlegen. Diese erleichtert das Arbeiten im Team ungemein. Weitere Dateien die angelegt werden können sind z.b. ext_icon.png|gif|svg und ext_tables.sql. Alle weiteren Optionen findet ihr im <http://wiki.typo3.org/Extension_Developers_Guide>.

## ext_emconf.php

Als erstes befassen wir uns kurz mit der ext_emconf.php. Diese dient alleine dazu das wir später die Extension auch im TYPO3 Extensionmanager finden und aktivieren können. Ohne diese Aktivierung greifen unsere Einstellungen und Programmierungen nicht.

```php
$EM_CONF[$_EXTKEY] = array(
	'title' => 'Inhaltselemente',
	'description' => 'Eigene Inhaltselemente für meine Webseite',
	'category' => 'misc',
	'version' => '0.0.1',
	'dependencies' => 'cms,extbase,fluid',
	'state' => 'beta',
	'author' => 'Markus Sommer',
);
```

Genaue Details zu dieser Datei findet man im TYPO3 Wiki.

## ext_tables.php

Als nächstes kommt die wichtigste Datei. Hier wird die Extension konfiguriert und damit natürlich auch unser Inhaltselement.

Wir binden dazu 2 Codeblöcke ein die je nach Bedarf natürlich erweitert werden können.

## TypoScript

PageTS einbinden für den »Content Wizzard«

### 1. TypoScript einbinden

Das Einbinden des TypoScripts in dem wir die Konfiguration für das Inhaltselement angeben.

```php
TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addStaticFile($_EXTKEY, 'Configuration/TypoScript', 'Eigene Inhaltselemente');
```

### 2. Zum Content Wizzard hinzufügen

Damit unser neues Element auch im »Content Wizzard« verfügbar ist müssen wir das PageTS erweitern um folgende Zeilen. Damit wir keine zusätzliche TypoScript Datei benötigen können wir eine Function des TYPO3 CORE's benutzen um unser PageTS einzubinden. Zudem Registrieren wir uns gleich einen Eigenen Tap namens OnePage um unsere Eigenen Elemente einfacher zu finden.

```php
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPageTSConfig('
mod {
	wizards.newContentElement.wizardItems.extra {
		header = OnePage
		elements {
			video_content {
				icon = ../typo3conf/ext/eigene_inhaltselemente/Resources/Public/Images/Backend/ContentElements/VideoContent.png
				title = Video Content Element
				description = Ein Element für Youtube Videos
				tt_content_defValues {
					CType = video_content
				}
			}
		}
		show = *
	}
}
');
```

## tt_content erweitern »meine_extension/ Configuration/ TCA/ Overrides/ tt_content.php«

Dieser Teil definiert und registriert unser Inhaltselement im TCA. Im array »showitem« legen wir fest welche Felder unser Inhaltselement bekommen soll. Hier haben wir die freie Auswahl aus den Standartfeldern der Inhaltselemente die das TYPO3 CMS mit bringt.

Natürlich können wir hier auch eigene Felder erstellen. Diese kann man dann in der ext_tables.sql eintragen. Diese Datei enthält das SQL-Statement das die Tabellen erzeugt oder aktualisiert.

In meinem Beispiel benutze ich die Felder »bodytext« um die URL zum Video abzuspeichern. Im Feld "image" wird über das FAL wird ein Thumbnail gesetzt das wir später Ausgeben. Die Überschrift definieren wir über »header« und fügen über »subheader« eine Unterüberschrift ein. Danach fügen wir noch die Zugriffs und Extended Tabs hinzu. Diese dienen der Zeitgesteuerten Veröffentlichung und des Zugriffsschutzes falls man Frontenduser hat.

```php
$tca = array(
	'types' => array(
		'video_content' => array(
			'showitem' => '--palette--;LLL:EXT:cms/locallang_ttc.xlf:palette.general;general,
	bodytext;Youtube Video URL,
	image;Thumbnail,
	header;Headline,
	subheader;Subheadline,
	--div--;LLL:EXT:cms/locallang_ttc.xlf:tabs.access,
	--palette--;LLL:EXT:cms/locallang_ttc.xlf:palette.visibility;visibility,
	--palette--;LLL:EXT:cms/locallang_ttc.xlf:palette.access;access,
	--div--;LLL:EXT:cms/locallang_ttc.xlf:tabs.extended'
		)
	),
	'columns' => array(
		'CType' => array(
			'config' => array(
				'items' => array(
					'video_content' => array(
						'Video Element', // Name des Inhaltselementes
						'video_content', // TCA Name des Inhaltselementes
						'EXT:eigene_inhaltselemente/Resources/Public/Images/Backend/ContentElements/VideoContent.png' // Bild des Inhaltelementes
					)
				)
			)
		)
	)
);

$GLOBALS['TCA']['tt_content'] = array_replace_recursive($GLOBALS['TCA']['tt_content'], $tca);
```

Seit der TYPO3CMS Version 6.2 werden Erweiterungen im TCA im Verzeichnis Configuration/TCA/Overrides abgelegt. Infos dazu findet ihr in diesem Slide <http://de.slideshare.net/pk77/2015-04-tca-anderungen>

## TypoScript »meine_extension/ Configuration/ TypoScript/ setup.txt«

So ab jetzt ist unser Inhaltselement im TYPO3 CMS verfügbar. Damit wir aber auch eine passende Ausgabe im Frontend bekommen müssen wir noch ein par Einstellungen im TypoScript vornehmen. Diese dienen allein dafür, dass unser Inhaltselement gerendert wird. Praktischerweise bringt TYPO3 schon die notwendigen Funktionen mit so das wir uns hier aus 2 Quellen bedienen können. Einmal das CSS_STYLED_CONTENT und als zweites FLUID.

Mit folgendem TypoScript legen wir das Rendering für das Inhaltselement fest. Wir benutzen dafür ein FLUID Template. Dieses ist sehr einfach zu konfigurieren und falls wir noch zusätzliche »ViewHelper« benötigen haben wir vollen zugriff auf die TYPO3 Funktionen.

Da wir das FAL benutzen um unser Vorschaubild zu Rendern packen wir das ganze in eine Fluid Variable um darauf ohne Probleme zugreifen zu können. Wir bedienen uns hier der Standardfunktion aus dem CSS_STYLED_CONTENT

```
tt_content.video_content = FLUIDTEMPLATE
tt_content.video_content {
	file = EXT:eigene_inhaltselemente/Resources/Private/Templates/VideoContent.html
	variables {
		previewImage = FILES
		previewImage {
			references {
				table = tt_content
				fieldName = image
			}
			renderObj = IMAGE
			renderObj {
				file.import.data = file:current:uid
				file.treatIdAsReference = 1
			}
		}
	}
}
```

## FLUID Template

Als letztes kommt das FLUID Template dran. Hier können wir auf die Felder mittels {data} zugreifen. In dieser Variable finden wir alle von TYPO3 gerenderten Felder.

Im FLUID Wiki von finden wir die Komplette Referenzen Hier kann man sich einfach spielen und das Inhaltselement nach Belieben anpassen.

```html
<div class="video-content">
  <div class="video-content__video">
    <a href="{data.bodytext}">{previewImage -> f:format.raw()}</a>
  </div>
  <div class="video-content__content">
    <h3>{data.header}</h3>
    <h4>{data.subheader}</h4>
  </div>
</div>
```

## Nachwort

So ab nun kann man ganz einfach weitere Inhaltselemente hinzufügen und so hinbiegen wie man sie gerne hätte. Wenn jemand Fragen oder Anregungen hat einfach an info@creativeworkspace.de schreiben. Ich bin auch jederzeit via Twitter erreichbar mit @beardcoder.

Viel Spaß beim Ausprobieren und herumexperimentieren.

Wer sich die Komplette Extension ansehen oder herunterladen möchte findet sie bei mir auf Github unter <https://github.com/beardcoder/eigene_inhaltselemente>

Vielen dank an:

[http://typo3.org/ ](http://typo3.org/)für die Bereitstellung des Wikis


Einfach und schnell eigene Inhaltselemente im TYPO3 CMS erstellen

Eigene Inhaltselemente im TYPO3 CMS 6.2.x und 7.x

2017-09-27-eigene-inhaltselemente-im-typo3-cms-6-2-x-und-7-x-full

backup_me

bavaria-ipsum

bavaria-ipsum-web

creativeworkspace

eigene_inhaltselemente

frontbrew

html_compress

itiden.se

php-72-docker-utils

Easy to use #TYPO3 #CMS Sitemap Generator. 

sitemap_generator

A oh-my-zsh plugin for surf command completion.

surf.plugin.zsh

system_update

webpack_typo3

Docker Proxy settings for ISPconfig with nginx

This helper prevents the focus ring on mouse interaction for bootstap buttons

Neos nginx configuration (by @sorenmalling)

Disable TYPO3 LDAP Login (EXT:ig_ldap_sso_auth)

TYPO3 Solr pageIndexer recursive downline / upline enabled

Hi, ich bin Markus Sommer

Projekte

Blog

TYPO3 mit webpack und Code Splitting

Mehrsprachigkeit in VueJS und Nuxt

Deploy nuxt.js static mit gitlab-ci

Sitemap in TYPO3 leicht gemacht

TYPO3 und die Content Security Policy

Eigene Inhaltselemente im TYPO3 CMS 6.2.x und 7.x

Coding

backup_me

bavaria-ipsum

bavaria-ipsum-web

creativeworkspace

eigene_inhaltselemente

frontbrew

html_compress

itiden.se

php-72-docker-utils

sitemap_generator

surf.plugin.zsh

system_update

webpack_typo3

Snippets

Mapping Pattern

Allow switch window over all workspaces

Store Pattern für vuex store

Typescript Vue Template

Typescript Vuex Module

Sample api file for js api calls

Docker Proxy settings for ISPconfig with nginx

Encoding video for the web

This helper prevents the focus ring on mouse interaction for bootstap buttons

Neos nginx configuration (by @sorenmalling)

Neos CMS NodeType Image

Neos NodeType Checkbox

Neos NodeType TextArea

Neos NodeType TextArea

Neos CMS NodeType Image

Neos CMS NodeType Link

Neos CMS NoteType Text

Neos NodeType Selectbox

Atomic Fusion responsive image

keybase

Neos FastCGI Cache with nginx

Use Redis as Neos Cache Backend

Docker Sync for WebDevOps Boilerplate

Disable TYPO3 LDAP Login (EXT:ig_ldap_sso_auth)

TYPO3 Solr pageIndexer recursive downline / upline enabled

Neos csp

Resolve container by hostname

Tools for website check