Formulier-elementen (in HTML) ondersteunen array-constructies door rechte haken toe te voegen aan een veldnaam:

<input type="text" name="regel[]" />

Dit soort velden kun je knippen en plakken met JavaScript (waarschijnlijk bedoelde je dat of jQuery in plaats van JSON, ik zie niet helemaal hoe JSON hier bij past?).

Als je vervolgens een regel opslaat en daarna weer wilt bewerken in eenzelfde soort dynamisch formulier zou je kunnen overwegen om een referentie (het volgnummer / het auto-increment veld) mee te geven aan dit veld:

<input type="text" name="regel[41]" value="eerder ingevoerde waarde" />

Wel zul je iets moeten verzinnen om het onderscheid te maken tussen bestaande regels en nieuwe regels.

Wat je ook nog zou kunnen doen (en wellicht stukken makkelijker is) is het volgende: deze regels zijn gekoppeld aan een overkoepelend iets (een factuur, een order, whatever). Wanneer je al deze data update doe je het volgende bij verwerking van het formulier:

• je verwijdert alle bestaande items die gekoppeld zijn aan de factuur, en
• je voegt ze opnieuw toe

Dus je gebruikt deze als een koppeltabel tussen je orderregels en je orders, je hoeft dan geen moeilijke inspecties te doen maar kiepert gewoon alles weg en voegt alles (en mogelijk meer) opnieuw toe.

Dit alles zou wel in één ondeelbare actie moeten. Dit kun je doen met database-transacties. Je moet er dan wel voor zorgen dat de ENGINE die je tabellen gebruiken deze bewerkingen ondersteunen.

In zijn algemeenheid is het ook wel handig dat als je een grote administratief-achtige database hebt dat deze echt relationeel is opgezet. Tabellen hebben dan echt onderlinge verbanden en relaties middels foreign keys.

Indien deze database(tabellen) niet de InnoDB engine hebben, zou ik daar eerst eens mee aan de slag gaan.

De database vormt het fundament van je applicatie. Als deze niet goed is, hoef je ook niet veel van je applicatie te verwachten.

EDIT: over PDF: dit lijkt mij echt een aparte zijstraat en die zou ik gewoon apart behandelen. Je zou bij het ontwerp van dit ding wel in je achterhoofd kunnen houden dat dit op ening moment ook in PDF-vorm gebruikt moet worden. Daarbij is het volgens mij ook (bij facturatie dan) belangrijk dat op het moment dat je hier een PDF van maakt en deze naar een klant stuurt dat de bijbehorende data niet meer gewijzigd kan/mag worden.

Hier hoeft niet eens PHP aan te pas te komen, dit kan in (native) JavaScript.

@Ferhat.Remory je wil dus wel bij de default blijven waarbij de chat standaard "open" staat? Je zou het ook om kunnen draaien waarbij de chat standaard geminimaliseerd is, dan hoef je helemaal niets te onthouden?

Leg eerst eens uit wat je wilt bereiken, nog voordat je begint over de gebruikte technologie of programmeertaal.

De klus bepaalt het gereedschap, niet andersom.

Op de Git pagina staat volgens mij een fout in het PHP template:

// Check if the user is logged in, if not no need to be here...
if (LOGGEDIN == FALSE) { header('Location: ' . ROOT_URL . 'index.php'); }


// Your PHP code

Volgens mij is dit een redelijk wijdverbreid misverstand: header('Location: ...') transporteert je niet direct automagisch naar een nieuwe locatie, dit gebeurt pas aan het einde van het script omdat headers onderdeel van output zijn.

Dit is wat er achtereenvolgens gebeurt als LOGGEDIN gelijk is aan FALSE:

1. de Location header wordt ingesteld op ROOT_URL.'index.php'
2. "// Your PHP code" wordt gewoon uitgevoerd
3. je wordt geredirect naar ROOT_URL.'index.php'

Meestal is het de bedoeling dat de uitvoering van code direct gestaakt zou moeten worden na het uitgeven van een header('Location: ...') statement. Daarom is het ook zaak dat dit statement vrijwel altijd gevolgd zou moeten worden door een exit; statement.

Het weglaten van dit exit; statement kan het verschil betekenen tussen een veilige of een onveilige applicatie...

Ik heb de rest van de code nog niet bekeken, maar ik hoop dat hier op andere plaatsen wel in is voorzien.

Omdat je in een applicatie vaak redirect zou je hiervoor een functie kunnen introduceren (inclusief exit, zodat je dit nooit meer vergeet):

function redirect($link) {
    header('HTTP/1.1 303 See Other');
    header('Location: '.$link);
    exit; // so we never forget :)
}

Toevalig kwam hierover recent een topic voorbij op phphulp.nl.

Met een link die verwijst naar de developers website van google.

Mogelijk heb je hier iets aan.

Overigens zal er zoals ik het zie hoe dan ook ergens een proces moeten zijn die de inhoud van je inbox controleert, anders weet je niet over er iets gepusht kan worden.

De enige manier om te controleren of je post hebt is in de brievenbus kijken...

Om nog een aantal zaken uit te sluiten: jouw website (waar naar teruggecommuniceerd moet worden) is ook bereikbaar vanaf het internet?

In de tweede link staat ook iets over het verschil tussen curl_error() en curl_errno(), je zou eens kunnen proberen om de correcte errorcode op te halen met curl_errno(), mogelijk wijst deze je veel nauwkeuriger in de richting van een mogelijke fout.

Heb je al geGoogled op cURL https of errorcode 104?

In het eerste resultaat van de eerste zoekopdracht staat iets over een verouderd bestand dat cURL gebruikt voor het authenticeren van certificaten (dateert weliswaar uit 2008). Er staat wel iets in over het uitzetten van opties als VERIFYPEER. Dit zou je code vatbaar maken voor Man In The Middle attacks.

Het eerste resultaat van de tweede zoekopdracht staat ongeveer hetzelfde geloof ik, met een toevoeging dat je openssl extensie actief moet zijn om dit soort requests te doen.

Dit alles kostte mij minder dan 5 minuten zoekwerk.

EDIT
Dit zou je kunnen gebruiken als startpunt van je zoektocht.

In het eerste resultaat staat ook iets over het aanzetten van redirects (middels FOLLOWLOCATION), dit doet cURL standaard niet. Mogelijk wordt je geredirect als je de initiële URL aanroept?

Citaat van Tredgy

maar op deze manier krijg je geen errors.

In tegenstelling tot wat?

Of je gebruikt recursie.

function recursieveCijferSom(input) {
    input = input.toString();
    var sum = 0;
    for (var i=0; i < input.length; i++) {
        sum += parseInt(input.charAt(i));
    }
    return (sum > 9 ? recursieveCijferSom(sum) : sum);
}

Daarbij is het ook handig dat je begint met de kleinst mogelijke weergave van je site en deze uitbouwt naar hogere resoluties. Dit principe wordt ook wel mobile first (ontwerpen) genoemd.

Google had zelf ook een artikel over de beginselen van responsive design.

Citaat van diestro

Nouja hij kent HTML al, dan is de meest logische stap om naar PHP te gaan lijkt me. Tenzij je je wat meer wilt onderscheiden, dan misschien Ruby on Rails

Actually, een kleine(re) tussenstap zou de stap naar een interactievere site middels (native) JavaScript kunnen zijn.

Citaat van Ferhat.Remory

In welke taal wil je dan programmeren..

Pretty much this.

Dit is zoiets als "Waar kan ik een vreemde (spreek)taal leren".

Citaat van milan khan

Omdat dit bedrijf heel erg uitgebreid zal worden wil ik meteen een hele goede naam hebben.

Dit klinkt een beetje paradoxaal: je wilt het groots aanpakken, maar schakelt geen marketingbureau in ofzo?

Citaat van WMDiensten

Niet geheel waar, als het een geregisterde handelsnaam is kan je hier niet zomaar gebruik van maken en kan de handelsnaam houder het domein opeisen.

Ook zijn er volgens mij gevallen bekend van onteigening van persoonsdomeinnamen. Was daar niet een hele tijd geleden van alles over te doen (Balkenende schiet mij te binnen)?

Citaat van lol

Ze zijn al maanden bezig met de voorbereidingen voor een goederenbank

En registratie van een domeinnaam valt daar niet onder? :/. Sorry hoor, maar dit is het internet. Als er ergens nog redelijk hard gespeeld wordt dan lijkt mij dat de domeinhandel. Zo had ik eens een idee voor een site met bijbehorende naam, maar die was al vergeven en geregistreerd via een bedrijf dat zich had gespecialiseerd in de handel van domeinnamen. Openingsbod 6000 euro of iets dergelijks. LOL.

Om antwoord te geven op je vraag: ook ik ben geen rechtendeskundige: het lijkt mij onwaarschijnlijk dat je dit domein zomaar kwijt bent (en om heel eerlijk te zijn ziet het er allemaal niet zo professioneel uit). Wel kan het verstandig zijn je vast enigszins in te dekken zoals @diestro aangeeft.

Vraag is: wat wil je zelf met dit domein doen? Als verhuren geen optie meer is? Ik denk trouwens dat je meer "problemen" krijgt met content die je had eh... geleend zoals @ThomasBlom zei (als ik het goed begrijp) of het concept wat je op deze manier min of meer kopieert, maar dat is toch een groot grijs gebied.

Begrijp me niet verkeerd, ik denk dat je in zekere zin in je recht staat, maar hoeveel mag dit gelijk jou kosten? Niet zozeer in geld, maar meer in reputatie. Ik bedoel, het moddersmijten is nu in zekere zin al begonnen. Je zou die nieuwssite ook kunnen betichten van smaad ofzo, maar dan heb je nog een "publieke opinie" die mogelijk een eigen draai geeft aan dit alles (en alvast de hooivorken en toortsen in gereedheid aan het brengen is al is op dit moment nog onduidelijk tegen wie deze gebruikt gaan worden).

En dan heb je nog de partij die ineens min of meer het centrum wordt van dit strijdtoneel: de minderbedeelde gezinnen.

Persoonlijk zou ik mij niet op deze manier mengen in deze hele gang van zaken omdat ik niet denk dat ik (als ik de domeinhouder was) het "voordeel van de twijfel" zou krijgen van de betrokken partijen. Je komt er volgens mij op geen enkele manier goed vanaf.

Sell the hot potato and walk away.

Dat is wat ik zou doen, te meer als je verder toch geen concrete plannen hebt om iets met dit domein te gaan doen.

Tenzij je dus een eigen alternatief wilt opstarten waarbij je echt een eigen draai aan dit concept geeft, maar dan moet je dat ook doorzetten.

EDIT: en als het dan komt tot een kort geding of whatever dan zou je ook nog vreselijke pech kunnen hebben met een wereldvreemde rechter die weinig snapt van het reilen en zeilen in de domeinhandel en dan komt het tot een schikking of hoger beroep? Is deze ellende het je allemaal waard, ik zou zeggen van niet.

Meh, als je daarvoor output buffering nodig hebt is er iets mis met de opbouw van je pagina(actie)s.

Lees anders dit artikel eens door :).

-_-

Je bent al bezig met het verzenden van output, en dan wil je cookies instellen? Dat gaat waarschijnlijk niet werken.

Dit zou je kunnen omzeilen met output buffering (wat voorheen mogelijk ingeschakeld stond) maar dat lijkt mij een ongewenste oplossing omdat je eigenlijk je structuur zou moeten rechtbreien.

Allereerst: zet het melden + weergeven van fouten eens aan in het bovengelegen script waarmee je deze pagina include. Voeg hiertoe helemaal aan de start van het script deze regels toe:

<?php
error_reporting(E_ALL);
ini_set('display_errors', 'stdout');
?>

Grote kans dat je nu "headers already sent" foutmeldingen krijgt.
Een nette oplossing voor dat probleem zou het instellen van een cookie in een aparte actie zijn, die verder geen output produceert. Een lelijke oplossing is het (opnieuw) aanzetten van output buffering.

Overigens hoort na een header('Location: ...') altijd een exit te staan.

EDIT: tevens is de enige relevante informatie die je dient te onthouden de theme-naam, dus waarom zou je meer opslaan dan dat?

Citaat van diestro

Je hebt dat laatste probleem al opgelost? Miste namelijk een preventdefault() in.

In native JavaScript kun je dat ook oplossen door de onclick te laten eindigen met "return false".

En als het echt de bedoeling is dat deze popup alleen middels JavaScript te openen valt dan kun je de href gelijk maken aan "javascript:void(0)".

regel 46 wordt gepakt als $_GET['id'] gelijk is aan 1.

Je bereikt in dat geval nooit de elseif op regel 74.

Maar dat had je inmiddels wss ook al gezien.

Het moet trouwens && zijn in plaats van AND op regel 40.
EDIT: AND en && doen niet hetzelfde, deze zijn dus niet vrij uitwisselbaar.

Ook zou ik het melden + weergeven van fouten aanzetten bij ontwikkeling. Je controleert namelijk niet op het bestaan van $_GET variabelen, wat normaal notices zou opleveren.

EDIT: het beste ljikt mij, nogmaals, om deze acties echt van elkaar te isoleren zodat je ze ook echt in afzondering kunt behandelen.

Nee, maar je gaf ook niet aan van waar vandaan je testte, dat had ik beter kunnen vragen.

Dus (om toch even wat dingen uit te sluiten): ben je deze betaalfunctionaliteit aan het testen vanaf een site ergens op het internet?

Wellicht werken de return-url's niet?

Heb je al geprobeerd de cancel_return url aan te roepen vanaf de betaalsite?

Heb je al geprobeerd de urls rechtstreeks aan te roepen op de testsite zelf?