Al een paar dagen doe ik ernstig m'n best om de TinyMCE 5 inline editor aan het werk te krijgen.
Dat lukt voor de helft: na het klikken in de div verschijnt de editor op de gewenste manier.
Maar een gewijzigde versie van de inhoud krijg ik met geen mogelijkheid in m'n php script.
Middels gebruik van de <textarea> tag krijg ik de editor permanent te zien, maar dat wil ik nu juist niet vandaar de keuze voor de inline optie.
De inhoudelijke update in het php script werkt echter naadloos.
Kent iemand dit probleem; en nog beter: Hoe kom ik er langs?
Dank voor de reactie.
Dit is een lastig en complex probeem: de reproductie ervan vereist alle code van het gehele (test) project, dat is veel.
In de kern komt het neer op:
1.
Bij gebruik van een <textarea> doet tinymce 5 z'n werk naar behoren en zorgt ervoor dat hij (zij?) de aangepaste inhoud van het tekstgebied via de super global $_POST naar het PHP-script stuurt. Maar dat betekent dat ik dan drie van die uiterst lelijke editors op m'n HTML-pagina moet dulden; en ik krijg ze met geen mogelijkheid weg. De inline optie is niet beschikbaar voor de <textarea> versie.
2.
Het gebruik van <div> tags levert middels de inline optie een mooie presentatie van de editor. De editor verschijnt pas als je op de betreffende <div> klikt. Helemaal goed en precies wat ik wil. Maar, tot dusver zie ik met geen mogelijkheid kans om de aangepaste inhoud van de editor in een element van $_POST te krijgen. Dat ligt natuurlijk aan mij want ze zullen bij tinymce toch niet zo dom zijn om dit over het hoofd te zien? (Verwacht ik, hoop ik).
Is dit nu typisch een geval van: Als het niet kan zoals ik het wil; dan moet ik het maar willen zoals het kan?
Of, heeft iemand dit al eens vóór mij opgelost?
Ah, je wilt de textarea gewoon als textarea blijven gebruiken, naast andere WYSIWYG-velden waar wel de editor wordt toegepast? Ik denk dat dit een kwestie is van initialisatie van TinyMCE is. Je moet TinyMCE dan (nauwkeuriger) vertellen op welke velden deze van toepassing zoud moeten zijn.
Of bedoel je dat het niet mogelijk is om meerdere WYSIWYG-velden te tonen, die initieel verborgen zijn onder een knop ofzo? Dat zou ik dan weer meer in de richting van de identificatie en naamgeving van de velden zelf zoeken. Die velden mogen bijvoorbeeld niet allemaal dezelfde naam/hetzelfde id hebben.
Als je je zaken aan de invoerkant oplost dan zou de uitvoer ook goed moeten zijn, lijkt mij.
Aan de andere kant, waarom zou je met twee verschillende varianten blijven werken? Het zou consistenter zijn als alles gewoon ofwel WYSIWYG is ofwel "rauwe" tekst? Heb je (per se) een combinatie nodig?
En zoals @Ariën aangeeft zou een "werkend" voorbeeld handiger zijn, waarbij je aangeeft wat je anders wilt of uitlegt wat niet werkt zoals jij wilt.
Desnoods met screenshots en wat snippets code, je hoeft hier niet alle code te dumpen of ergens een online voorbeeld te hebben. Maar dat zou natuurlijk wel handiger zijn.
https://ibb.co/TwV7ZgS
https://ibb.co/v1JTjV0
Het plaatje zonder zichtbare presentatie van de editor, is zonder dat er op de inhoud van de div is geklikt.
Het plaatje met zichtbare presentatie verschijnt als je op de te wijzigen tekst in de div klikt.
De code die dit feest bereikt is:
[size=xsmall]Toevoeging op 04/10/2019 17:56:11:[/size]
Nou, dit is duidelijk NIET de code die ik heb geplakt.
Als je de verkeerde code plaatst, dan kan je je bericht aanpassen door op te klikken, en je kan je code tussen [code] en [/code] plaatsen, zodat deze in een geheel codeblok komt te staan met regelnummering en dergelijke.
In de Veelgestelde Vragen staat halverwege een overzicht met alle opmaakcodes die op de site gelden.
Allereerst: in bovenstaande code zitten dubbele id's. Verdere correcte werking is dus sowieso al discutabel omdat je HTML document niet in orde is.
Ten tweede: als je iets POST via AJAX ($.post) dan moet je natuurlijk het formulier niet alsnog POSTen. Na het uitvoeren van $.post is het nog steeds "business as usual". Dus als je niet aangeeft dat het formulier na afloop niet gesubmit moet worden (omdat je dit dus al via AJAX had gedaan) dan wordt je formulier alsnog gesubmit. En dan zit je POST data in "excerpt" of wat dan ook, en niet in "pvpVar". Het was dus ook niet zo handig om die empty($_POST['phpVar']) conditie op te nemen voor het dumpen van $_POST, je belemmert hier zelf in wezen de debugging van $_POST mee, en dan had je direct gezien dat er dingen misgaan.
Je bent ook niet zozeer geïnteresseerd in het klikken op een button, maar op het submitten van het formulier zelf. DAT moet je afvangen. Een betere check zou dan ook de volgende zijn:
<!DOCTYPE html>
<html>
<head>
<title>jQuery form submit test</title>
</head>
<script
src="https://code.jquery.com/jquery-3.4.1.min.js"
integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo="
crossorigin="anonymous"></script>
<body>
<form id="myForm" action="ajax.php" method="POST">
<input type="text" name="woops" id="woops">
<button type="submit">go</button>
</form>
<script type="text/javascript">
//<![CDATA[
$().ready(function() {
$('#myForm').submit(function(e) { // capture the submit event
e.preventDefault(); // do not go through with default behavior (actually submitting the form)
$.post(
'ajax.php',
{
'ajaxWoops': $('#woops').val()
},
function(data) {
alert('done');
}
);
});
});
//]]>
</script>
</body>
</html>
ajax.php
<?php
header('Content-Type: text/html; charset=UTF-8');
function escape($in) {
return htmlspecialchars($in, ENT_QUOTES, 'UTF-8');
}
function dump($in) {
if (is_array($in)) {
$in = print_r($in, true);
}
echo '<pre>'.escape($in).'</pre>';
}
if ($_SERVER['REQUEST_METHOD'] == 'POST') {
dump($_POST);
}
?>[end]
Als je dus die "e" en "e.preventDefault()" weglaat dan zul je zien dat er een element "woops" (oorspronkelijke naam in form) en niet "ajaxWoops" in het POST array zit. En je komt ook bij ajax.php uit omdat dat de action was.
te klikken, en je kan je code tussen [code] en [/code] plaatsen, zodat deze in een geheel codeblok komt te staan met regelnummering en dergelijke.