As you can imagine allowing a user to put arbitrary code into a textbox is a security issue. This would create a situation where the user might put in some harmful code and then it be executed on their site. This is probably why the interactivetools team made sure to run the field through an encoding/escaping function so that it will print the characters of the code rather than run the code itself.

One solution you might want to try is to find out what part of the paypal code is dynamic (like a special product number etc.) and then have the user enter that into the textbox. Then when it comes to writing PHP out to their page, you can write in the paypal snippet, placing the product number into the snippet itself. Of course still make sure you validate the user input before putting it into the snippet.

For example, let's assume the paypal code uses a special product number to print out the buttons. Maybe the code looks like (and this is me just making stuff up here)...

<button id="paypal" data-product-num="12345">Pay on PayPal</button>

What you would do is create the text field to collect the "12345" product number and then in the PHP that generates the page you could use that...

<?php

$prodNum = intval($prodRec['prodNum']);

if (($prodNum > 0) && ($prodNum <= PHP_INT_MAX)) {

   echo "<button id=\"paypal\" data-product-num=\"{$prodNum}\">Pay on PayPal</button>";

} else {

  echo "Invalid product number!";

}

?>

Hopefully you get the idea of what we are doing here. With this type of approach you control the output of the paypal code and allow the user the option to put in the dynamic parts to customize the button. You can also control the validation of that dynamic value the user entered.

The other option is for the interactivetools team to put in a new field type tailored for things like paypal buttons or the like. Where essentially the code generator would do what I just showed you above.

I hope this helps. :)

What Robin suggested is the right approach, but I suggest that instead of just looking at quotes, you do a bit more to make sure things are secure. If you don't escape the values, you could open yourself up a security attack known as cross-site scripting attack (XSS). This allows someone to put some random code into the values for the user's name or address and when you echo it out to the user it will then run the attackers JavaScript as coming from you and can be used to hijack user's sessions etc. with other sites.

One way you can mitigate this issue is using the PHP function json_encode() to escape the code and make it safe for JS display. Below is an example...

<script>

  const jsUsernameSafe = <?php echo json_encode($username); ?>;

  alert(`Your username is ${jsUsernameSafe}`); //<-- Notice the use of backticks here for a template string literal (interpolation)

</script>

You may also want to just make sure that the user's name and address are not empty either an account for that. Not the greatest experience to say "Hello <blank>!" 

I hope this helps! :)

Yeah dealing with FK columns can always be tricky when it comes to moving schemas between databases. However, if you disable the FK check constraints as you suggested earlier, I don't see why you would need to go through the whole process of deleting columns and renaming tables (assuming the target system is fresh).

It should just be a matter of disabling the FK constraints for the database, copy over the schemas and then re-enabling the constraints. 

I agree that simply trying to create tables alphabetically without disabling the FKs is going to give you issues, but disabling the FKs should also allow you to create the tables in any order you want. It turns out to be a pretty much straight copy over operation at that point since no referential integrity checks are being done with the FKs. 

If cmsbuilder doesn't disable the keys first then obviously that would be the issue. The rest should be pretty straight forward if I understand things correctly.

Now... if you are changing the table names for other reasons (like a custom prefix you want to use for the new database) then obviously you will have to update the FKs to point to the right tables. 

It just sounds like a lot of work you are going through to achieve something that should be a bit simpler. :)

So what you show there is the PHP code used to generate the HTML. Do you have this page hosted on the public web so we can visit it? I think what we need to see is the resulting HTML generated by this PHP. I am assuming that the script looks at the resulting HTML code and uses that to build the PDF. If the PHP generates a relative link or a link that is pointing to a file that doesn't exist, it may then have the issue. If we can see the page up on the new server, we can look at the source code and see if there are any links/resources there that may be an issue.

Hopefully you get what I am saying. :)

It seems you are on the right track and this error seems to be involving one of many scenarios...

1. It is a relative URL that it is having trouble with
2. It is running across a link which is broken or the resource is not available (like missing a linked file or something like a font file)
3. If a link is returning something like a 403 response (forbidden) 
4. It is choking on some JavaScript (but this seems to be a bit of an outlier)

I think what might help is to show us what is the HTML you are trying to convert and perhaps we can see something you are missing.

I guess the wkhtmltopdf can be a bit finicky at times and so something minor could be the problem. I am guessing that if you had it working before on the other server, perhaps you missed transferring a file to the new server or the new server is not allowed to access something that the original server could. I would start with the HTML you are trying to convert and work from there. :)

Nice addition Jeff. :)

I noticed that the server is sending webp files as an incorrect mimetype of

application/octet-stream

instead of being image/webp. Think of mimetypes as a way for a server to tell a browser the type of file it is. This means when the browser encounters such a file it will do something different than other file types. Some browsers will just download the file (which seems to be the default for Chrome) while others will open it in a new tab (which seems to be the default for Firefox). 

I think the solution here is for the server to make sure it is serving webp files with the correct mimetype. It is probably not this way by design and needs a simple mimetype association on the web server to fix it. It is nothing wrong on your side. 

I think you caught a nice little oddity here. :)

I am new to CMS Builder but I thought I could pitch in with an answer. Dave's solution will work, but is missing a few more details. 

On the textarea element with the name "optionsQuery" a few lines up from the "Available vars" line, add two additional attributes. One is

id="optionsQuery"

and another is...

style="height: 300px;"

So in the end your textarea element should look like the following...

<textarea name="optionsQuery" id="optionsQuery" cols="60" rows="3" style="height: 300px;" class="form-control text-nowrap setAttr-spellcheck-false textareaGrow" data-growsize="10"><?php echo htmlencode($field['optionsQuery']) ?></textarea>

I believe after this change, the JavaScript Dave gave you should turn that box into an editor box with line numbers. Attached is a screenshot.

Now of course I don't know if it is safe to edit these files and if they will be overwritten by future updates, but at least it can get that working for now and perhaps Dave's team can then put it in as part of core.

I hope this is what you were looking to do. :)

I am new here but I thought perhaps I can chime in and give you a solution to the problem. I am assuming you have the latest version but if you do:

1. Go to CMS Setup
2. Then select the Database Editor
3. Modify the given section you are working with (in my case "News" as outlined in the tutorial)
4. Find your image upload field and select "Modify"
5. Under input validation you will see sections for creating thumbnails. By default it looks like it only creates 1, but you can select to have it generate up to 4 and specify the dimensions for each. You could just make one of those 100 x 100 and it will generate a thumbnail image for each size you specified. I attached a screenshot.

Then in your templates you can access these other thumbnails using code like...

<img src="<?php echo htmlencode($upload['thumbUrlPath2']) ?>" width="<?php echo $upload['thumbWidth2'] ?>" height="<?php echo $upload['thumbHeight2'] ?>" alt="">

<img src="<?php echo htmlencode($upload['thumbUrlPath3']) ?>" width="<?php echo $upload['thumbWidth3'] ?>" height="<?php echo $upload['thumbHeight3'] ?>" alt="">

<img src="<?php echo htmlencode($upload['thumbUrlPath4']) ?>" width="<?php echo $upload['thumbWidth4'] ?>" height="<?php echo $upload['thumbHeight4'] ?>" alt="">

It looks like by default the system will support up to 4 thumbnails and you can have those thumbnails either "crop" or "recreate". I think if you go back and reattach any images on older items it will regenerate those new thumbs. This process I outline here would then work for all new items going forward. Hopefully that solves the issue for you. :)