Da's finetuning (en zoals gezegd hangt dat mogelijk ook van schermresolutie af).
Mogelijk kun je het formulier ook wat verder naar onder plaatsen zodat de "helft" over de kaart valt, en de onderste "helft" over de donkerblauwe achtergrond valt ofzo...
Anyhoo, my work here is done :).
In mijn browser (Chrome) werkt dit (het informatievenster wordt direct getoond bij de marker), al valt de marker nog steeds weg achter het contactformulier. Dit (marker achter formulier) kan te maken hebben met de schermresolutie.
Weet je zeker dat je je pagina(cache) goed hebt ververst in je browser? In welke browser bekijk jij jouw site?
Zoals ik het zie zijn er twee dingen die er opgelost moeten worden:
1. De kaart moet niet gecentreerd zijn op de marker (dit is in feite waar de lat en lon coordinaten in combinatie met het zoomniveau voor zorgen), omdat op deze manier de marker achter het formulier valt. Zoals hierboven beschreven staat is het zaak dat je de lat coordinaat (van wat in wezen het verticale centreerpunt van de kaart is) zo kiest dat de marker wel direct zichtbaar is. Dit doe je door het lat coordinaat te verlagen. Dit zorgt ervoor dat de kaart naar het zuiden schuift, en daarmee staat de marker noordelijker.
2. Het informatiekader moet direct getoond worden. Dit zou je misschien op de volgende manier kunnen bereiken:
Vervang op de plek waar nu dit staat:
marker.showInfoWindow();
Deze code door het volgende fragment:
infowindow.open(map, marker);Protocollen (HTTP, HTTPS, FTP et cetera) hebben elk een default poort.
Als je van deze (impliciete) default afwijkt dan zul je het programma dat met dit protocol communiceert expliciet moeten vertellen via welke poort de communicatie dient te verlopen tenzij je in dat programma uitzonderingen kunt definiëren (waarmee je de poort dan dus alsnog expliciet instelt).
Oftewel, het moet op een of andere manier duidelijk zijn.
Daarnaast kan het dus ook zijn dat een protocol een poort voorschrijft. Afhankelijk van het pakket wat je hiervoor gebruikt en/of de speelruimte die het protocol biedt zijn er wellicht mogelijkheden.
En zoals altijd is het handig je te realiseren dat jij waarschijnlijk niet de enige bent met dit probleem, oftewel, heb je al gezocht in documentatie en/of zoekmachines naar alternatieve (poort)configuratie?
Ergens in je HTML-code (map-canvas) of configuratie staat je latitude coordinaat (52.076486). Als je deze verlaagt (naar bijvoorbeeld 52.06) schuift de kaart omlaag, en daarmee gaat je marker omhoog. Dit hangt natuurlijk ook een beetje van je zoomniveau af.
Ik zie dat het infowindow nog steeds niet direct getoond wordt, ondanks de marker.showInfoWindow(); in de code. Dat is wel opmerkelijk, weet zo niet direct waarom dat niet werkt.
Dan zou ik het middelpunt van de kaart die je initieel toont iets naar het zuiden leggen. Dit zou ervoor moeten zorgen dat de kaart wat verder omhoog schuift.
Hm, dat is al anders dan wat ik te zien krijg.
Voordat ik iets doe zie ik dit:
Nadat ik gescrolld en geklikt heb zie ik dit:
De marker valt dus in eerste instantie achter het offerteformulier.
Het bovenstaande heb ik bekeken in Chrome. Wat zou er precies anders moeten gebeuren? Heb je al geprobeerd alle (browser)cache van je pagina weg te gooien?
EDIT: als je in template/js/map-script.js na de volgende regel:
map.setOptions({styles: styles});Het volgende toevoegt:
marker.showInfoWindow();Levert dat misschien al het gewenste effect.
Op welke pagina('s) speelt dit probleem, en hoe zou je dit willen hebben dan? Nu is namelijk dat canvas min of meer een achtergrond-element waar vaak zaken overheen worden weergegeven.
Er zijn opties om een kaart te centreren op grond van coordinaten (dit gebeurt volgens mij al), en het is ook mogelijk om een infowindow direct te tonen. Wat zou je verder omtrent de positionering van het adres willen regelen?
Ik heb geen probleem ik heb een vraag, ik hoef daarvoor geen details te geven over een project. Het gaat om het type opslag en of ik hiermee performance verlies bij meerdere data verwerking.
Zie mijn laatste reply, daarin zit een hoop voorbeeldcode waarmee je wel vooruit kunt denk ik.
Met de reactie daarvoor wilde ik alleen aangeven dat het moeilijk (zo niet onmogelijk) is om een beeld te vormen van een optimale aanpak voor het gevraagde, en ook om de absurditeit van hoe je dit vraagt te benadrukken. Je geeft een enkel puzzelstuk, en verwacht dan dat we kunnen vertellen hoe de hele legpuzzel er uit dient te zien?
Daarna probeer ik die stelling verder te onderbouwen door aan te geven dat de database (wat in feite het fundament vormt voor je applicatie) in dienst staat van de applicatie, en dus hier ook op moet zijn afgestemd.
Als je niet uitlegt hoe de applicatie (technisch) werkt, dan wordt het ook vrij lastig om een database op de goede manier in te richten.
Met mijn "kinderachtige opstelling" hield ik in zekere zin ook een spiegel voor, maar dat is je waarschijnlijk ontgaan. Je het over een "uniek concept" alsof je the next best thing since sliced bread hebt uitgevonden. Als je dan toch op de kip met de gouden eieren denkt te zitten, waarom stap je dan niet naar een bureau om dat concept uit te werken als het je aan technische kennis ontbreekt? Ah, I see.
Dat jij jezelf zo kinderachtig opstelt zegt genoeg over jou, ik weet voldoende stel me vragen voortaan ergens anders.
K bye.
Proof of concept / test.
<?php
ini_set('display_errors', 'stdout');
error_reporting(E_ALL);
header('Content-Type: text/html; charset=UTF-8');
function escape($in) {
return htmlspecialchars($in, ENT_QUOTES, 'UTF-8');
}
// @see http://php.net/manual/en/function.inet-ntop.php#117398
// PHP equivalent of MySQLs INET6_ATON(), because inet_ntop() isn't apparently
/**
* Convert a MySQL binary v4 (4-byte) or v6 (16-byte) IP address to a printable string.
* @param string $ip A binary string containing an IP address, as returned from MySQL's INET6_ATON function
* @return false if not valid.
*/
function inet6_ntop($ip) {
$l = strlen($ip);
if ($l == 4 or $l == 16) {
return inet_ntop(pack('A' . $l, $ip));
}
return false;
}
?>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>IP test</title>
</head>
<body>
<?php
$db = new mysqli('127.0.0.1', 'test', 'test', 'test');
$db->set_charset('utf8mb4');
$db->query("CREATE TABLE IF NOT EXISTS `test_ip` (
`ipt_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`ipt_ip` varbinary(16) NOT NULL,
PRIMARY KEY (`ipt_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4");
// https://www.randomlists.com/ip-addresses
$testIps = array(
'42a6:4dff:28a7:c07d:3a32:97d8:369b:7277',
'dc4c:5486:e:3321:caa3:4b09:6dfa:9f7b',
'e2dc:60f1:43b7:3e3b:a6ad:9423:af5d:68ab',
'fb6e:a7ef:4e3e:75ce:903b:c444:1ebc:babf',
'aaa7:bf2a:b443:9fa9:72ee:67de:d1:8805',
'5894:4879:4a27:dd5a:661c:9906:3ced:5163',
'1eb:d630:692a:4e0f:ac14:4bfe:bc87:92d6',
'68f4:1479:3615:353:f70b:7421:12f1:df62',
'cda0:b4fe:ff76:a8ac:94de:5a91:b1c4:4633',
'7c0a:3f82:5425:3a18:8cfd:8d03:ecb5:f9b1',
'3bf:52c8:b5be:bd43:25c2:43fc:b22d:64e3',
'3218:5c:4250:666b:25d:cb1:f2b0:6774',
'252.228.69.200',
'111.204.105.216',
'182.170.251.175',
'161.210.254.48',
'69.176.138.182',
'200.139.220.243',
'67.95.35.174',
'229.235.136.200',
'151.68.1.236',
'134.112.54.29',
'10.56.42.115',
'203.132.92.142',
);
$db->query('TRUNCATE test_ip');
foreach ($testIps as $ip) {
// unpacked --> packed, store in DB in packed form in VARBINARY(16)
$packedIp = inet_pton($ip); // already compatible with MySQLs INET6_NTOA()
$db->query(
"INSERT INTO test_ip (ipt_ip) VALUES (
'".$db->real_escape_string($packedIp)."'
)"
);
// packed --> unpacked, only for display purposes (human readable form)
$unpackedIp = inet6_ntop($packedIp);
$ok = $ip == $unpackedIp;
echo $ip;
?> <b style="color: #<?php echo ($ok ? '00cc00' : 'cc0000') ?>;"><?php
echo ($ok ? '' : 'NOT ') ?>OK</b><hr><?php
}
$res = $db->query(
'SELECT ipt_ip AS packed,
INET6_NTOA(ipt_ip) AS unpacked
FROM test_ip'
);
while ($row = $res->fetch_assoc()) {
$unpackedInSQL = $row['unpacked'];
$unpackedInPHP = inet6_ntop($row['packed']);
echo ($unpackedInSQL == $unpackedInPHP ? 'ok' : 'NOT ok').'<hr>';
}
?>[end]
</body>
</html>Zolang je in de DB enkel werkt met de (rauwe) binaire variant kun je e.e.a. makkelijk optimaliseren.
Als je iets dan toch in human readable form moet weergeven dan regel je dat aan de PHP-zijde met bovenstaande custom functie (of in een MySQL console met INET6_NTOA()).
EDIT: codevoorbeeld uitgebreid met database.
"Hoi ik wil niets uitleggen over mijn probleem maar ik wil wel de beste oplossing, kan iemand mij helpen?"
Wat bedoel je met "verwerken" en hoe vaak gebeurt dit? Als het niet zo vaak voorkomt dat gegevens worden ingevoerd dan mogen deze toevoeg-operaties best wat duurder zijn. Als deze gegevens vervolgens heel vaak worden opgevraagd is het belangrijk dat deze snel uitgelezen kunnen worden.
Vervolgens bepaalt de manier van gebruik van deze IP's hoe je deze het beste kunt optimaliseren, hier is geen universeel recept voor.
Oftewel: een optimale afstemming van tabellen hangt van het gebruik af (wat doe je met deze informatie), en dit wordt weer bepaald door het gedrag / de werking van de applicatie (hoe gebruik je deze in je applicatie)... waar jij niets over wilt vertellen. Dat wordt dan knap lastig.
On a side note: functies (in MySQL) toepassen op geïndexeerde kolommen, ik denk niet dat dat de snelheid ten goede komt (edit: als je dat in condities gebruikt, zou dat dan niet inhouden dat er toch eerdergenoemde tablescans worden uitgevoerd omdat gekeken moet worden of het resultaat van het toepassen van zo'n functie het gewenste resultaat oplevert?). Wat je wel zou kunnen doen is deze vertalingen uitvoeren in PHP, en zo wegschrijven in de database, en vervolgens zou je queries kunnen uitvoeren op deze geëncodeerde (en geïndexeerde) kolommen. Maar hier geldt weer dat dit sterk afhangt van hoe je deze data gaat gebruiken.
Misschien is het voornaamste probleem wel dat je meet met twee maten, zoals @Patrick aangeeft kan INET6_ATON(expr) hier uitkomst bieden. Voor het terugvertalen in PHP zijn hier opties voor (blijkbaar is inet_ntop() (PHP) niet compatibel met INET6_ATON() (MySQL)). Ik zou dan denk ik wel deze functies alleen aan de PHP-zijde gebruiken, en het gebruik van functies in MySQL -in ieder geval bij het opvragen van informatie- vermijden.
tl;dr omdat je niet uitlegt hoe iets zou moeten werken, is het ook vrij onmogelijk om hier een optimale aanpak bij te verzinnen. Mogelijk heb je toch iets aan bovenstaande opmerkingen.
Niemand reageert normaal als iemand hulp nodig hebt en zulke leden als jullie reageren hier alleen met nutteloze antwoorden waar de topic starters totaal niet op zitten te wachten.
Eens even zien.
Hier stel je een vraag over mysqli_result(). Daar informeer ik eerst naar een ander topic waar nog niet op is gereageerd, waarover hieronder meer. Vervolgens:
Hier stel je een vraag over SQL-injectie. @cakemasher geeft ook nuttige reacties. Zelf:
Leg mij eens uit, hoe was het bovenstaande nutteloos? Ooit gehoord van het spreekwoord "paarlen voor de zwijnen werpen"?
En dat is zeker niet alleen bij mij, maar ook bij andere leden omdat het hier tegenwoordig alleen maar een vast clubje actief is. Dat noemen we ook wel vriendjespolitiek.
Ik denk dat je hier wat dingen door elkaar haalt. De mensen die hier nog actief zijn zijn waarschijnlijk de overgebleven fanatieke die-hards, die nog wel enige heil zien in deze site. Ik zie niet hoe dit iets met vriendjepolitiek te maken zou hebben?
Houdt je commentaar voortaan lekker voor je en reageer alleen als je iets nuttigs te zeggen hebt. Je kan dit wel zeggen dat ik geen topic moet plaatsen en even reageren om te helpen kan je niet. Zeg dan helemaal niks.
Ik schreef volgens mij niet dat je niets meer mocht plaatsen, ik schreef dat je wellicht wat langer moest wachten (of liever gezegd: wat meer huiswerk moet doen) voordat je op de submit-knop drukt.
Ik heb wel een aantal keren gereageerd met volgens mij best nuttige info (zie hierboven), maar hier wordt vervolgens helemaal niet op gereageerd. Dan weet ik verder niet of je uberhaupt de reactie hebt gelezen of er niets mee hebt gedaan of dat je nog steeds met een probleem zit. Het is op zijn minst wel zo netjes om een soort van bevestigend antwoord te geven, ook al doe je er niets mee.
Ik heb inmiddels wel geleerd dat ik niet zou moeten reageren in de hoop daarvoor wat lof, een like of wat dankbaarheid terug te verwachten, dat kan tegenwoordig misschien zelfs wel als naïef bestempeld worden. Ik reageer meestal omdat ik mij vertrouwd voel met de materie, en het belangrijk vind dat anderen ook goed snappen hoe bepaalde zaken werken en ben er ook redelijk van overtuigd iemand anders daar mee te kunnen helpen zodat iemand op een gegeven moment op eigen benen kan staan, en die persoon dan wellicht op zijn/haar beurt weer iemand anders kan helpen.
Waarom roepen de leden hier dan en dat doen ze bijna allemaal, ga naar google, daar vindt je je antwoord?
Misschien is dat niet altijd terecht, maar het zegt mogelijk wel iets over het niveau van de vraag, waarbij de beantwoorder zich afvraagt of de vragensteller wel de moeite heeft genomen om zelf eerst (dingen) te (onder)zoeken. Als je dit in je vraagstelling meeneemt (waarmee je in wezen aantoont dat je je al hebt ingespannen om zelf tot een oplossing te komen, dit is helemaal niet zo vanzelfsprekend als jij wellicht denkt, en wij weten dat ook :)) dan kun je dat soort reacties vermijden. Sterker nog, je zou deze zoekresultaten kunnen aanhalen en kunnen uitleggen waarom dat geen gewenste resultaten opleverde... als dat ondertussen je probleem nog niet had opgelost 
Ik vind het een beetje raar dat je er vanuit lijkt te gaan dat we er hier op uit zijn om het handjevol bezoekers dat hier nog komt af te kraken, maar enige eigen inspanning en (voor)onderzoek wordt wel verwacht voordat je een vraag stelt. En als iemand de moeite neemt om te reageren (wat niet jouw recht is maar iemands eigen keuze) dan is het wel zo fatsoenlijk om deze een repliek te geven.
Als je dit echter niet wilt doen en je simpelweg geen onderzoekende aard bezit noch de tijd wilt nemen om dingen uit te zoeken of kant-en-klare antwoorden wilt kunnen knippen en plakken dan kun je je programmeerwerk beter uitbesteden, dit forum is geen afhaalchinees / gratis helpdesk. We zijn bereid om je op weg te helpen, maar we gaan het werk niet voor je doen, althans niet onbetaald.
Ik geloof ook niet dat vragenstellers echt geholpen zijn met rechtstreekse antwoorden op vragen, omdat er vaak wel wat mankeert aan de aanpak. Het lijkt mij dan beter om terug te gaan naar de tekentafel in plaats van een ad hoc oplossing te geven voor een ad hoc probleem. En met die insteek staat de vragensteller de volgende dag weer klaar met een nieuwe vraag, omdat deze weigert (en ook gefaciliteerd wordt) om (niet) zelf na te denken over problemen. Op die manier leer je ook niets.
Wat mij betreft staat de deur nog altijd open mits je zelf wat meer betrokkenheid (en inlevingsvermogen) toont, maar tot die tijd denk ik dat ik inderdaad jouw advies opvolg en gewoon niet meer op jou reageer.
@LadyOfHell het is fijn dat je zo fanatiek bent, maar zou je misschien wat terughoudender kunnen zijn met het plaatsen van topics, hier gaan mensen soms enthousiast mee aan de slag en om dan (herhaaldelijk, want dit is niet de eerste keer) te horen te krijgen dat "het al opgelost" is nodigt mensen niet echt uit om je (in de toekomst) te helpen.
Ook is het wel zo netjes om op topics te reageren, zoals hier en hier, anders bestaat de kans dat je na verloop van tijd te boek staat als een chaotisch snelvuurkanon.
Thanks.
upload_max_filesize is een PHP_INI_PERDIR instelling, dit houdt in dat je een aantal keuzes hebt waar je dit allemaal in kunt stellen, zo zou je deze (tijdelijk) in een .htaccess bestand kunnen zetten (waarschijnlijk heb je geen toegang tot de php.ini file van jouw hostingpakket).
upload_max_filesize is overigens de maximale grootte van één bestand, er is ook nog een instelling voor de maximale totale grootte van geposte data: post_max_size. Deze zul je dus beide (tijdelijk) moeten ophogen om grotere bestanden te kunnen uploaden.
Maar omdat je gebruik maakt van een pakket loont het de moeite om te proberen om het via de spelregels van het pakket op te lossen.
Een simpele Google opdracht leert ons vervolgens dat er meerdere manieren zijn om dit op te lossen.
Misschien is het ook mogelijk om het RAR bestand ergens neer te zetten via FTP, en vervolgens daarmee aan de slag te gaan?
Overigens, als je de volgende keer zo'n melding krijgt (The uploaded file exceeds ...) - deze zijn bij uitstek geschikt om in een zoekmachine te gooien, de problemen die aan dit soort foutmeldingen ten grondslag liggen zijn zelden tot nooit uniek, iemand anders is hier al een keer tegenaan gelopen en heeft al voor zichzelf en voor anderen uitgezocht wat de oplossing is.
Kort antwoord is dus: hoog upload_max_filesize en post_max_size (tijdelijk) op of kijk of er een manier is om dingen op een alternatieve manier te uploaden (bijvoorbeeld via FTP) in plaats van via het web. Het web (lees: webpagina's) leent zich doorgaans slecht voor het uploaden van grote bestanden.
NB blijkbaar kun je de uitgepakte vorm ook direct in wp-content/themes/ zetten. Dit kostte mij ook < 2 minuten Googlen.
Waar gebruik je de IP-adressen voor? En zijn deze noodzakelijk?
Als je namelijk een oplossing hebt waarbij je niet afhankelijk bent van IP-adressen, dan heb je dit probleem in eerste instantie niet.
En hoe speelt snelheid hier een (cruciale?) rol? Je kunt toch gewoon een index aanmaken op een kolom?
Al GeGoogled (zoek eens op "webbassed planning software")? Er zijn tientallen zoniet honderden (of meer) webbased planningssystemen.
Bijvoorbeeld LiquidPlanner.
Maar wat je kunt gebruiken hangt sterk af van wat je wilt kunnen doen. Daarbij zul je ook het niveau van de gebruikers en bijbehorende leercurve moeten incalculeren. Een systeem kan nog zo fantastisch zijn, als niemand begrijpt hoe het werkt dan is het waarschijnlijk meer een last dan een hulpmiddel.
Als ik Google op "joomla file manager component" krijg ik een hoop resultaten, bovenaan de resultaten een link naar de extensions pagina van Joomla zelf.
In de omschrijving van de eerste module (ProFiler) staat o.a. het volgende:
Dus als je voor elke gebruiker een eigen groep creëert dan heb je in principe al min of meer wat je wilt? Mogelijk is het (ondertussen) ook al mogelijk om root folders rechtstreeks / exclusief aan gebruikers te koppelen wie weet. Ook kun je misschien het aantal extenties beperken (als dat jouw wens is), maar daar zou je ook gewoon afspraken over kunnen maken.
En zo zou je ook andere modules uit kunnen proberen / kunnen bestuderen om te zien in hoeverre deze voldoen aan jouw wensen.
Content Management Systemen zijn gemaakt voor dit soort functionaliteit, al sluiten de kant-en-klare bouwstenen die je hier in kunt prikken meestal niet feilloos aan op iemands persoonlijke wensen. Je zult dus vaak moeten kijken of deze verschillen overbrugbaar zijn door enkele tweaks of dat hetgene jij wilt echt niet bestaat (en er ook niets is wat er in de verste verte op lijkt) maar dat komt eigenlijk niet zo vaak voor volgens mij.
Hm, weet je zeker dat Joomla geen modules heeft die zoiets kunnen? Het klinkt allemaal redelijk eenvoudig, vooral als jij (of een superadmin) diegene bent die toegang regelt enzo.
Al zie ik niet direct de noodzaak dat dit centraal beheerd wordt, tenzij je dit als een soort van dienst wilt aanbieden?
Heb je eventueel ook al naar alternatieven gekeken zoals, ik noem maar wat, Google Drive (verder geen ervaring mee) of DropBox ofzo?
Of je kijkt of de Marktplaats API mogelijkheden biedt.
Het in een transactie plaatsen van queries garandeert niet de ondeelbaarheid van een reeks acties binnen zo'n transactie, twee of meer transacties kunnen nog steeds tegelijkertijd plaatsvinden.
Het ondeelbaar maken van meerdere acties bereik je alleen door binnen de transactie records te vergrendelen met FOR UPDATE. Dus het "reserveren" waar jij het over hebt is (zowel in mijn voorstel als in jouw aanpak) een absolute voorwaarde voor correcte werking.
Lees de volgende paragraaf eens door, deze verwoordt mogelijk beter wat er gebeurt tijdens een transactie.
En ook zul je dus de situatie moeten ondervangen dat de transactie in het geheel niet doorgaat. Dus stel dat je een batch niet in zijn geheel kunt kopen, dan zal deze hele batch niet doorgaan, immers, het idee van een transactie is dat deze in het geheel wordt uitgevoerd, of in het geheel niet. Daarom stelde ik voor om de afmeting van de "ondeelbare actie" op item-niveau te doen, in plaats van op bestelling-niveau zodat je niet alle items opnieuw hoeft in te kopen als er toevallig één item niet meer in de juiste hoeveelheid beschikbaar is omdat iemand anders je net voor was. Zo gaat het in een webshop ook: als 1 item niet beschikbaar is zal niet ineens je hele bestelling worden geannuleerd :p.