[PHP] preg_replace - Regular Expressions

[imp4ct]

Ik ben mij aan't toeleggen op Regular Expressions en 'k heb wat tutorials zitten lezen hier een daar over deze zaken, al wat geprobeerd, maar nu zit ik echt vast.

Ik werk met BB code bij de input van m'n newspost systeem. Wanneer ik via BB code een aanmaak en deze post, dan werkt dit goed. Deze omzetting via preg_replace en regular expression werkt dus.
Nu wanneer iemand z'n post wilt editen, moet die BB code wat dus HTML is geworden terug worden omgezet naar BB, nu dit lukt niet.

Kan iemand me helpen ?

PHP:

$bbpost = preg_replace("#<a href=([^\"\"]*)?>([^\"\"]*)([</a>])#e","het werkt", $bbpost);

de input wat deze preg_replace zou moeten verwerken is.

code:

vb.
HTML input = <a href="http://www.tweakers.net" target="_blanc">Tweakers.net</a>
dit zou moeten worden omgezet naar
[url=http://www.tweakers.net]Tweakers.net[/url]

[Verwijderd]

Sla zowel de input (UBB) als de output (HTML) op in de database.

[imp4ct]

Verwijderd schreef op dinsdag 07 juni 2005 @ 20:00:
Sla zowel de input (UBB) als de output (HTML) op in de database.

Da's een vrij "domme" oplossing vind ik persoonlijk. Je kan het natuurlijk doen, als je het jezelf heel makkelijk wilt maken. Maar als je grote posts 2x in je DB gaat opslaan vind ik dit vrij stom. Dus ik zou het toch liever oplossen met deze functie te gebruiken. 'k Denk niet dat er veel sites volgens deze manier werken.

[Peter]

I_M_P_A_C_T schreef op dinsdag 07 juni 2005 @ 19:56:
Ik ben mij aan't toeleggen op Regular Expressions en 'k heb wat tutorials zitten lezen hier een daar over deze zaken, al wat geprobeerd, maar nu zit ik echt vast.

Ik werk met BB code bij de input van m'n newspost systeem. Wanneer ik via BB code een aanmaak en deze post, dan werkt dit goed. Deze omzetting via preg_replace en regular expression werkt dus.
Nu wanneer iemand z'n post wilt editen, moet die BB code wat dus HTML is geworden terug worden omgezet naar BB, nu dit lukt niet.

Kan iemand me helpen ?

PHP:

$bbpost = preg_replace("#<a href=([^\"\"]*)?>([^\"\"]*)([</a>])#e","het werkt", $bbpost);

de input wat deze preg_replace zou moeten verwerken is.

code:

vb.
HTML input = <a href="http://www.tweakers.net" target="_blanc">Tweakers.net</a>
dit zou moeten worden omgezet naar
[url=http://www.tweakers.net]Tweakers.net[/url]

Je gebruikt de 'e' modifier, deze betekend 'execute', dat de tekst dus uitgevoerd zou moeten worden. Uitgaand dat je eerste pattern wel goed is:

PHP:

$bbpost = preg_replace("#<a href=([^\"\"]*)?>([^\"\"]*)([</a>])#si","[url=\\1]\\2[/url]", $bbpost);

zoiets, zou het dan worden

[imp4ct]

.Peter schreef op dinsdag 07 juni 2005 @ 20:12:
[...]


Je gebruikt de 'e' modifier, deze betekend 'execute', dat de tekst dus uitgevoerd zou moeten worden. Uitgaand dat je eerste pattern wel goed is:

PHP:

$bbpost = preg_replace("#<a href=([^\"\"]*)?>([^\"\"]*)([</a>])#si","[url=\\1]\\2[/url]", $bbpost);

zoiets, zou het dan worden

Nope, werkt hier niet. Voor wat staat die 'si' medifier, als 'k mag vragen ?

edit : mijn patern is niet juist, 't is juist hier dat hij problemen geeft, 'k zou graag weten wat er dus fout is aan m'n patern.

[ Voor 22% gewijzigd door imp4ct op 07-06-2005 20:30 ]

[Verwijderd]

Weinig kennis van zaken hebben, en dan een aangedragen suggestie dom/stom noemen.

[imp4ct]

Verwijderd schreef op dinsdag 07 juni 2005 @ 20:27:
Weinig kennis van zaken hebben, en dan een aangedragen suggestie dom/stom noemen.
[afbeelding]

Sorry, niet bedoeld van je te kwetsen of te beledigen. Maar 'k vond het nogal een "te makkelijke" oplossing, want 't is natuurlijk ergens de bedoeling dat ik vlot leer werken met Regular Expressions, want eens je het beheerst is't echt iets heel handig om input te valideren.

[ Voor 5% gewijzigd door imp4ct op 07-06-2005 20:32 ]

[mosymuis]

I_M_P_A_C_T schreef op dinsdag 07 juni 2005 @ 20:25:
[...]
Nope, werkt hier niet. Voor wat staat die 'si' medifier, als 'k mag vragen ?

Clique. Extra parser analyse + incasesensitive dus.

[ Voor 4% gewijzigd door mosymuis op 07-06-2005 20:39 ]

[Verwijderd]

Bij leren werken met regular expressions hoor je ook te leren wanneer je ze moet vermijden. Maar dit is wellicht eerder een normalisatie / optimalisatie kwestie. Dat er iets soms omgezet moet worden is volgens mij bijzaak, in dit geval.

Ik bedoelde te zeggen dat het verstandiger is om alleen van UBB naar HTML te vertalen, en niet andersom. Het scheelt je een keer omzetten, en kost je inderdaad wat ruimte. Maar de winst is dat het ophalen van de gegevens snel gaat, de originele code is opgeslagen zodat je nog kunt editen, etcetera. Als je er een goede reden voor hebt geeft het niet om een oplossing als deze te gebruiken.

Oh, en ik ben absoluut niet beledigd hoor, ik snapte gewoon je reactie niet.

[imp4ct]

Wel ik moet je ergens natuurlijk gelijk geven, deze oplossing zou het omzetten besparen en ik zou inderdaad zeer snel bij m'n code kunnen.

Wat ik er het nadeel van vind, is dus die opslagcapaciteit, maar dit niet alleen. Je moet ook rekenen dat er op posts die op de website staan ook comments kunnen gegeven worden. Nu hier werkt alles natuurlijk ook volgens hetzelfde systeem. Dan zijn er nog wat "post" mogelijkheden voor admin's enzow via het admin-panel enzow. Als je dit allemaal gaat optellen en rekenen dat elke post dus 2x wordt opgeslagen in de DB vind ik dat dan echt wel veel worden.
Daarom dat ik het dus op deze manier wil proberen.

Nu wat ook een oplossing is natuurlijk is de BB code opslaan en alle posts door een filter van HTML te laten lopen zoals jij zelf aangeeft. Maar dit vind ik ook weer niet goed, want dan moet elke post - comment - etc.. telkens helemaal door deze validator, wat in mijn ogen de performance van je website niet ten goede komt.

edit :
'k Ga eens overleg plegen met m'n server-administrator, als diskspace niet echt een grote zorg is, dan toch maar misschien voor de makkelijke oplossing gaan en dan moet ik zeker toegeven. Cheatah je hebt me overtuigd .

[ Voor 38% gewijzigd door imp4ct op 07-06-2005 21:01 ]

[We Are Borg]

Volgens mij (weet het niet zeker) doet react ook alles 2 keer opslaan. UBB en HTML versie. Nu wil ik niet gelijk zeggen dat het daarom een super oplossing is, maar de heren van Parse zijn niet op hun achterhoofd gevallen

[Verwijderd]

Bij React slaan ze inderdaad beide versies op. Bij React draait heel veel om performance, dus ik denk dat ze hier ook wel goed over hebben nagedacht.

Verder scheelt het je gewoon een hoop gedoe, als je de Html enUbb versie opslaat.
En redunantie mag als het je behoorlijke performance winst oplevert.

[compufreak88]

Waarom sla je niet alleen de ubb versie op, en bij het weergeven zet je het om in html...

[Schonhose]

compufreak88 schreef op dinsdag 07 juni 2005 @ 21:37:
Waarom sla je niet alleen de ubb versie op, en bij het weergeven zet je het om in html...

Dit is een uitstekende oplossing welke ik ook gebruik in mijn systeem. Belangrijk is wel of je je moet afvragen of je pagina door vele mensen tegelijk wordt opgevraagd. In dat geval kan er een performance loss plaatsvinden door dat elke keer die omzetting opnieuw gedaan moet worden.

Je bespaart jezelf wel een heleboel werk met de regular expressions.

offtopic:
-NMe-, je waagt het niet om een opmerking te maken over mijn code en performance loss (op hele andere vlakken dan hierboven).....

[NMe]

Schonhose schreef op dinsdag 07 juni 2005 @ 21:51:

offtopic:
-NMe-, je waagt het niet om een opmerking te maken over mijn code en performance loss (op hele andere vlakken dan hierboven).....

Wat betreft wat hierboven gezegd wordt over UBB omzetten als je het nodig hebt: dat wordt hier op GoT ook gedaan, dus lijkt me prima.

offtopic:
Schonhose, preg_match is sneller dan eregi.

[imp4ct]

Schonhose schreef op dinsdag 07 juni 2005 @ 21:51:
[...]
Belangrijk is wel of je je moet afvragen of je pagina door vele mensen tegelijk wordt opgevraagd.

[/quote]

Wat is veel eh, 'k weet nog niet of m'n nieuwe site veel bezoekers zal trekken, hangt er een beetje van af of het concept aanslaat. Maar het zou best kunnen. Ook moet ik rekening houden dat op onze server nog 3 andere sites runnen. 2 Ervan stellen niet zoveel voor, maar op de andere zijn er toch gemiddeld constant 20 - 30 bezoekers online op de website

Dit zijn de serverspec's

ProLiant DL360R03 model 6/3000
1 Xeon cpu 512KB 1024MB (in de 3Ghz)
2gig ram
2x hot pluggable cpu
2x 36gig HDD
OS : Linux

[ Voor 3% gewijzigd door imp4ct op 07-06-2005 22:31 ]

[crisp]

Diskspace is relatief goedkoop over het algemeen, dus daar hoef je het meestal niet voor te laten. Bijkomend voordeel van dubbel opslaan is dat je met versies kan werken. Als je om 1 of andere reden de opmaak van je UBB-omzetting wilt wijzigen is het enkel een kwestie van de versie van je parser ophogen, en oudere berichten kunnen adhv het opgeslagen versienummer bij het bericht automagisch (eenmalig) opnieuw geparsed worden.

Verder krijg je bij terug omzetten ook niet altijd precies het originele bericht terug; vroeg of laat loop je toch een keer tegen problemen op die lastig op te lossen zijn...

[imp4ct]

'k Ben dus maar gegaan voor het opslaan van zowel de UBB als de HTML code. Mits ik door de reacties hier toch heb ingezien dat het meer voor- dan nadelen met zich meebrengt.
Thx for the help

[Cavorka]

Voor eens voor altijd: kan er bij reg-exp vragen niet gewoon gelinked worden naar de RexEx Coach? De oplossing nu is natuurlijk ook goed, maar dat scheelt weer een hoop gepost met al dan niet juist aanwijzingen.

Dus: RegEx Coach.

[chem]

We Are Borg schreef op dinsdag 07 juni 2005 @ 20:55:
Volgens mij (weet het niet zeker) doet react ook alles 2 keer opslaan. UBB en HTML versie. Nu wil ik niet gelijk zeggen dat het daarom een super oplossing is, maar de heren van Parse zijn niet op hun achterhoofd gevallen

Dat klopt.

De reden hiervoor is dat het terugzetten van HTML, met crew die ook nog eens HTML rechten heeft, een rotklus is.
Met name omdat we verschillende RML (ubb) configs per site hebben, die verschillende html onder verschillende omstandigheden kan uitpoepen (en dus per site+config andere resultaten kan geven: een preg_quote op het resultaat werkt dan niet) en last but not least: we werken met RML versies, waarbij een nieuwere 'versie' ook op oude berichten wordt toegepast bij het opvragen van de berichten. Als we dan, naast de hiervoorbeschreven situaties, ook dát nog eens moeten ondersteunen zijn we meer tijd kwijt aan de RML parser, dan aan de rest van React...