On a sidenote: als iedereen tot op zekere hoogte pagina's kan creëren (of andere dingen kan doen met beschikbaar gestelde functionaliteit) voor een eigen website lijkt mij veiligheid wel een dingetje. Als je maar 1 voordeur hebt (index.php) hoef je er ook maar 1 slot op te gooien :). Lijkt mij helpen bij het beheersbaar houden van dit soort concepten. Als je dadelijk allerlei standalone scripts hebt die gepatched moeten worden moet je mogelijk een heleboel werk dubbel doen. Met één kapstok hoeft dat maar op één plaats.

Ah well :).

HTML heeft dit in principe al ingebouwd. Maar je wilt waarschijnlijk niet dat iemand broncode kan inspecteren om de voorwerpen te localiseren. (Of als dat geen probleem is ben je in principe al klaar, behalve dat je een soort van drag-and-drop functionaliteit moet verzinnen om dat soort afbeeldingen toe te voegen).

Vaak is het met dit soort vraagstukken zo dat deze niet uniek zijn :]. Iemand anders is hier al eens tegenaan gelopen.

Kan echter zo gauw niets vinden :p, maar als je dit serverside wilt uitrekenen dan is dit niet zo lastig:
- vierkant, rechthoek en cirkel zijn redelijk triviaal,
- ovaal is misschien wat lastiger,
- en mogelijk biedt dit uitkomst voor polygonen

Je zult dan wel de afbeeldingen moeten definieren in coordinaten, en deze mbv een "ophangpunt" in/over je achtergrondafbeelding plaatsen ofzo.

Zou je dit niet veel makkelijker kunnen doen?

In wezen heb je geen rewriterules nodig, enkel een "front end controller" / "single point of entry".

Op grond van het subdomein zou je gewoon naar een database kunnen schakelen (aangenomen dat je per subdomein een database hebt)?

Idealiter "vervuil" je de $_GET namespace niet met dit soort "onzichtbare" $_GET parameters (die daarmee dus effectief "gereserveerd" zijn) - $_GET zou juist transparant moeten zijn.

Maar/en om antwoord te geven op je vraag: probeer eens de QSA (Query String Attach) flag toe te voegen.

Maar nogmaals, dat is dus niet nodig als je voor de "simpelere" oplossing gaat.

Mja, een soort van serverside imagemap dus. De clicks zou je via AJAX-calls kunnen afhandelen. Het "enige" wat je aan de serverzijde controleert is of iemand binnen een polygon heeft geklikt.

Waarschijnlijk wil je ook bijhouden hoe vaak iemand klikt, anders zou je misschien zelfs geautomatiseerd een plaatje af kunnen klikken.

Citaat van Frenzo.Brouwer

Ja dat is het probleem, maar weet iemand de oorzaak?

Dat is toch de oorzaak? Het schermt verspringt omdat je scrollbalk verdwijnt. Of liever gezegd. Het scherm verspringt omdat bij het openen van de modal de scrollbalk verdwijnt en daarmee je site effectief breder wordt, waardoor alles opnieuw gepositioneerd wordt.

En de oorzaak daarvan zit waarschijnlijk in je CSS.

En als je dat kruimelpad volgt is het waarschijnlijk een developer die te weinig koffie had gedronken (of teveel van iets anders :p) en/of eentje die zijn/haar oplossingen niet echt heeft doorgetest.

Waarschijnlijk door slaaptekort vanwege een te lang weekend.

Etc. etc.

De scrollbalk verdwijnt als de overlay verschijnt, waardoor de breedte van je site verandert.

Hm, mogelijk kun je nog e.e.a. refactoren. Zo zou je gebruik kunnen maken van array_sum() -mits je e.e.a. slim onderbrengt in subarrays- en als je een stukprijs hebt kun je die vermenigvuldigen met dat aantal?

This looks like a typical Magento webshop?

Asking what SEO "implementation" is used (or perhaps, more accurate, what SEO principles are used) for a website is like asking what typewriter was used to write a novel... there is no way to tell?

Looking into what design philosophies Magento uses when it comes to SEO will probably get you further.

This is not a magic wand you can wave and suddenly you have "SEO" (and I doubt such tools exist), but a free page where you could find more information on this would be Google.

You will also have to apply these principles from the get-go when developing a website. You cannot have crap navigation and HTML structure and then pour some SEO sauce over it, it just doesn't work that way.

Je wilt dus op grond van een key / waarde in een (genest) array een nieuw array bouwen waarbij je groepeert op deze key / waarde?

Dit lijkt mij niet zo lastig, maar hoe zou dat nieuwe gecombineerde array er dan uit moeten zien?

Je hebt het trouwens over samentellen en groeperen, maar als je je nieuwe array (of dataset) nu eens handig in elkaar steekt dan kun je de informatie ook rechtstreeks berekenen aan de hand van die nieuwe structuur. In dat geval kun je ook nog herleiden hoe die optelsommen totstand komen want die zijn puur programmatisch en niet ingebakken in het array (hiermee is je dataset ook dus nog breder inzetbaar/herbruikbaar voor andere doelen). Als je alles op voorhand bij elkaar mikt dan kun je dit niet meer afleiden wat mij niet echt handig lijkt.

Technisch of visueel?

Technisch: je zou iets met jQuery kunnen doen, de meeste mobiele devices ondersteunen tegenwoordig wel JavaScript lijkt mij? En het dan zo maken dat alles anders altijd uitgeklapt is zodat je zonder JavaScript in principe ook uit de voeten kunt.

Visueel: hier kun je natuurlijk zelf helemaal los als je wilt :p. Ik zou simpel beginnen, bijvoorbeeld een lichtere kleur voor subitems. En je zou pijltjes of +/- symbolen kunnen gebruiken voor uitklapbare items, zodat dit op een of andere manier duidelijk is.

Dat zeg ik dus. Als je niet hovered over een list-item met een submenu moet het submenu gewoon onzichtbaar zijn, dus zoiets:

#navigation-menu-bottom ul li ul.sub-menu { display: none; }

En als je wel hovered, wel:

#navigation-menu-bottom ul li:hover ul.sub-menu { display: block; }

Weet niet of dat echt handig is voor een mobiel menu, want als je naar Test2 zweeft dan klapt je menu weer in. Eigenlijk wil je de submenu's handmatig openklikken misschien.

Weet niet precies wat je met puntje #2 bedoelt en of dit voor de mobiele of niet-mobiele navigatie is. Je zou het inspringen achterwegen kunnen laten (op mobiel is de horizontale ruimte sowieso al beperkt) en kunnen volstaan met een lichtere achtergrondkleur zodat duidelijk is dat dit een sub-onderdeel van een hogergelegen item is? En dus met eerdergenoemde handmatige uitklap-actie zodat je menu niet automatisch weer inklapt, ik denk dat je dan beide problemen hebt opgelost?

Wat je wilt is volgens mij het volgende:

Citaat

Indien er niet gehovered wordt over een item wat een submenu heeft, dient dit submenu geen ruimte in te nemen.

Hiervoor zul je iets in CSS moeten verzinnen, waarschijnlijk iets waarbij het submenu standaard display: none heeft, en als je hovered display: block.

Nou, als je even Googled dan vind je een aantal resultaten, waaronder een link naar de officiële handleiding.

Los hiervan, als je backups aan het maken bent zitten er ideaal gesproken geen gebruikers in je systeem / webshop. Dus het zou beter zijn als je de store tijdelijk offline haalt, en dat houdt weer in dat je het draaien van backups aan zou moeten kondigen. In de aanloop van het maken van de backup zit dus enige voorbereiding.

Of je zorgt dat dit in daluren gebeurt (bijvoorbeeld diep in de nacht).

En zoals je in bovenstaande documentatie(link) kunt zien gaat het maken van een backup verder dan enkel de database, je hebt ook nog je media-assets. Samen zorgen deze voor al je "content".

En dan ben je er nog niet, er is ongetwijfeld ook een (uitgebreide?) procedure voor het restoren van een backup.

Zorg ook dat je de HELE routine test (zowel backup als restore), en niet enkel het maken van een backup. Indien je backup onbruikbaar is (zoals nu ook het geval is geloof ik?) heb je helemaal niets aan een backup...

Daar zijn toch procedures voor? Die waarschijnlijk ook gedocumenteerd zijn, Magento heeft over het algemeen wel goede documentatie. Ook moet je waarschijnlijk na afloop allerlei (gecachede) indexen herbouwen (backup + restore bestaat uit meerdere stappen en tussendoor zul je de site / stores ook offline moeten halen lijkt mij, dit is een traject, niet een enkele handeling). Het lijkt mij dat je niet zomaar een database-dump en een import kunt doen voor een site als Magento.

Mogelijk heb je dan niet "alles" gebackupped? Wel de tabelstructuur maar niet de data?

Misschien moet je ook wat specifieker zijn?
Wat voor platform?
Wat voor pakket?
Wat voor database?
Wat voor backupmethode?
Wat voor restoremethode?
Regel je ook het technisch beheer van de site zelf? Want het kan (anders) best zijn dat een hoster wel (incrementele) backups heeft maar in eerste instantie zegt dat ze weinig voor je kunnen betekenen omdat ze geen zin hebben in het terugzetten hiervan?

Citaat van A.Bijlsma

Normaal zou CF dus beter moeten werken met websites.
Bij mij is het nu zo dat CF mijn website juist slomer maakt, en bij gebruik van https:// sorgt het ervoor dat ie niet eens de css bestanden inlaadt iemand enig idee wat er mis is?

Dit is wel grappig als je er over nadenkt. Hier zitten allerlei aannames in verwerkt.

Bijvoorbeeld dat topicstarter eerst een site X had zonder CF, die blijkbaar wel snel was, en vervolgens had deze precies dezelfde website X overgezet naar CF (precies hetzelfde, anders is het toch een beetje appels met peren vergelijken?) die ineens sloom is.

Vervolgens wijst de topicstarter https (dus toch een wijziging ten opzichte van de originele opstelling naast de overgang naar CF? of gebruikt CF altijd https? I dunno.) aan als schuldige voor het niet werken van CSS-bestanden, terwijl dit mogelijk een verwijzingsprobleem is zoals hierboven al wordt aangekaart.

En dan het beklag dat CF traag is of zou zijn. Wanneer je meerdere factoren tegelijkertijd wijzigt en er problemen ontstaan, kun je niet zomaar op voorhand één factor aanwijzen als de boosdoener.

Dit hele verhaal rammelt aan alle kanten. Immers. Je hebt zelf al geconstateerd dat er een probleem is (CSS-bestanden laden niet). Los dit eerst eens op, en kijk dan of de problemen nog spelen.

Het heeft geen zin om een situatie te analyseren waarvan je wéét dat die niet klopt!

Dit is zoiets als het intensief staren naar een plas water, terwijl je zelf ergens een kraan open hebt gezet.

Ok.

Maak even een backup van wat je nu hebt in een apart bestand.

Zet vervolgens enkel de volgende tekst in je .htaccess bestand:

<IfModule mod_rewrite.c>
RewriteEngine On
Options -Indexes
Options +FollowSymLinks


RewriteCond %{HTTP_HOST} ^badbull.eu [NC]
RewriteRule ^(.*)$ http://www.badbull.eu/$1 [L,R=301] 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* loader.php [L,QSA]
</IfModule>

Je zou nog kunnen proberen om de Options regels te voorzien (vooraf te laten gaan door) een hashtag, zoals hierboven ook gesuggereerd wordt als e.e.a. niet werkt.

Ook zou je misschien na kunnen gaan of mod_rewrite wel aan staat via een controlepaneel ofzo.

Als dit alles je probleem niet oplost zul je toch even met je host / vaste programmeur contact op moeten nemen. Zomaar ergens een source neerplempen is mogelijk niet echt de beste aanpak. Vaak is er een handleiding of korte uitleg wat de te doorlopen stappen zijn voor een installatie of verhuizing.

Is dat letterlijk wat er in je .htaccess staat? Beetje een puinhoop niet?

Als je alle commentaarregels verwijdert houd je het volgende over:

Options 
<IfModule mod_rewrite.c> RewriteEngine On
RewriteCond %{HTTP_HOST} ^badbull.eu [NC]
RewriteRule ^(.*)$ http://www.badbull.eu/$1 [L,R=301] 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* loader.php [L,QSA]
</IfModule>
Options 
<IfModule mod_rewrite.c> RewriteEngine On
RewriteCond %{HTTP_HOST} ^badbull.eu [NC]
RewriteRule ^(.*)$ http://www.badbull.eu/$1 [L,R=301] 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* loader.php [L,QSA]
</IfModule>

De regels met "Options" zijn syntactisch (qua vorm) waarschijnlijk incorrect.

Ook gaat het waarschijnlijk mis op de regel met IfModule, die RewriteEngine regel moet naar alle waarschijnlijkheid op een aparte regel.

Los hiervan, je had dit door middel van eliminatie al uit kunnen vogelen door regels te voorzien van een hashtag net zolang totdat je geen foutmelding meer had.

Ik stel voor dat je e.e.a. ontdubbelt en uiteindelijk maar één (werkend) IfModule blok overhoudt want het is voor iedereen (zowel mens als computer) verwarrend als je dingen dubbel definieert.

En zelfs als je je tijden fixt zul je rekening moeten houden met het volgende:

Stel dat je een "crime" of wat dan ook wilt verwerken, dit valt dan vaak in twee of meer stappen uiteen:
[controleer of actie X uitgevoerd mag worden]
[voer na controle actie X uit]

Wat je wilt is dat deze stappen als één ondeelbare (atomaire) actie worden uitgevoerd. Ook hier zul je zelf werk voor moeten verzetten, bijvoorbeeld door gebruik te maken van database-transacties (en enkel het gebruik maken van transacties is eigenlijk nooit genoeg). De reden waarom "crime games" of andere webgames vaak niet goed beveiligd zijn tegen valsspelen is omdat (onder andere) aan dit punt geen aandacht wordt besteed.

Stel bijvoorbeeld dat iemand 3x tegelijkertijd zo'n actie op de webserver afvuurt, wanneer dan de bovenstaande actie niet ondeelbaar is, worden de scripts parallel uitgevoerd (dit gebeurt trouwens sowieso), bijvoorbeeld in de volgende volgorde:
[controleer of actie X uitgevoerd mag worden #1]
[controleer of actie X uitgevoerd mag worden #2]
[voer na controle actie X uit #1]
[voer na controle actie X uit #2]
[controleer of actie X uitgevoerd mag worden #3]
[voer na controle actie X uit #3]
Grote kans dat actie #1 en #2 worden doorgelaten, en enkel #3 wordt geblokkeerd vanwege #1 of #2, maar zelfs dat is niet gegarandeerd en hangt af van wat deze acties doen / hoe snel de scripts uitgevoerd worden.

Wat belangrijk is dat op het moment dat zo'n transactie start, alle betrokken resources worden vergrendeld zodat eenzelfde transactie moet wachten totdat de huidige transactie is afgerond. Dit is de enige manier om te garanderen dat op enig moment maximaal één transactie ten uitvoer wordt gebracht.

In bovenstaand voorbeeld zou dit bijvoorbeeld kunnen resulteren in het uitvoeren van twee crimes in eenzelfde tijdsbestek, terwijl het eigenlijk de bedoeling was dat iemand dit maar één keer mag doen binnen een bepaalde timeout. Hierbij helpt het natuurlijk ook als er geen rekenfouten zitten in je tijdscalculaties. Als je die baseert op 1 klok, en daarmee dus ook meet met maar 1 maat, ben je al een eind op de goede weg, maar ben je nog bij lange na niet bij een (veilige) eindbestemming.

Nee, dat zeg ik dus. Onder water wordt standaard al (zoals je zelf al zegt met bij o.a. de time() functie) met UTC gerekend. Hoe je dit weergeeft doet er niet toe. Je moet er ook voor zorgen dat je één bron voor je klok gebruikt. Dus niet zowel in MySQL als in PHP de "huidige tijd" genereren, maar doe dit altijd ofwel in PHP ofwel in MySQL. Stap dus van een van de twee af.

CURRENT_TIMESTAMP() is een -geformatteerde- timestamp (yyyy-mm-dd hh:mm:ss) in lokale tijd. Dit is dus NIET (of in ieder geval NIET PER SE) het MySQL-equivalent van time() (ALTIJD UTC), maar hangt af van de op de databaseserver geconfigureerde tijdszone (MOGELIJK NIET UTC).

Ik denk dat het volgende even moet bezinken. time() is altijd in UTC. Op het moment dat je, gegeven zo'n time() timestamp, hier een datum-formatteringsfunctie overheen gooit, zoals date(), dat wordt automatisch een conversie gedaan van UTC naar de ingestelde lokale tijd(szone). Dit kon je ook terugzien in mijn bovenstaande codevoorbeeld: ik verander niets aan de timestamp $now, maar als ik de tijdszones tussendoor verander spuugt dezelfde functie-aanroep (met precies dezelfde parameters) achtereenvolgens twee verschillende tijden uit.

Dit is dus enkel een weergave-ding, onder de motorkap is (of zou dit) allemaal UTC (moeten zijn), dus OOK de timestamps die je in je database wegschrijft. Daarom is het onverstandig om CURRENT_TIMESTAMP() te gebruiken want dit vertelt je niets over de tijdszone waar je in zit. Het is dan vaak wel een zinnige aanname om, wanneer je met timestamps werkt, er vanuit te gaan dat dit ook UTC is, maar daar moet je dan wel zelf voor zorgen :p. En liefst ook documenteren.

TL;DR
gebruik één klok (PHP of MySQL) om te bepalen hoe laat het is (maar niet allebei, mogelijk staan beide klokken niet (helemaal) gelijk)
sla alles in UTC op, en documenteer dit ook ergens
geef tijden en datums in lokale tijdszone weer, doe dit middels standaard datum- en tijdfuncties (deze voeren de vertaling UTC -> lokale tijdszone vaak automatisch uit, maar controleer dit)

In andere bewoordingen, waarin in feite hetzelfde wordt gezegd.

(en het probleem is dus bij timestamps als yyyy-mm-dd hh:mm:ss dat je op geen enkele manier kunt afleiden op welke tijdszone deze betrekking heeft)

Het TIMESTAMP kolomtype heeft trouwens dezelfde beperkingen als de unix timestamp (bereik tot 2038-01-19) en de DATETIME kolom heeft het nadeel dat deze niet automatisch geconverteerd wordt bij gebruikmaking van formatteringsfuncties, want het is niet gegarandeerd dat de timestamps om te beginnen UTC waren... Je zou er nog steeds voor kunnen kiezen om alles als UTC op te slaan in DATETIMEs en dan het rekenwerk naar jouw ingestelde lokale tijdszone over te hevelen naar PHP. Dit is in zekere zin een weergavekwestie die je apart kunt behandelen.

Speerpunt hier misschien is ook het volgende: UTC heeft geen "DST" (Daylight Saving Time), oftewel, deze zal nooit een uur verspringen. Dit komt dan weer van pas om te berekenen of iemand al acties voor/na een bepaalde verstreken tijd mag uitvoeren want dat tijdsverschil is altijd exact want de klok verspringt nooit.

Dit alles komt dus in feite neer op bewustwording van het fenomeen tijdszones en welke functies hier op acteren of afhankelijk van zijn, en welke niet. En vervolgens is het zaak dat je consequent bent bij het opvragen van de tijd, en het op één manier (in één tijdszone) opslaan van deze tijden.