Webdesign und TYPO3 Blog aus DuisburgMAC localhost kill Prozess Port 8080 8000 (24.1.2017, 13:23 UTC)

Beim Webdevelopment lokal auf dem MAC nutzt man gerne einen Prozess Port 8080 oder 8000. Bekannte Beispiele sind hier z.B. Symfony, TYPO3, WordPress oder auch Silex. Alle Technolgien sind mir sehr vertraut und bei mir im täglichen Einsatz. Hier kann es allerdings sein, daß ich den Prozess nicht richtig beende und den Tab bei oh-my-zsh schon vorher schließe. Dann läuft der Prozess im Hintergrund weiter und blockiert einen Start bei einem anderen Projekt.

Command Line MAC localhost kill Prozess Port 8080

Vorab es macht auf jeden Fall Sinn hier mit oh-my-zsh zu arbeiten, damit man die Autovervollständigung auf der CLI Command Line nutzen kann. Zuerst suchen wir alle Prozesse die auf Port 8080 laufen.

MAC finde alle Prozesse auf Port 8080

lsof -i tcp:8080

Jetzt wird der entsprechende Prozess gelistet. Hier wird u.a. eine UID. Dann einfach ein kill command ausführen.

kill -9 <PID>

MAC Kill Prozess 8080 localhost

MAC Kill Prozess 8080 localhost

 

Der TYPO3 Webdesign Blog MAC localhost kill Prozess Port 8080 8000 erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
Gjero KrsteskiLean Testing und eine Beobachtung der letzten Jahre – ein Gastbeitrag von Nils Langner (17.1.2017, 14:48 UTC)

Über den Autor: Einige von euch kennen Nils vielleicht aus seinem Blog phphatesme, die anderen von Konferenzen oder ähnlichem. Vor einem Jahr hat er sich aufgemacht das “Lean Testing”-Vorgehen unter die Leute zu bringen. Das liegt hauptsächlich daran, dass diese Testing-Methodik wunderbar zum Internet passt, aber vielleicht auch, weil er mit Leankoala die erste “Software as a Service”-Lösung in diesem Bereich auf den Markt gebracht hat. Ach ja, er schreibt Texte über sich gerne in der dritten Person.

Was haben wir nicht alles die letzten Jahre ausprobiert?! Seit über zehn Jahren habe ich mich jetzt schon in das Thema des Qualitätsmanagements gestürzt. Die meiste Zeit davon im Web. Ausprobiert habe ich fast alles und vieles lieben gelernt. Begonnen haben wir oft mit einfachen Testplänen, die wir dann genutzt haben, um manuell Webseiten durchzutesten, wenn einem das zu blöd wurde, hat man Selenium angeworfen und echte Browser automatisiert ferngesteuert. Danach wurde man etwas mutiger und hat sich Behaviour Driven Development angeschaut. Auch eine feine Sache. Die Testabdeckungen wurden immer ausgereifter und umfänglicher, was leider häufig dazu geführt hat, dass die Wartbarkeit gelitten hat. Alles in allem war man aber glücklich, da trotz des manchmal hohen Aufwandes man trotzdem schneller mit der Testen von Funktionen war, als die Entwickler neue Features rausgebracht haben.

2012, nachdem wir fast alles ausprobiert hatten, was der Markt so zu bieten hatte, wollten wir etwas Neues ausprobieren. Also schrieben wir unser eigenes kleines Werkzeug, um uns zu helfen Tests zu schreiben und durchzuführen. Wir haben es LiveTest2 genannt und es sollte dabei behilflich sein einfache Eigenschaften von Webseiten abzutesten. So konnte man zum Beispiel in einer Konfigurationsdatei sagen, dass auf jeder hinterlegten Seite der String Impressum vorkommen soll. So wollten wir sicherstellen, dass der Footer überall gerendert wird. Ziel war es möglichst einfach simple Smoke-Tests aufzustellen. Ein Test wie dieser muss schnell durchgeführt sein, um zu entscheiden, ob es sich lohnt die teuren, lange dauernden Tests auszuführen. Zu dieser Zeit sind wir zweigleisig gefahren. Einfache Tests als erste Testphase und danach die Tests, die wir mit unserem QA-Stolz gebaut hatten.

Nach einer gewissen Zeit kam dann die angekündigte Beobachtung. Jedes Mal wenn die einfachen günstigen Tests angeschlagen haben, haben uns auch die teuren alarmiert. Und wenn die einfachen Tests gesagt haben, dass alles grün ist, so haben sich die teuren angeschlossen. Daher haben wir erstmal die Theorie aufgestellt, dass LiveTest2 genauso gut ist wie andere Testing-Tools, nur mit weniger initialen Aufwand. Betrachtet man die beiden Herangehensweisen genauer, fällt einem ein großer Unterschied auf. Bei Unit-Tests, BDD-Tests und Selenium-Tests versucht man häufig jeden möglichen Fehlerfall auszutesten. Jeder potentiellen Ursache von Fehlern sollte möglichst ein Test zugeordnet sein. Bei unserer neuen Methodik ging es nicht mehr um Ursachen, sondern um Symptome.

Nehmen wir wieder das Beispiel des Footers. Sobald das Wort Impressum nicht mehr vorhanden ist, wissen wir, dass wir funktionale Probleme haben. Welche Ursache dies hat, können wir anhand des Testes nicht sagen. Der Erfahrung nach ist den Entwicklern dies aber trotzdem sehr schnell klar.

2014 kamen wir dann mit dem Begriff Lean Testing auf, den ich für diese Art des Testens prägen wollte. Dabei geht es darum sich auf Symptome zu konzentrieren und nicht mehr auf Ursachen.

Wenn man eine Weile im Internet unterwegs ist, dann ist einem klar, dass die Anzahl der Symptome, die klassischerweise auftauchen, sehr beschränkt ist. So kommt man mit einem einfachen “Http-Status-Code 200”-Test in der Integrations- oder Stage-Umgebung schon sehr weit. Fügt man dann noch die Möglichkeit hinzu nach Texten zu suchen ist man fast durch. Weil man das Web kennt garniert man das ganze noch mit XPath und Css-Selektoren. Dazu hatten wir 2015 das Open-Source Tool Smoke released, was all diese Tests beinhaltet.

2016 haben wir begonnen diese Methodik in eine “Software as a Service”-Lösung zu gießen und es ist mit dem Anfang dieses Jahre die erste Produktivversion unter www.leankoala.com erschienen.

Link
Gjero KrsteskiLean Testing und eine Beobachtung der letzten Jahre – ein Gastbeitrag von Nils Langner (17.1.2017, 14:48 UTC)

Über den Autor: Einige von euch kennen Nils vielleicht aus seinem Blog phphatesme, die anderen von Konferenzen oder ähnlichem. Vor einem Jahr hat er sich aufgemacht das “Lean Testing”-Vorgehen unter die Leute zu bringen. Das liegt hauptsächlich daran, dass diese Testing-Methodik wunderbar zum Internet passt, aber vielleicht auch, weil er mit Leankoala die erste “Software as a Service”-Lösung in diesem Bereich auf den Markt gebracht hat. Ach ja, er schreibt Texte über sich gerne in der dritten Person.

Was haben wir nicht alles die letzten Jahre ausprobiert?! Seit über zehn Jahren habe ich mich jetzt schon in das Thema des Qualitätsmanagements gestürzt. Die meiste Zeit davon im Web. Ausprobiert habe ich fast alles und vieles lieben gelernt. Begonnen haben wir oft mit einfachen Testplänen, die wir dann genutzt haben, um manuell Webseiten durchzutesten, wenn einem das zu blöd wurde, hat man Selenium angeworfen und echte Browser automatisiert ferngesteuert. Danach wurde man etwas mutiger und hat sich Behaviour Driven Development angeschaut. Auch eine feine Sache. Die Testabdeckungen wurden immer ausgereifter und umfänglicher, was leider häufig dazu geführt hat, dass die Wartbarkeit gelitten hat. Alles in allem war man aber glücklich, da trotz des manchmal hohen Aufwandes man trotzdem schneller mit der Testen von Funktionen war, als die Entwickler neue Features rausgebracht haben.

2012, nachdem wir fast alles ausprobiert hatten, was der Markt so zu bieten hatte, wollten wir etwas Neues ausprobieren. Also schrieben wir unser eigenes kleines Werkzeug, um uns zu helfen Tests zu schreiben und durchzuführen. Wir haben es LiveTest2 genannt und es sollte dabei behilflich sein einfache Eigenschaften von Webseiten abzutesten. So konnte man zum Beispiel in einer Konfigurationsdatei sagen, dass auf jeder hinterlegten Seite der String Impressum vorkommen soll. So wollten wir sicherstellen, dass der Footer überall gerendert wird. Ziel war es möglichst einfach simple Smoke-Tests aufzustellen. Ein Test wie dieser muss schnell durchgeführt sein, um zu entscheiden, ob es sich lohnt die teuren, lange dauernden Tests auszuführen. Zu dieser Zeit sind wir zweigleisig gefahren. Einfache Tests als erste Testphase und danach die Tests, die wir mit unserem QA-Stolz gebaut hatten.

Nach einer gewissen Zeit kam dann die angekündigte Beobachtung. Jedes Mal wenn die einfachen günstigen Tests angeschlagen haben, haben uns auch die teuren alarmiert. Und wenn die einfachen Tests gesagt haben, dass alles grün ist, so haben sich die teuren angeschlossen. Daher haben wir erstmal die Theorie aufgestellt, dass LiveTest2 genauso gut ist wie andere Testing-Tools, nur mit weniger initialen Aufwand. Betrachtet man die beiden Herangehensweisen genauer, fällt einem ein großer Unterschied auf. Bei Unit-Tests, BDD-Tests und Selenium-Tests versucht man häufig jeden möglichen Fehlerfall auszutesten. Jeder potentiellen Ursache von Fehlern sollte möglichst ein Test zugeordnet sein. Bei unserer neuen Methodik ging es nicht mehr um Ursachen, sondern um Symptome.

Nehmen wir wieder das Beispiel des Footers. Sobald das Wort Impressum nicht mehr vorhanden ist, wissen wir, dass wir funktionale Probleme haben. Welche Ursache dies hat, können wir anhand des Testes nicht sagen. Der Erfahrung nach ist den Entwicklern dies aber trotzdem sehr schnell klar.

2014 kamen wir dann mit dem Begriff Lean Testing auf, den ich für diese Art des Testens prägen wollte. Dabei geht es darum sich auf Symptome zu konzentrieren und nicht mehr auf Ursachen.

Wenn man eine Weile im Internet unterwegs ist, dann ist einem klar, dass die Anzahl der Symptome, die klassischerweise auftauchen, sehr beschränkt ist. So kommt man mit einem einfachen “Http-Status-Code 200”-Test in der Integrations- oder Stage-Umgebung schon sehr weit. Fügt man dann noch die Möglichkeit hinzu nach Texten zu suchen ist man fast durch. Weil man das Web kennt garniert man das ganze noch mit XPath und Css-Selektoren. Dazu hatten wir 2015 das Open-Source Tool Smoke released, was all diese Tests beinhaltet.

2016 haben wir begonnen diese Methodik in eine “Software as a Service”-Lösung zu gießen und es ist mit dem Anfang dieses Jahre die erste Produktivversion unter www.leankoala.com erschienen.

Link
Webdesign und TYPO3 Blog aus DuisburgCaps Lock Shift Taste Escape statt Delete Key macOS Sierra (3.1.2017, 13:50 UTC)

Für effektives Arbeiten an Keyboards ist es wichtig die Shift Taste Escape (Caps Lock) zu belegen. So hat man die größte Taste auf der Baseline mit einer wichtigen Funktion belegt. Da ich selber recht viel mit VIM arbeite und die Escape-Taste auch sonst recht häufig brauche habe ich diese auf die Caps Lock gelegt. Einige Webdeveloper nutzen hier allerdings auch die Delete-Taste. Das ist vielleicht auch ein sehr guter Usecase. Da schlägt bei mir allerdings die Macht der Gewohnheit zu.

Die Caps Lock oder Shift Taste mit Escape statt Delete Key in macOS Sierra

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Leider gibt es eine Änderung bei der neuen Version von Apples Betriebssystem macOS Sierra gegenüber vorherigen Versionen. Hier hatte ich bereits über das Setting mit der Software Seil gebloggt. Das fällt ab sofort flach und geht dafür allerdings gefühlt auch ein wenig einfacher. Man ruft einfach folgendes auf

Systemeinstellungen
Tastatur
Sondertasten
Shift Taste
Escape auswählen

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Caps Lock Shift Taste Escape statt Delete Key macOS Sierra

Leider muß man das sowohl für die normale Tastatur, als auch für die Magic Keypad Settings einrichten. Das ist zwar recht seltsam, aber nicht die Hölle

Der TYPO3 Webdesign Blog Caps Lock Shift Taste Escape statt Delete Key macOS Sierra erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
Webdesign und TYPO3 Blog aus DuisburgGulp run sequence – Gulp Task sequentiell abarbeiten (24.11.2016, 11:41 UTC)

Frontend-Webdevelopment mit Gulp Task sequentiell abarbeiten ist bei modernen Webdesign nötig. Dabei sind Gulp-Tasks ein wichtiger Bestandteil dieser tollen neuen Technologie. Gulp ist eine NodeJS Applikation, die natürlich auch in der Prozessverarbeitung ihre großen Vorzüge bezüglich der Performance hat. Asynchrone Prozessverarbeitung. Damit tun sich traditionelle Webdeveloper, gerade aus der PHP-Welt recht schwer. Hier findet man sich dann schnell in der sogenannten Callback-Hell wieder. An diesem Punkt sollte man sich natürlich fragen, ob man die richtige Technologie für das zu lösende Problem gewählt hat.

Gulp Task sequentiell ausführen – TYPO3 Gulp

In einer TYPO3 Migration von 6.2 auf 7.6 bin ich vor kurzem auf eine Herausforderung mit Gulp gestoßen. Hier war es wichtig die CSS-Files und JS-Files erst zu minimieren und dann an die richtige Stelle zu meiner Design Extension zu exportieren. So konnte unabhängig im Front- und Backend im Team gearbeitet werden.

const gulp = require('gulp');
const debug = require('gulp-debug');
const gulpLoadPlugins = require('gulp-load-plugins');
const wiredep = require('wiredep').stream;
const del = require('del');
const runSequence = require('run-sequence');

const $ = gulpLoadPlugins();

var stylesTarget = 'Resources/Public/Styles/';
var scriptsTarget = 'Resources/Public/Scripts';
var imagesTarget = 'Resources/Public/Images';
var fontsTarget = 'Resources/Public/Fonts';

gulp.task('clean-styles', del.bind(null, [stylesTarget]));
gulp.task('styles', () => {
  return gulp.src('../../rogoit-design/app/Styles/*.scss')
    .pipe(debug())
    .pipe($.plumber())
    .pipe($.sourcemaps.init())
    .pipe($.sass.sync({
      outputStyle: 'expanded',
      precision: 10,
      includePaths: ['.']
    }).on('error', $.sass.logError))
    .pipe($.autoprefixer({browsers: ['> 1%', 'last 2 versions', 'Firefox ESR']}))
    .pipe($.sourcemaps.write())
    .pipe(gulp.dest(stylesTarget));
});

gulp.task('clean-scripts', del.bind(null, [scriptsTarget]));
gulp.task('scripts', () => { // ['lint'],
  return gulp.src('../../rogoit-design/app/Scripts/**/*.js')
    .pipe(debug())
    .pipe($.plumber())
    .pipe($.babel())
    .pipe(gulp.dest(scriptsTarget));
});

gulp.task('vendor-scripts', () => { // ['lint'],
    return gulp.src(['../../rogoit-design/dist/Scripts/vendor/**/*', '../../rogoit-design/dist/Scripts/vendor.js'])
        .pipe(debug())
        .pipe(gulp.dest('Resources/Public/Scripts/vendor'));
});

gulp.task('clean-images', del.bind(null, [imagesTarget]));
gulp.task('images', () => {
  return gulp.src('../../rogoit-design/app/Images/**/*')
    .pipe(debug())
    .pipe($.imagemin({
      progressive: true,
      interlaced: true,
      svgoPlugins: [{cleanupIDs: false}]
    }))
    .pipe(gulp.dest(imagesTarget));
});

gulp.task('clean-fonts', del.bind(null, [fontsTarget]));
gulp.task('fonts', () => {
  return gulp.src(require('main-bower-files')('**/*.{eot,svg,ttf,woff,woff2}', function (err) {})
    .concat('../../rogoit-design/app/Fonts/**/*'))
    .pipe(debug())
    .pipe(gulp.dest(fontsTarget));
});


function lint(files, options) {
  return gulp.src(files)
    .pipe($.eslint(options))
    .pipe($.eslint.format());
}

gulp.task('lint', () => {
  return lint('../../rogoit-design/Scripts/**/*.js', {
    fix: true
  })
  .pipe(gulp.dest(scriptsTarget));
});

gulp.task('compress', ['styles', 'scripts'], () => {
  return gulp.src(['Resources/Public/**/*'])
    .pipe(debug())
    .pipe($.if('*.js', $.uglify()))
    .pipe($.if('*.css', $.cssnano({safe: true, autoprefixer: false})))
    .pipe(gulp.dest('Resources/Public'));
});

gulp.task('default', function(done) {
    runSequence('clean-styles', 'clean-scripts', 'clean-images', 'clean-fonts','styles', 'scripts', 'vendor-scripts', 'fonts', 'images', 'compress', function() {
        console.log('All tasks finished');
        done();
    });
});

Gulp Task sequentiell

Artikel gek: Lesen Sie den Rest hier (weitere 1424 Bytes)

Link
PHPUG WürzburgEinladung zum November-Treffen / Verlosung PHPStorm-Lizenz (22.11.2016, 14:14 UTC)

Hallo alle zusammen!

Wir treffen uns am 29. November um 19 Uhr in

Mennas Time Out
Frankfurter Straße 1
97082 Würzburg

Parkplätze sind in der näheren Umgebung ausreichend vorhanden, Straßenbahn-Haltestelle: Wörthstraße.

Und dran denken: Es wird eine Lizenz von PHPStorm verlost!

Ich freue mich auf viele Teilnehmer und rege Diskussionen!

Viele Grüße
Jason

Link
Coding – byteludeWie kann ich einen unendlich lang gültigen Facebook Page Accesstoken erzeugen? (7.11.2016, 19:00 UTC)

Facebook Access Tokens sind eine ziemlich fiese Sache, wenn man Server only Anwendungen bauen möchte – also keine wirkliche Chance hat, den User einen Token besorgen zu lassen. Zusätzlich haben die “normalen” Access Tokens bei Facebook das Problem, dass sie spätestens nach 60 Tagen ungültig sind. Es gibt aber derzeit noch eine Möglichkeit, an unendlich gültige Access Tokens zu kommen. Mit diesen Tokens könnt ihr beliebig auf euer Seite posten, Statistiken abfragen usw. – und an diesen Token kommt ihr so:

  1. Zunächst müsst ihr Admin der gewünschten Fan Page sein
  2. erstellt eine Facebook App – natürlich mit dem gleichen User, der auch Admin der Seite ist.
  3. kopiert in den Einstellungen der App die App-ID sowie das App Secret
  4. öffnet den Facebook Graph API Explorer
  5. oben rechts ist ein Dropdown, in dem ihr die eben erstellte App auswählt (anfänglich steht da “Graph API Explorer” drin)
  6. nun klickt ihr auf das “Get Token”-Dropdown und wählt da “Get User Access Token” – dabei ist es wichtig, dass ihr in der nun erscheinenden Übersicht das Häkchen bei “manage_pages” setzt
  7. kopiert nun den kurzfristigen Token aus dem Textfeld in der Mitte und ruft folgende URL auf:
    https://graph.facebook.com/oauth/access_token?client_id=[APP_ID]&client_secret=[APP_SECRET]&grant_type=fb_exchange_token&fb_exchange_token=[TOKEN]
  8. kopiert euch den nun angezeigten langfristigen Token (LONG_LIVING_TOKEN, 60 Tage gültig)
  9. ruft nun die folgende URL auf:

    https://graph.facebook.com/me/accounts?access_token=[LONG_LIVING_TOKEN]

  10. in dem nun erscheinenden JSON seht ihr alle von euch verwalteten Seiten sowie deren unendlich lang gültigen Tokens für die verwendete App

Zur Überprüfung ruft ihr einfach das Access Token Debug Tool auf: 

https://developers.facebook.com/tools/debug/accesstoken

Hier könnt ihr den Token eintragen und bekommt dann Informationen darüber – und eben auch die Gültigkeit.

Link
PHPUGFFMDie UG trifft sich zum 5. Mal in 2016 (3.11.2016, 06:30 UTC)

Am 17. November dürfen wir wieder zu Gast bei solvians sein. Diesmal geht es um die Gesundheit im Programmiereralltag und um einen vergleichsweise neuen Ansatz bei der DependencyInjection.

Mehr Infos – und die Möglichkeiten deinen Platz zu reservieren – findest du auf der Veranstaltungsseite oder bei joind.in.


We will be guests at solvians on the 17th of November.

This time we’ll be talking about health in a programmers everyday routine as well as a rather new way of handling DependencyInjection.

Find more informations – as well as the possibility to RSVP – on the eventpage or at joind.in.

Link
Webdesign und TYPO3 Blog aus DuisburgTYPO3 Seiten mit Extensions Plugin suchen PID (30.10.2016, 18:45 UTC)

Das Open Source CMS TYPO3 ist weit verbreitet und hat in den letzten Jahren auch von den Versionen einen großen Schritt nach vorne gemacht. Legacy Code und veraltete Versionen der eingesetzten Software stellen allerdings leider eine große Herausforderung in der so schon sehr angespannten Welt des Webdesigns dar. Naben dem Update der eigentlichen CMS Version müssen allerdings auch immer wieder alle Extensions aktualisiert werden. Bei eigenen Extensions stellt das zum Teil eine sehr große Herausforderung dar.

TYPO3 Extensions im Pagetree suchen

TYPO3 Seiten mit Extensions Plugin suchen PID

TYPO3-Seiten-mit-Extensions-Plugin-suchen-PID

Es gibt unterschiedliche Wege sich die PIDs zu den eingesetzten TYPO3 Extensions anzeigen zu lassen. Tatsächlich gibt es genau für diesen Zweck auch wieder Extensions. Aber jede installierte Extension bedeutet auch immer mehr Aufwand, eine mögliche Sicherheitslücke in TYPO3 und in Zukunft auch immer mehr Arbeit. Von daher sollte man immer den einfachsten Weg wählen und der geht ganz einfach über die Datenbank.

TYPO3 Seiten mit Extension in Datenbank finden

Folgendes SQL-Statement kann einfach auf der Datenbank ausgeführt werden:

SELECT tt_content.pid,pages.title
FROM tt_content JOIN pages ON tt_content.pid = pages.uid
WHERE tt_content.list_type LIKE '%extensionkey%'
ORDER BY tt_content.uid DESC

Mit dem oben abgebildeten TYPO3 SQL Statement kann man ganz gezielt nach einem TYPO3 Extension Key suchen.

TYPO3 alle Seiten mit Extensions finden

Neben der Möglichkeit eine Extension zu suchen, ist es vielleicht auch wichtig alle eingesetzten Extension und ihre PIDs als Übersicht zu sehen. Das kann man auch einfach mit einem entsprechenden SQL Statement ausführen

SELECT tt_content.pid,pages.title
FROM tt_content JOIN pages ON tt_content.pid = pages.uid
WHERE tt_content.list_type <> ''
ORDER BY tt_content.list_type ASC

 

Der TYPO3 Webdesign Blog TYPO3 Seiten mit Extensions Plugin suchen PID erschien zuerst auf Webdesign und TYPO3 Blog aus Duisburg.

Link
Coding – byteludeWie lade ich in Django 1.10 ein Bild von der Festplatte per Django Command hoch? (9.10.2016, 18:00 UTC)

Für den Fall, dass man ein Bild in eine Django Applikation uploaden möchte, gibt es unzählige Tutorials – kniffelig wird es dann ein bisschen, wenn man ein Bild von der Festplatte des Servers, auf dem die Applikation läuft, mittels Django Command hochladen möchte. In meinem Beispiel importiere ich Bilder per Cronjob aus einem anderen Programm. Bisher ging der Upload auch ohne Probleme, aber seit Django 1.9 oder 1.10 wurde das Sicherheitskonzept geändert – man darf keine Dateien mehr ausserhalb des Media_Path Kontextes hochladen (Suspicious File Operation. Um das Problem zu umgehen, muss man das “normale” Fileobject, welches man normalerweise dann an das Model übergeben würde, in den Django File Wrapper packen. Dazu importiert ihr diesen Wrapper wie im Beispiel unten, übergebt den realen Pfad zum Bild und, und das ist nun wichtig, übergebt per “name” Parameter einen beliebigen Dateinamen, mit dem diese Datei dann im “Upload Prozess” von Django ankommt. Nun müsst ihr das “image” Objekt einfach nur an den Image Parameter eures Models hängen, und schon klappt das Einspielen der Datei wieder. Bei mir war es tatsächlich der fehlende “name” Parameter, der mich in die Verzweiflung getrieben hat

from django.core.files import File
image = File(open("[PATH_TO_REAL_FILE]", "rb"), name="[SOME_FILE_NAME]")

Link
LinksRSS 0.92   RDF 1.
RSS 2.0 Feed   RDF 1.
100% Planet PHP   PHP5 powered
PEAR powered  
Code wird von Planet-PHP zur Verfügung gestellt. Vielen Dank.