PHP rocks! wünscht allen Mitgliedern einen guten Rutsch ins neue Jahr 2017 !!!
Hinweis: Das Forum zieht um! Um keine Datenverluste zu haben, schalten wir zwecks Übernahme der Daten das Forum am Sonntag, den 24.04.2016 um ca. 21:00 Uhr offline und passen anschliessend die DNS-Einträge an.
www.php-rocks.de wird euch dann nach den Aktualisierungen der DNS-Server wieder wie gewohnt uneingeschränkt zur Verfügung stehen.
Danke für euer Verständnis!

Hallo, Gast
Du musst dich registrieren bevor du auf unserer Seite Beiträge schreiben kannst.

Benutzername/E-Mail:
  

Passwort
  





Durchsuche Foren

(Erweiterte Suche)

Foren-Statistiken
» Mitglieder: 296
» Neuestes Mitglied: as852163
» Foren-Themen: 338
» Foren-Beiträge: 1.063

Komplettstatistiken

Aktive Themen
ETFE ethylene tetrafluoro...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
COVID-19 IgG/IgM antibody...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
spiral duct forming machi...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
Cable Tray Roll Forming M...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
Pharmaceutical Intermedia...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 0
Fire-Rated Metal Door
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
Aluminum Alloy 8011 Foil ...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
Fiberglass Tissue
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
Razor Power Rider 360 Ele...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1
The 6 Most Popular Insula...
Forum: PHP Basics
Letzter Beitrag: as852163
Vor 2 Stunden
» Antworten: 0
» Ansichten: 1

 
  nginx url rewrite
Geschrieben von: Arne Drews - 11.08.2015, 23:03 - Forum: Webserver - Antworten (8)

Hallo,

In Bezug auf diesen Thread möchte ich das ganze auch auf nginx lauffähig haben.

Dazu benötige ich ein gutes Tutorial über die Rewrite-Möglichkeiten von nginx.
Die Doku hilft mir so nicht wirklich weiter, da sie auf diesen Fall bspw. nicht eingeht:

Code:
RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^ index.php [QSA,L]
Vielleicht ist es auch so simpel, daß ich es nicht rauslese, dennoch würde ich gerne ein gutes Tutorial dazu durcharbeiten, falls jemand eins kennt.

Danke für Infos
Arne


EDIT:
Ich habe eben diesen Converter gefunden, der mir folgendes konvertiert:
Code:
location / {
   if (!-e $request_filename) {
       rewrite ^(.*)$ /index.php break;
   }
}
Sieht für mich zwar logisch und nachvollziehbar aus, aber falls jemand wie gesagt gute Tutorials kennt, wie man selbst auf dieses Konstrukt kommen kann, wäre ich weiterhin dankbar.

Drucke diesen Beitrag

  Name für neue Board-Software
Geschrieben von: Arne Drews - 10.08.2015, 00:58 - Forum: Off Topic - Antworten (11)

Hallo an alle,

Im Zuge des Aufbau dieses Forum und der Neuauflage von php.de, habe ich einige Ideen gesammelt, die ich derzeit an einer eigenen Board-Software umsetze.
Die Board-Software soll die auf php-rocks.de zugrunde liegende MyBB-Software ablösen und dann ständig erweitert/angepasst werden.

Was ich derzeit suche, ist ein guter Name für eine solche Board-Software.

Das Board steht auf folgenden Eckpfeilern:

  • reines html5/css3*
  • responsive fähig
  • Twig basierend
  • PHP v5.4+ erforderlich
  • MySQL 5.6+ / pgSQL 9.4**
* Browser-Inkompatiblitäten werden tlw. durch Einsatz von JS-Frameworks korrigiert, nicht aber als primäre Zielsetzung betrachtet!
** auswählbar bei der Installation, pgSQL-Unterstützung ist derzeit allerdings noch experimentell.

Das Layout ist in Objekte aufgeteilt, die auf jeweils eigene Controller zurückgreifen. Damit wollte ich maximale Anpassbar-/Erweiterbarkeit erreichen, ohne mit anderen Elementen zu kollidieren.

Das erstmal nur als Grundinformation, ich denke, daß ich das beim aktuellen Stand in einigen Wochen schon mal als Test-Installation zur Verfügung stellen werde.
Das werde ich hier dann auch ankündigen und hoffe auf freiwillige Tester für konstruktives Feedback.

Was derzeit - wie angesprochen - fehlt, ist eine einprägsame Bezeichnung.
Eine Auswahl meiner Schnellschüsse:
  • mycb.de ( MyCommunityBoard )
  • xcb.de ( ExtendedCommunityBoard )
  • xboard.de / x-board.de ( ExtendedBoard )
  • fireboard.de / fire-board.de
  • u.a.
Aber bei allen existiert bereits eine Domain.
Wer bessere Ideen für Bezeichnung und/oder Domain hat, darf dies gern hier mitteilen.

Ich bin dankbar für jeden ernst gemeinten Vorschlag.

Danke
Arne

Drucke diesen Beitrag

  mail tutorial mit swiftmailer
Geschrieben von: HaJa - 09.07.2015, 21:00 - Forum: PHP Basics - Antworten (4)

hallo,

ich weiss nicht ob ich hier überhaupt antwort bekomme aber versuche es mal.
bei google habe ich das tutorial hier gefunden http://www.php-rocks.de/thema/51-html-mail-versenden-mit-phpmailer.html und hab das auch erfolgreich umsetzen können.
soweit cool. ein kolege von mir meinte allerdings das er swiftmailer besser findet. also wollte ich das mal ausprobieren.
die erklärungen auf der herstellerseite verstehe ich aber ehrlich gesagt nicht ganz und scheitere daran.
habt ihr dazu auch ein tutorial?

danke schon mal
Hannes

Drucke diesen Beitrag

  undefined index: var in ... on line
Geschrieben von: Arne Drews - 26.06.2015, 00:50 - Forum: Fehler, Warnungen und Hinweise - Keine Antworten

Notice: undefined index: var in ...


Häufige Notice bei Verwendung von Formularen


Was ist passiert?
Diese Notice tritt auf in Verwendung eines Array, auf dessen Schlüssel wir zugreifen möchten, der nicht existiert.
In vielen Fällen handelt es sich zwar einfach nur um einen Tippfehler des Schlüsselnamens, aber auch bei Verwendung eines Formulares erhalten viele Einsteiger diese Notice.

Um das nachzustellen, schauen wir uns das folgende minimale "Affen"-Formular an:
PHP-Code:
<?php

echo $_POST['sometext'];

?>
<form name="test" action="" method="post">
    <input type="text" name="sometext" value="" />
    <input type="submit" name="submitted" value="absenden" />
</form> 
Die Fortgeschrittenen unter euch erkennen auf den ersten Blick, was hier passiert. Der erste Aufruf der Seite wirft die beschriebene Notice:
Zitat:Notice: Undefined index: sometext in /var/www/vhosts/php-rocks.de/httpdocs/.../....php on line 3

Um das Problem zu beheben, müssen wir einfach nur abfragen, ob das Formular überhaupt gesendet wurde, bzw. Daten im POST-Kanal vorhanden sind.
Dazu bedienen wir uns - um nicht bei der Abfrage eine ähnliche Notice zu erhalten - der Funktion isset():
PHP-Code:
if ( isset($_POST['submitted']) ) {

 
   echo $_POST['sometext'];


Wenn wir nun keinen Tippfehler gemacht haben, sind wir die ungewünschte Notice los und auch der erste jungfräuliche Aufruf der Seite wird nicht mit einer Notice bestraft.


POST und GET
Häufig tritt dieses Problem auch auf, wenn Formulare bspw. per POST übertragen werden, man aber versucht die Daten aus $_GET zu bekommen.
Dies ist einer der ersten Punkte, die man prüfen sollte, wenn der Fehler in Verbindung mit einem Formular auftritt.


Hinweis

Dies sind nur zwei von vielen Ursachen für eine Notice dieser Art. Erhält man eine solche Notice, kann man also i.d.R. davon ausgehen, daß man einen Vertipper in einem Array-Schlüssel hat oder über einen falschen Kanal auf Formulardaten zurückgreifen möchte.

Drucke diesen Beitrag

  Cannot add/modify header information - headers already sent
Geschrieben von: Arne Drews - 24.06.2015, 00:43 - Forum: Fehler, Warnungen und Hinweise - Keine Antworten

Warning: Cannot add/modify header information - headers already sent


Ein Klassiker unter den unverhofften PHP-Warnungen.

Was ist passiert?
Diese Warnung tritt i.d.R. auf, wenn versucht wird, den HTTP-Header zu modifizieren, nachdem bereits Dokumenten bezogene Inhalte an den Browser gesendet wurden.
Oft fällt einem dies im ersten Moment gar nicht mal auf, denn die Ursache für die Warnung ist vielfältiger, als manch einer denkt.

Um das prinzipiell verständlich zu machen, stellen wir das Problem auf einfachste Weise mal nach:
PHP-Code:
.<?php
header 
'Content-Type: text/html; Charset=utf-8;' ); 
Der Punkt vor dem <?php soll hier mal ein einfaches Leerzeichen darstellen ( gibt der Editor leider bzw. Gott sei dank nicht her, daher als Beispiel der Punkt ), also für einen unerfahrenen User kaum als wirkliche Ausgabe zu erkennen.
Dennoch ist dies eine Zeichen bereits eine Ausgabe, die an den Browser gesendet wird. Und genau dies kann der folgenden Funktion header(...); zum Verhängnis werden, denn die kann den HTTP-Header nicht mehr verändern, da die Ausgabe bereits einen eigenen HTTP-Header gesendet hat.

Das Problem tritt also tatsächlich nicht nur bei der Verwendung von header() auf, sondern bei allen Funktionen, die den HTTP-Header modifizieren.
Folgende häufig verwendete PHP-Funktionen zählen u.a. zu diesen:
  • header()
  • session_start()
  • session_regenerate_id()
  • setcookie()
  • setrawcookie()
Jetzt wissen wir, wo das Problem liegt und entfernen mühsam alle Ausgaben, die sich vor diesen Funktionen eingeschlichen haben.
Doch PHP bleibt beharrlich und meldet weiterhin dieselbe Warnung?! Der Grund dafür ist mit hoher Wahrscheinlichkeit dann...

Die Unicode-Falle
Die Verwendung von Unicode - allen voran UTF8 - ist heutzutage Quasi-Standard, wenn es bspw. um CharsetEncoding von Webprojekten geht.
Viele Editoren oder IDE's speichern die Daten im UTF8-Modus. Genau hier muß man aber aufpassen, daß man nicht nur UTF8, sondern UTF8 ohne BOM ( ByteOrderMark ) verwendet!

Das ByteOrderMark ist eine Kennung für die Unicode-Kodierung, die den Datenstrom einleitet und im Falle von UTF8 aus der Bytesequenz EF BB BF besteht.
Das wird in Browsern häufig als  interpretiert und ausgegeben ( im Quelltext des Browsers erkennbar ).

Daher Dateien immer UTF8 ohne BOM speichern!

Hinweis
Output Buffering kann das hier beschriebene Problem zwar in manchen Fällen umgehen, behebt dieses aber nicht! Eine saubere Programmierung ist immer die beste Fehlerbehandlung.

Drucke diesen Beitrag

  Welchen Sinn hat eval() im Templating?
Geschrieben von: Arne Drews - 10.06.2015, 08:29 - Forum: PHP Basics - Antworten (5)

Hallo,

Mich stört ja schon von Anfang an, daß im Templating eval() benutzt wird.
Zwar werden damit keine Benutzereingaben ausgewertet, aber ich selbst habe eval() immer gemieden und kann mich auch heute nicht wirklich damit anfreunden.

Wenn ich folgende Zeilen sehe:

PHP-Code:
eval('$index = "'.$templates->get('index').'";'); 
ist das auf den ersten Blick für mich dasselbe, wie das hier:
PHP-Code:
$index $templates->get'index' ); 
, denn in beiden Fällen sollte $templates->get( 'index' ); ausgeführt werden.

Scheinbar wird aber im zweiten Fall das index-Template nicht geparst, Ausgabe ( gekürzt ):
Code:
{$header}
...
{$footer}

Warum ist das so?
Ich würde eval() gerne ersetzen, müsste dazu aber erstmal wissen, was die beiden Zeilen unterscheidet.
Vielleicht hat ja jemand einen geistigen Anstoß für mich?

Danke

Drucke diesen Beitrag

  Thema "erledigt"-Funktion implementiert
Geschrieben von: Arne Drews - 08.06.2015, 16:46 - Forum: Off Topic - Keine Antworten

Ab sofort kann die Thema-Erledigt Funktion genutzt werden, um ein Thema als erledigt oder unerledigt zu kennzeichnen.
Berechtigt dazu sind neben dem Thread-Ersteller Administratoren und Moderatoren.

Visuell stellt sich das in der Thread-Ansicht so dar:
[Bild: http://www.php-rocks.de/uploads/thema-erledigt-thread-ansicht.jpg]

und in der Foren-Übersicht so:
[Bild: http://www.php-rocks.de/uploads/thema-erledigt-forum-ansicht.jpg]

Drucke diesen Beitrag

  Blog gestartet
Geschrieben von: Arne Drews - 30.05.2015, 01:59 - Forum: Off Topic - Antworten (2)

Hallo zusammen,

Ich habe für www.php-rocks.de einen Blog angelegt: http://php-rocks-kb.blogspot.de/.
Da werde ich - so wie es die Zeit und mein Wissen zulassen - in der nächsten Zeit immer mal wieder kurze Tipps, Infos oder Anleitungen posten.

Da einige von euch immer wieder mal hier vorbei schauen, würde ich mich freuen, euch auch dort zwischendurch anzutreffen.
Sollten Interessierte aus der Community Interesse haben dort auch was zu posten, bitte mich für Details per PN anschreiben.

Auf gutes Gelingen und "Gut Blog...", würde ich mal sagen...
Wink

Drucke diesen Beitrag

  Subselect mit AND verknüpfter Bedingung liefert mehr Datensätze als erwartet
Geschrieben von: Arne Drews - 22.05.2015, 16:17 - Forum: Andere SQL Datenbanken - Antworten (2)

Hallo,

Ich poste mal zu Beginn die Query, damit ihr wisst, worum es geht:

Code:
select
lieferscheine.* -- der Kürze halber

from
VKBelege lieferscheine

where
lieferscheine.Belegkennzeichen = 'VLL'
and lieferscheine.BelID not in ( select ReferenzBelID from VKBelege where ReferenzBelID is not null and Belegkennzeichen = 'VFR' )

order by
lieferscheine.Belegdatum desc
Ich suche quasi alle Lieferscheine, zu denen scheinbar noch keine Rechnungen erstellt wurden. Das Belegkennzeichen VLL steht für die Lieferscheine, VFR für Rechnungen.
Jeder Beleg, egal ob Lieferschein oder Rechnung hat eine eindeutige BelID. Für den Fall, daß aus einem Lieferschein bereits eine Rechnung erstellt wurde, gibt es die ReferenzBelID in der Rechnung, die der BelID des Lieferscheins entspricht.

Die Logik ist damit klar:
Code:
Selektiere alle Lieferscheine, deren BelegID in keiner ReferenzID der Rechnungen vorhanden ist.

Was mich ein wenig aus dem Konzept bringt:
So wie oben im Code, bekomme ich 796 Datensätze.
Wenn ich in dem Subselect das and Belegekennzeichen = 'VFR' entferne, bekomme ich nur noch 264 Datensätze.

Warum bekomme ich denn mehr Datensätze, wenn ich die Ergebnismenge des Subselects weiter eingrenze?

Da habe ich ein kleines Verständnis-Problem und freue mich auf erleuchtende Hinweise.
Undecided

Drucke diesen Beitrag

  ...und mal wieder ohne Vorankündigung :-)
Geschrieben von: Arne Drews - 18.05.2015, 14:09 - Forum: Off Topic - Antworten (2)

[Bild: http://www.php-rocks.de/uploads/phpde.jpg]

Drucke diesen Beitrag