Een .htaccess in blog maken met:quote:Op woensdag 15 oktober 2014 16:23 schreef wipes66 het volgende:
weet iemand hoe ik een htaccess bestand uit een 'parent' directory kan laten negeren? bv:
public_html/www/index.php
public_html/www/.htaccess
public_html/www/blog/
en als dan public_html/www/blog/index.php wordt opgevraagd dat het bovenliggende .htaccess bestand geheel genegeerd wordt, is dat mogelijk?
1 | RewriteEngine Off |
1 | RewriteConf %{REQUEST_URI} !^/blog/? |
het gaat helaas niet alleen om rewrite rules, maar ook allerlei andere regels (white listing van bestanden etc). het hele htaccess moet dus genegeerd worden.quote:Op woensdag 15 oktober 2014 16:39 schreef Aether het volgende:
[..]
Een .htaccess in blog maken met:
[ code verwijderd ]
óf in de .htaccess toevoegen (uit m'n hoofd):
[ code verwijderd ]
Voor zover ik weet is dat niet mogelijk. Je zou in de bovenliggende htaccess moeten opgeven dat de regels daarin niet gelden voor een specifieke onderliggende map. Voorbeeld: http://stackoverflow.com/(...)ules-in-root-htaccesquote:Op woensdag 15 oktober 2014 16:42 schreef wipes66 het volgende:
[..]
het gaat helaas niet alleen om rewrite rules, maar ook allerlei andere regels (white listing van bestanden etc). het hele htaccess moet dus genegeerd worden.
Ik wil daaruit de tekst tussen <blockquote> en </blockquote> hebben zodat ik tekst tussen tags apart van de rest kan verkrijgen, hiervoor heb ik het volgende bedacht:quote:bla
<blockquote>bla bla bla</blockquote>
bla bla
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | CASE WHEN LOCATE( '<blockquote>', `contents` ) != 0 THEN MID( `contents`, LOCATE( '<blockquote>', `contents` ) + 12, (LOCATE( '</blockquote>', `contents` ) - LOCATE( '<blockquote>', `contents` )) - 12 ) ELSE '' END AS post_quote, CASE WHEN LOCATE( '<blockquote>', `contents` ) != 0 THEN CONCAT_WS( LEFT( `contents` , LOCATE( '<blockquote>', `contents`) - 1), ' ', RIGHT( `contents` , LENGTH(`contents`) - (LOCATE( '</blockquote>', `contents` ) + 12)) ) ELSE `contents` END AS post_contents |
Hier zou het volgende uit moeten komen:quote:<blockquote>quote 1</blockquote>
reactie 1
<blockquote>quote 2</blockquote>
reactie 2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | SELECT CASE WHEN LOCATE( '<blockquote>', `contents` ) != 0 THEN MID( `contents`, LOCATE( '<blockquote>', `contents` ) + 12, (LOCATE( '</blockquote>', `contents` ) - LOCATE( '<blockquote>', `contents` )) - 12 ) ELSE '' END AS post_quote, CASE WHEN LOCATE( '<blockquote>', `contents` ) != 0 THEN CONCAT_WS( LEFT( `contents` , LOCATE( '<blockquote>', `contents`) - 1), ' ', RIGHT( `contents` , LENGTH(`contents`) - (LOCATE( '</blockquote>', `contents` ) + 12)) ) ELSE `contents` END AS post_contents FROM ( SELECT 'bla bla bla <blockquote>quote 1</blockquote>reactie 1<blockquote>quote 2</blockquote> reactie 2' AS `contents` ) AS dummy |
Deze query wordt door Sphinx gebruikt om data te indexeren, ik moet deze data in twee velden in de index hebben zodat ze los van elkaar doorzocht kunnen worden. Ik kan in dit geval niets anders doen dan het in de query afhandelen.quote:Op zondag 19 oktober 2014 08:47 schreef KomtTijd... het volgende:
Dat het kan betekent niet dat je het ook moet willen. Dit lijkt me typisch iets wat je in je businesslogic afhandelt ipv in een query.
Eens, maar gaat in dit geval nietquote:Op zondag 19 oktober 2014 09:01 schreef slacker_nl het volgende:
Hij vind het leuk om zich in moeilijke situaties te knopen.
Maar agreed, dit moet je denk ik niet in je SQL stoppen, maar erbuiten.
Nodig niet, of het handig is hangt af van je toepassing.quote:Op zondag 19 oktober 2014 21:19 schreef xaban06 het volgende:
Normaal heb ik bij een database tabel een veld genaamd 'id' met auto increment. Dit keer heb ik een andere veld welke uniek is en nooit dubbel kan zijn. Is het dan nog steeds handig/nodig om een id veld te hebben?
Gebruikelijk is om zowel de ruwe input als de HTML op te slaan. Waarom je ook nog platte tekst op zou willen slaan zou ik niet weten. Je kunt toch ook zoeken op de html/txt velden?quote:Op zondag 19 oktober 2014 21:19 schreef xaban06 het volgende:
Normaal heb ik bij een database tabel een veld genaamd 'id' met auto increment. Dit keer heb ik een andere veld welke uniek is en nooit dubbel kan zijn. Is het dan nog steeds handig/nodig om een id veld te hebben?
ik dacht anders zoekt ie de tags ook gezellig mee. Ok cool dankjequote:Op zondag 19 oktober 2014 21:44 schreef KomtTijd... het volgende:
[..]
Gebruikelijk is om zowel de ruwe input als de HTML op te slaan. Waarom je ook nog platte tekst op zou willen slaan zou ik niet weten. Je kunt toch ook zoeken op de html/txt velden?
Whut?quote:Op zondag 19 oktober 2014 21:44 schreef KomtTijd... het volgende:
[..]
Gebruikelijk is om zowel de ruwe input als de HTML op te slaan. Waarom je ook nog platte tekst op zou willen slaan zou ik niet weten. Je kunt toch ook zoeken op de html/txt velden?
Daar heb je zeker een punt ja. Je zou kunnen overwegen ook de platte tekst op te slaan idd, maar als je echt een fatsoenlijke zoekfunctie wilt maken komt daar nog heel wat meer bij kijken. Ik heb er geen ervaring me maar weet dat er hele studies maar verricht zijn.quote:Op zondag 19 oktober 2014 21:54 schreef n8n het volgende:
[..]
ik dacht anders zoekt ie de tags ook gezellig mee. Ok cool dankje
Als je id hebt buiten je primary doe je wat fout.quote:Op zondag 19 oktober 2014 21:42 schreef KomtTijd... het volgende:
[..]
Nodig niet, of het handig is hangt af van je toepassing.
een id is toch nooit weg?quote:Op maandag 20 oktober 2014 00:00 schreef Boze_Appel het volgende:
[..]
Als je id hebt buiten je primary doe je wat fout.
Hij bedoelt denk ik een extra id buiten je primary key.quote:
ongetwijfeld, denk voor de html-variant dat in veel gevallen ook op hele pagina’s gecached kan worden. Geeft een mooi beeld van wat er nou allemaal onderhouden/aangepast moet worden met een updatequote:Op zondag 19 oktober 2014 22:00 schreef KomtTijd... het volgende:
[..]
Daar heb je zeker een punt ja. Je zou kunnen overwegen ook de platte tekst op te slaan idd, maar als je echt een fatsoenlijke zoekfunctie wilt maken komt daar nog heel wat meer bij kijken. Ik heb er geen ervaring me maar weet dat er hele studies maar verricht zijn.
ik heb op een site een unieke hash die ik als slug gebruik maar daarnaast ook een id, momenteel omdat ik daar nog op sorteer (oud naar nieuw, wordt nog aangepast). Een id veld maakt verder toch geen reet uit, als in een id is 'gratis'?quote:Op maandag 20 oktober 2014 11:11 schreef Tijn het volgende:
[..]
Hij bedoelt denk ik een extra id buiten je primary key.
Het valt heel erg mee, maar ik zou voor een beetje fatsoenlijke zoekfunctie inderdaad gewoon fatsoenlijke search software gebruiken zoals bijvoorbeeld Apache Solr.Standaard relevantie scoring obv TF/IDF, allerhande mogelijkheden voor stopwords filtering, stemming, synoniemen, enzovoort.quote:Op zondag 19 oktober 2014 22:00 schreef KomtTijd... het volgende:
[..]
Daar heb je zeker een punt ja. Je zou kunnen overwegen ook de platte tekst op te slaan idd, maar als je echt een fatsoenlijke zoekfunctie wilt maken komt daar nog heel wat meer bij kijken. Ik heb er geen ervaring me maar weet dat er hele studies maar verricht zijn.
Ik heb zelf vaak ook een public hash voor het exposen van records aan de buitenwereld, zodat ik niet de interne ids hoef te delen. Ik zou ook niet direct weten waarom dat erg is, maar ik kan me voorstellen dat het geen handig databaseontwerp is als je hetzelfde record via allerlei verschillende ids kan terugvinden.quote:Op maandag 20 oktober 2014 11:13 schreef n8n het volgende:
[..]
ik heb op een site een unieke hash die ik als slug gebruik maar daarnaast ook een id, momenteel omdat ik daar nog op sorteer (oud naar nieuw, wordt nog aangepast). Een id veld maakt verder toch geen reet uit, als in een id is 'gratis'?
op die manier, ik heb alleen een hash van 4 karakters, eerste altijd alpha dus 1.213.056 combinaties wat voor dit project ruim voldoende is. Browsers tonen toch steeds vaker naar een versimpelde url, verder is er geen manier om content er uit te persen voor publiekquote:Op maandag 20 oktober 2014 11:17 schreef Tijn het volgende:
[..]
Ik heb zelf vaak ook een public hash voor het exposen van records aan de buitenwereld, zodat ik niet de interne ids hoef te delen. Ik zou ook niet direct weten waarom dat erg is, maar ik kan me voorstellen dat het geen handig databaseontwerp is als je hetzelfde record via allerlei verschillende ids kan terugvinden.
Bij grote hoeveelheden data scheelt het nog veel meer, zeker in de worst case scenario's.quote:Op maandag 20 oktober 2014 18:53 schreef xaban06 het volgende:
Wat is MySQL trouwens snel zeg als je de juiste indexes toepast factor 10 kwa snelheidswinst
Tabel heeft nu 50.000 records, binnen enkele weken wordt dat een paar miljoen en zal vanaf dan dagelijks met ~800 records groeien.quote:Op maandag 20 oktober 2014 19:16 schreef Monolith het volgende:
[..]
Bij grote hoeveelheden data scheelt het nog veel meer, zeker in de worst case scenario's.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |