[PHP] Tekst tussen <pre> tags afvangen

[Reveller]

Ik probeer een regex te schrijven die alle tekst tussen <pre>-tags afvangt:

PHP:

$content = 'Hele hoop tekst <pre class="php">dattes</pre>. 
            Nog meer tekst <pre><p>HTML uitleg</p></pre>';

preg_match_all("/<p(.*?)>(.*?)<\/pre>/", $content, $matches);

De bedoeling is een array terug te krijgen als volgt:

code:

Array
(
    [0] => dattes
    [1] => <p>HTML uitleg</p>
)

Ik krijg echter:

code:

Array
(
    [0] => Array
        (
            [0] => <pre class="php">dattes</pre>
            [1] => <pre><p>HTML uitleg</p></pre>
        )

    [1] => Array
        (
            [0] => re class="php"
            [1] => re
        )

    [2] => Array
        (
            [0] => dattes
            [1] => <p>HTML uitleg</p>
        )

)

Ik zit nu al uren te prutsen met de Regex Buddy, maar die helpt mij ook niet verder. Hoe haal ik in $matches de hele match en de match van de openings-tag weg?

[crisp]

Je hebt sowieso een extra capturing subpatern die je niet gebruikt - haal die haakjes daar gewoon weg.
Bekijk deze output eens:

PHP:

$content = 'Hele hoop tekst <pre class="php">dattes</pre>. 
            Nog meer tekst <pre><p>HTML uitleg</p></pre>';

preg_match_all("/<pre[^>]*>(.*?)<\/pre>/", $content, $matches);
print_r($matches[1]);

[Osiris]

Hm, crisp, volgens de PHP manual staat de '^' voor 'negate the class, but only if the first character', alleen Joost mag weten wat dat betekend?

[NMe]

Als je op <pre>-tags wil matchen, waarom verzin je dan /<p(.*?)>(.*?)<\/pre>/ als regexp? Waarom p en niet pre? Let je trouwens wel even op dat deze regexp case sensitive is, en die van crisp ook?

[NMe]

Osiris schreef op dinsdag 04 oktober 2005 @ 23:13:
Hm, crisp, volgens de PHP manual staat de '^' voor 'negate the class, but only if the first character', alleen Joost mag weten wat dat betekend?

[^>] betekent 'elk karakter behalve >'
[>^] betekent 'ofwel >, ofwel ^'

[Osiris]

-NMe- schreef op dinsdag 04 oktober 2005 @ 23:16:
[...]

[^>] betekent 'elk karakter behalve >'
[>^] betekent 'ofwel >, ofwel ^'

Aha, thnx, gekke vage zin met 'negate' enzo, komt niet in mijn idioom voor

[Borizz]

Osiris schreef op dinsdag 04 oktober 2005 @ 23:13:
Hm, crisp, volgens de PHP manual staat de '^' voor 'negate the class, but only if the first character', alleen Joost mag weten wat dat betekend?

Dat klopt toch ook, er staat nu dat het alles mag zijn behalve een '>' (die volgt daarna namelijk nog).

edit: hmmm misschien iets eerder moeten refreshen .

[ Voor 12% gewijzigd door Borizz op 04-10-2005 23:23 ]

[Reveller]

-NMe- schreef op dinsdag 04 oktober 2005 @ 23:15:
Als je op <pre>-tags wil matchen, waarom verzin je dan /<p(.*?)>(.*?)<\/pre>/ als regexp? Waarom p en niet pre?

Dat was een typvoud

Let je trouwens wel even op dat deze regexp case sensitive is, en die van crisp ook?

Daar moet ik nog wat aan doen.

De bedoeling is dat als iemand in mijn CMS tussen <pre >- tags html zet, deze html niet geparsed wordt. Hiertoe heb ik nu het volgende:

PHP:

$content = 'Hele hoop tekst <pre class="php">dattes</pre>. 
            Nog meer tekst <pre><p>HTML uitleg</p></pre>';

preg_match_all("/<pre[^>]*>(.*?)<\/pre>/", $content, $matches);

foreach ($matches[1] as $pre) {
  echo htmlentities($pre);
}

Nu heb ik weliswaar de < pre> delen gematched, en alles daarbinnen vervangen door html entities, maar hoe krijg ik dit nu op de goede plaats in $content terug? Volgens mij bewandel ik een verkeerde weg...

[ Voor 78% gewijzigd door Reveller op 04-10-2005 23:32 ]

[NMe]

Het zou makkelijker gaan met een stack based parser, maar in principe zou je er ook uit moeten komen door de index in het $matches array te gebruiken in combinatie met strpos. Daarbij geldt dan wel dat elke <pre> ook daadwerkelijk afgesloten moet zijn, anders loopt alles mis.

[crisp]

of met een callback (of desnoods met de e-modifier):

PHP:

$content = 'Hele hoop tekst <pre class="php">dattes</pre>. 
            Nog meer tekst <pre><p>HTML uitleg</p></pre>';

$content = preg_replace_callback('/(<pre[^>]*>)(.*?)(<\/pre>)/i', 'tag_pre', $content);

echo $content;

function tag_pre($matches)
{
    return $matches[1] . htmlspecialchars($matches[2]) . $matches[3];
}

maar stackbased is meer fail-safe en biedt meer mogelijkheden.

[Reveller]

crisp, -NMe-, bedankt voor jullie snelle reakties. De code van crisp hierboven werkt de gegeven content, maar in dit geval worden de bold-tags gewoon geparsed en niet omgezet naar htmlentities. Enig idee waarom niet?

PHP:

$content = "<pre>
switch ($status) {
  case MENU_NOT_FOUND:
    not_found('<b>Pagina niet gevonden</b>');
    break;
  case MENU_ACCESS_DENIED:
    access_denied('<b>Geen toegang</b>');
    break;
}
</pre>";

$content = preg_replace_callback('/(<pre[^>]*>)(.*?)(<\/pre>)/i', 'tag_pre', $content);

echo $content;

function tag_pre($matches) {
    return $matches[1] . htmlspecialchars($matches[2]) . $matches[3];
}

Een vraag van algemene aard: wat is eigenlijk het voordeel van een UBB parser boven het direct intikken van HTML? Zoveel eenvoudiger is het toch niet uit te leggen dat een link [ url=http://www.link.com] zo gemaakt moet worden[/url] dan < a href="www.link.com">zo</a>? Het enige voordeel zie ik bij constructies als [image=43], in plaats van een complete image tag te moeten tikken. En later zou je altijd nog eens de image tag-constructie zelf kunnen aanpassen, en alle UBB [image] tags veranderen dan gewoon mee. Is dat meteen ook de hoofdreden of zijn er meer argumenten te geven voor het maken van een UBB (ook binnen een CMS?) in plaats van het direct laten intikken van HTML?

[crisp]

je moet nog een s-modifier toevoegen voor line-spanning

[Reveller]

crisp, Dank je. Ik heb meteen op de PHP Pattern Modifiers pagina gekeken of ik nog andere patterns nodig zou hebben, maar kon er geen meer vinden. Ik ben nu zover dat ik regenummers aan de <pre>-tekst wil toevoegen:

PHP:

function tag_pre($matches) {
  $source = explode("\n", trim($matches[2]));
  $count = sizeof($source);
  for($i = 1; $i <= $count; $i++) {
    if ($source[$i] == '') {
      $output.= "\n";
    }
    else {
      $output.= "<span>$i</span> " . htmlspecialchars($source[$i]);
    }
  }

  return $matches[1] . $output . $matches[3];
}

Als er lege regels in de tekst tussen de <pre> zitten, probeer ik deze in de output ook leeg te laten door een newline in te voegen (zie regels 5 en 6). Dit werkt echter niet. Als ik de volgende tekst door tag_pre haal:

code:

<pre class="php">
include_once 'includes/common.inc';
include_once 'includes/bootstrap.inc';

fix_gpc_magic();

odisys_page_header();

$status = menu_execute_active_handler();

switch ($status) {
  case MENU_NOT_FOUND:
    not_found();
    break;
  case MENU_ACCESS_DENIED:
    access_denied();
    break;
}

drupal_page_footer();

echo theme_print();
</pre>

De $source array die in regel 2 van de functie wordt aangemaakt, ziet er hierbij als volgt uit:

code:

Array
(
    [0] => include_once 'includes/common.inc';
    [1] => include_once 'includes/bootstrap.inc';
    [2] => 
    [3] => fix_gpc_magic();
    [4] => 
    [5] => odisys_page_header();
    [6] => 
    [7] => $status = menu_execute_active_handler();
    [8] => 
    [9] => switch ($status) {
    [10] =>   case MENU_NOT_FOUND:
    [11] =>     not_found();
    [12] =>     break;
    [13] =>   case MENU_ACCESS_DENIED:
    [14] =>     access_denied();
    [15] =>     break;
    [16] => }
    [17] => 
    [18] => drupal_page_footer();
    [19] => 
    [20] => echo theme_print();
)

Dan ziet de output er in de browser als volgt uit:

HTML:

1 include_once 'includes/bootstrap.inc';
2 3 fix_gpc_magic();
4 5 odisys_page_header();
6 7 $status = menu_execute_active_handler();
8 9 switch ($status) {
10   case MENU_NOT_FOUND:
11     not_found();
12     break;
13   case MENU_ACCESS_DENIED:
14     access_denied();
15     break;
16 }
17 18 drupal_page_footer();
19 20 echo theme_print();

Met andere woorden, de lege regels 2, 4, 6, 8, 17 en 19 krijgen geen newline in de output. Ook "\n" vervangen door <br> werkt niet. Wie ziet wat ik fout doe?

[Bosmonster]

Reveller schreef op woensdag 05 oktober 2005 @ 10:47:
Een vraag van algemene aard: wat is eigenlijk het voordeel van een UBB parser boven het direct intikken van HTML? Zoveel eenvoudiger is het toch niet uit te leggen dat een link [ url=http://www.link.com] zo gemaakt moet worden[/url] dan < a href="www.link.com">zo</a>? Het enige voordeel zie ik bij constructies als [image=43], in plaats van een complete image tag te moeten tikken. En later zou je altijd nog eens de image tag-constructie zelf kunnen aanpassen, en alle UBB [image] tags veranderen dan gewoon mee. Is dat meteen ook de hoofdreden of zijn er meer argumenten te geven voor het maken van een UBB (ook binnen een CMS?) in plaats van het direct laten intikken van HTML?

Het voordeel van ubb (of wat voor eigen formaat dan ook) is dat je de volledige controle hebt over wat mensen kunnen gebruiken en hoe dit eruit komt te zien.

[Reveller]

Bosmonster schreef op woensdag 05 oktober 2005 @ 12:28:
[...]
Het voordeel van ubb (of wat voor eigen formaat dan ook) is dat je de volledige controle hebt over wat mensen kunnen gebruiken en hoe dit eruit komt te zien.

Mja, dat dacht ik ook al. Ik kan me voorstellen dat het handig is als je UBB-tags maakt van de vorm [kader=Mijn kader]Deze tekst komt in een mooi vormgegeven kader met als titel "Mijn kader"[/kader]. En als de <b>-tag depreciated wordt en vanaf nu <strong> de voorkeur krijgt, hoef je alleen je UBB-parser maar aan te passen ([b] wordt <strong>) in plaats van dat je alle hardcoded getikte html <b>-tags in de content in de database zou moeten veranderen. Wat ik me wel afvraag: veel GoT'ers zeggen in hun CMS een WYSIWYG editor aan te bieden. Daarmee vervalt dan het grote voordeel van een UBB editor. In hoeverre bieden jullie (vaak niet technische onderlegde klanten) UBB editors aan in plaats van WYSIWYG editors, omdat de consistentie zo meer bewaakt wordt?

Overigens - ik hoor het nog steeds graag als iemand een oplossing heeft voor mijn probleem 2 posts hierboven. Kom er nog steeds niet uit.

[Swaptor]

@TS: heb je nl2br() al geprobeerd?
Werkte iig in mijn geval perfect.

http://www.php.net/nl2br

[RwD]

Reveller schreef op woensdag 05 oktober 2005 @ 16:00:
[...]
Wat ik me wel afvraag: veel GoT'ers zeggen in hun CMS een WYSIWYG editor aan te bieden. Daarmee vervalt dan het grote voordeel van een UBB editor. In hoeverre bieden jullie (vaak niet technische onderlegde klanten) UBB editors aan in plaats van WYSIWYG editors, omdat de consistentie zo meer bewaakt wordt?

Theoretisch, zou je, met een beetje moeite, de html die je uit een wysiwyg kunnen parsen en omzetten naar ubb. En als je het wil editen weer naar html...