Volg het kruimelpad, waar komt $this->dbh vandaan?
En wat @Luc zegt, alle mysql_* functies zijn vanaf PHP versie 7 foetsie. Dus zorg ervoor dat je je schapen op het droge hebt voordat je versie gebumpt wordt.
Het feit dat je gebruik maakt van mysql_* functies lijkt mij trouwens een groter probleem dan die ene instantie waarin een query niet werkt, tenzij er geen enkele query werkt op die website?
Het probleem zit em waarschijnlijk in het feit dat de namen van de radio-velden niet dynamisch zijn, zie mijn vorige reactie.
maar in de if komt altijd alleen de laatste erdoor.
Waar blijkt dit uit? Zit er mogelijk een fout in die code? En er kan er maximaal ook maar "een doorkomen", het betreft immers een radiobutton? Het is sowieso vreemd dat je meerdere radiobuttons met dezelfde naam kunt checken, dit is geen standaard gedrag?
Misschien als je de naam "options" verandert in options[<id van de huidige rij>], anders overschrijf je alles elke rij opnieuw :p.
Weet niet hoe actueel of relevant dit nog is maar in Nederland is er zoiets als een branchevereniging waar digitale bureaus zich aan kunnen sluiten. Mogelijk bestaat er ook zoiets in België?
Je zegt:
een volledige site met alles er op en er aan kan laten maken
Maar is dit echt heel erg veel maatwerk, of zou dit ook voor een groot deel onder standaard functionaliteit van een willekeurig CMS kunnen vallen? Dit kan het verschil betekenen tussen gebruikmaking van iets wat from scratch gebouwd is of het inbouwen van een design en enkele maatwerkmodules (of zelfs het inzetten van een aantal standaard modules) in, ik noem maar wat, een WordPress site. De gekozen oplossing/aanpak bepaalt sterk het kostenplaatje.
Ik denk dat je, nog voordat je naar een bureau stapt, een vrij goed beeld moet hebben van wat je wilt. Uiteraard kan een bureau helpen met verdere conceptvorming en/of uitwerking maar het lijkt mij handig als je al een globale koers hebt uitgestippeld. Een bureau kan je vervolgens informeren over de mogelijkheden.
Dit is een interessant en nuttig concept (zelfs met reclamebanners I suppose :p). Vroegah hadden wij ook zoiets: SAIS (Stage en Afstudeer Informatie Systeem). Dit was intern via de opleiding ontstaan (deze site zelf was ook middels een stageopdracht opgezet en later leverde het onderhoud mij ook een stageopdracht op :)).
Hier zat echter nog wel één belangrijke partij bij: de docentbegeleider (en in algemenere zin de opleiding / opleider zelf dus). Deze moest (onder andere) uiteindelijk zijn/haar toestemming geven die aangaf of de opdracht "stage-waardig" was. Met name bij afstudeeropdrachten lag de lat begrijpelijkerwijs vrij hoog.
Daarnaast heb je op een hoger niveau waarschijnlijk ook nog een (algemeen) stage- en afstudeercoördinator. De contactpersonen/partijen waarmee een student rekening moet houden kan natuurlijk per opleiding verschillen. Voorziet jouw systeem hier ook in?
Ook kan ik mij voorstellen dat je e.e.a. wilt organiseren per opleiding (hogeschool, universiteit etc.), zo kun je namelijk een aantal zaken stroomlijnen. Stel je doet een opleiding communicatie dan ben je waarschijnlijk niet echt geïnteresseerd in IT-stageplaatsen en andersom. Ook zouden studenten zoekprofielen kunnen aanmaken (als dat er al niet in zit).
Je kunt dus bedrijven benaderen (vraag) maar wellicht ook scholen en universiteiten (aanbod). Ik denk dat deze laatste partij zeker op een of andere manier een plekje verdient in dit systeem.
Maar ergens moet er een soort van gebruiker-interactie zijn zodat deze kan aangeven "nu wil ik iets opslaan". En het zou wel zo netjes zijn dat de gebruiker ook een soort van terugkoppeling krijgt dat de informatie is verstuurd.
(tenzij je een soort keylogger probeert te bouwen uiteraard :p)
Bij gebruikmaking van een AJAX-call wordt er in de achtergrond overigens nog steeds informatie "gesubmit" via een GET of POST request.
Kun je een concrete toepassing of voorbeeld geven van gebruik? Wat probeer je te bouwen?
EDIT: en waarom zou je dit willen opslaan naar HTML? Dit is redelijk ongestructureerd in die zin dat het veel moeite zou kosten om de informatie weer uit de pagina te vissen.
Ah, online privacy. Dat is net zo'n populair stopwoord als "First Amendment" voor Amerikanen, maar als je dan doorvraagt wat dat precies betekent kijken ze je soms glazig aan.
Wat versta je precies onder online privacy? En waarom is dit zo belangrijk? Wat kan er allemaal misgaan en hoe kun je dit voorkomen?
Ik denk dat je al een heel eind komt als je gewoon je gezond verstand gebruikt en niet zomaar overal persoonlijke informatie achterlaat.
Ook verzanden dit soort threads al snel in conspiracy-theory-verhalen waarbij de Grote Boze Bedrijven er op uit zijn om de Gewone Man te naaien. Maar vaak is het gewoon stupiditeit of het slordig omspringen met gegevens wat voor problemen zorgt.
De afbeelding zal voor jou (na correctie) wel zichtbaar zijn, maar als je dit footer-bestand upload waarbij die hyperlink letterlijk "localhost" bevat dan ziet de rest van de wereld dit uiteraard niet omdat hun "localhost" geen lokale webserver heeft die zo'n afbeelding bevat, laat staan een lokale webserver actief heeft in de meeste gevallen.
Beter is dus om of de hyperlink relatief te maken of dynamisch op te bouwen met behulp van functies van WordPress zelf. Als dit laatste nu al gebeurt hoef je niets aan te passen uiteraard (behalve de spellingsfout).
Is er een reden waarom je dit niet webbased doet, of een bestaand ticketsysteem gebruikt, for that matter?
Ik heb een déjà vu. Zeer recent is er een soortgelijk topic geplaatst.
Een horizontale overflow in codeblokken, zodat code er niet uitziet als een treinbotsing.
Denk dat ik, als er geen makkelijk manier is, maar erbij vermeld dat op shared servers gegevens
niet kloppeneen benadering zijn.
Je zou dit kunnen benaderen door een optelsom te maken van wat je hebt (web, mail, db)? En dit uit te zetten tegen de ruimte die je tot je beschikking hebt volgens je account? Mogelijk nemen andere zaken ook ruimte in.
Je zou aan jouw host kunnen vragen hoe zij dit bepalen. Misschien heeft iedereen een aparte user waar je iets uit af kunt leiden of wellicht via quotas?
Waarvoor is een indicatie van het gebruik uberhaupt nodig/interessant?
Waarom redirect je niet alles naar index.php? Daar inspecteer je vervolgens $_SERVER['REQUEST_URI']. Je hebt dan geen rewriterules nodig en je kunt de routing van je applicatie afhandelen in PHP(-code).
Daar zou je eerst de pagina/actie kunnen uitvoeren (en alle output op kunnen vangen in een buffer) en kunnen kijken of iemand die pagina uberhaupt op mag roepen. Bij deze pagina betrek je vervolgens het juiste maintemplate (en geef je de informatie in de buffer weer tezamen met het maintemplate).
Op het moment dat je met routing (de navigatie door je applicatie) bezig bent komen er echter een heleboel dingen samen. Wanneer de opzet, indeling en opbouw van pagina's en de bijbehorende acties vastligt wordt het heel lastig om hier vervolgens nog in te schuiven omdat je inmiddels een aantal onderlinge afhankelijkheden hebt die niet echt omgegooid kunnen worden. Daarom is het zaak dat je heel goed nadenkt over de opbouw van dit alles.
Desalniettemin: vergeet niet je output te escapen :). Wie weet wat men in sessies stopt.
Jouw script leest alleen de bestand(snam)en uit, niet de inhoud. Daar kun je dus moeilijk uit afleiden of sessies van andere sites in de (een mogelijk gezamenlijke) sessie-directory staan opgeslagen.
Als ik die probeer te bereiken krijg ik "Permission denied" dus dat lijkt wel snor. Maar weet niet of er meer een mogelijkheid is dat verder te testen.
Je bedoelt via FTP? Probeer het eens via een PHP-script ^^.
<?php
header('Content-Type: text/html; charset=UTF-8');
error_reporting(E_ALL);
ini_set('display_errors', 'stdout');
// don't be bad, escape output
function escape($in) {
return htmlspecialchars($in, ENT_QUOTES, 'UTF-8');
}
$dir = session_save_path();
if ($handle = opendir($dir)) {
?><h1>reading <?php echo escape($dir) ?></h1><?php
?><table border="1" width="100%">
<tr><th>file</th><th>contents</th></tr><?php
while (false !== ($file = readdir($handle))) {
if (!in_array($file, array('.', '..'))) {
$path = $dir.DIRECTORY_SEPARATOR.$file;
?><tr><td><?php echo escape($file) ?></td><td><?php
if (is_dir($path)) {
?>is a directory<?php
} else {
// note: probably not suited for large files
if (false !== ($content = file_get_contents($path))) {
echo escape($content);
} else {
?>[error] could not read file<?php
}
}
?></td></tr><?php
}
}
closedir($handle);
?></table><?php
} else {
?>[error] could not read dir<?php
}
?>[end]Op zich is dit een mogelijke aanpak: je hebt twee "maintemplates" waarin je ingelogde en niet-ingelogde gebruikers scheidt?
Het alternatief, waar jij volgens mij op aanstuurt, is een constructie met één maintemplate waarin je (keer op keer) op grond van het wel of niet ingelogd zijn bepaalt wat je weergeeft.
Voor beide aanpakken is iets te zeggen. Afhankelijk van hoeveel de niet-ingelogde en wel-ingelogde variant verschillen is het verstandiger om voor een specifieke aanpak te kiezen.
Voordeel van het scheiden van de templates is dat deze een compleet verschillende opbouw kunnen hebben.
Hm even googlen op dit onderwerp (aflopend terugkerend evenement) levert een hoop resultaten op waarbij het blijkbaar nog steeds problematisch is om een eind te breien aan permanent terugkerende afspraken (waarbij ALLE historie wordt verwijderd, en niet alleen de uitstaande afspraken in de toekomst).
Misschien is het nog het beste om eens in de zoveel tijd een batch afspraken in te plannen, bijvoorbeeld via een import via CSV. Tis wat meer handwerk maar het bespaart je de ellende van een geautomatiseerde oplossing die niet precies doet wat je wilt.
En voor dit doel zou je een tooltje kunnen schrijven (als je dit vaak doet) die de datums kiest (jQuery datepicker) en via code (PHP) een CSV bakt.
Ik ging er min of meer vanuit dat je beide wilt? Automatisch bij het laden van de pagina, op afroep bij het klikken op de save-knop? Dat zou dan zoiets worden?
<script type="text/javascript">
//<![CDATA[
function saveImage() {
// moved if statement to function
if ($("#image-canvas").length > 0) {
$("#image-canvas").height($($(this).attr('data-print-area')).height());
$("#image-canvas").width($($(this).attr('data-print-area')).width());
$($(this).attr('data-print-area')).html2canvas({
onrendered: function (canvas) {
var formdata = {
image_code:canvas.toDataURL('image/png')
};
// console.log(formdata);
$.post('screenshot/saveimage.php', formdata, function(msg) {
console.log(msg);
window.location.href = msg;
});
}
});
} else {
// @todo maybe some feedback here like "can't save image"?
}
} // function saveImage
$(document).ready(function() {
// save image on load
saveImage();
// save image on click
$(".save-image").on('click', function() {
saveImage();
});
});
//]]>
</script>Als je het onclick gedeelte weg wilt hebben haal je gewoon het on click blok weg. Ik geloof dat alle haken goed staan maar je moet maar even kijken.
Overigens als $(document).ready() niet werkt kun je overwegen om $(window).load() te gebruiken om de code pas effectief te maken als alle objecten, frames en afbeeldingen op de pagina zelf zijn geladen zoals hier staat uitgelegd.