Jump to content

Markup field in page editor


MaryMatlow
 Share

Recommended Posts

At page editor level I need to place a piece of code which is unique to that page. This is the code:

<healcode-widget data-type="class_lists" data-widget-partner="mb" data-widget-id="xxxxxxxx" data-widget-version="0.1"></healcode-widget>

This code pulls in data from a third-party site. The Body Field won't accept this code. I could place this in the template file but for that I'd have to crate a separate template file for each page. I'd rather use a common "basic_page" template file for most pages. Also, I would like to give the client the ability to change/edit code when necessary if it is at page editor level. Is there any way to achieve this? Thanks.

Link to comment
Share on other sites

CKEditor is stripping out your code since <healcode...> is not a valid HTML tag. You can tell it, via its ACF and/or Extra allowed content settings, to allow that tag, though am not sure even that  would work.

Another possibility is to use Hanna Code to insert that code at runtime. Parameters would have to be passed to it (the values you want the client to be able to change) so as to render them at runtime. The Hanna Code would be could like so in your body field:

[[widget a=value1 b=value2 c=value3]]

where a, b and c are the parameters whose value the editor can change. You can rename them to something your client would understand, e.g. type,partner,id, etc...However, do you still want your client to be editing the Hanna Code like that? Alternatively, you can create a field(s) to store your editable values and via the Hanna Code, tell it to read from that field(s). Or, if the values will always be coming  from a set pool, you can save them beforehand to a pagefield. The client would then have select the applicable values in that pagefield. Hanna Code would then grab the values from that pagefield. Note that the above is not the Hanna Code code itself; just how to call it on your page. 

Anyway, please describe your scenario with a bit more specifics so that we can tailor our responses to that.

  • Like 5
Link to comment
Share on other sites

@kongondo I did take a look at Hanna Code but really wouldn't know how to set it up. As I explained, I've to put this code snippet at the page editor level, to pull in data from server. I need to pull different data on different pages so that's why can't put in one common template. There is nothing much to it.

@Robin S Yes it would occur in the same place, but the thing is I want to use the same template for all pages rather than creating separate ones. What field type would I use to place the code snippet into. I tried textarea fieldtype but it didn't work.

Link to comment
Share on other sites

If you use Hanna Code, you will place the Hanna Code in the RTE textarea of your page ,e.g. 

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras et rhoncus nisl, a facilisis turpis. Integer sit amet fringilla velit, quis lobortis leo. Aliquam vitae ante tristique, sollicitudin est sit amet, scelerisque leo.

[[widget]]

Pellentesque iaculis mi dolor, id pretium dolor pellentesque eu. Proin in tincidunt mauris, eget facilisis nibh. Mauris eget euismod magna. Nunc eu mi pellentesque justo pharetra dapibus.

The 'widget' will be read by Hanna Code and it will apply the PHP code present saved for that widget in Hanna Code editor. I can give you example code. All your clients would have to do is to put [[widget]] on each page, or if passing values, [[widget data_type=whatever, etc]]. Would they be able to do that.

As for the other alternative, you could use a normal textarea without RTE and instruct the Hanna Code [[widget]] to get its values from that textarea. Hope this makes sense.

Edit:

Beaten by Robin S. :)

More thoughts:

Scenario 1

If your widget code will be place before or after your body text, then you don't need Hanna Code; only a non-RTE textarea field. In your template you would have two fields. One is your RTE textarea and the other the non-RTE one. In the RTE enter body copy as normal. In the non-rte one, let's call it widget_textarea, your editors will place the code. If the whole code will be changing, as opposed to parts of it, then they will put in that textarea the whole code. You will then only have to do the following in your template file

echo $page->body;// RTE body copy
echo $page->widget_textarea;// will echo your <healcode-widget></healcode-widget> code

Scenario 2

If your widget code will be appearing in between text, then you can either use Hanna Code only or a combination of Hanna Code and the widget_textarea. Then in your template file, you would only need to do the following:

// since the body field has the Hanna Code, whatever that Hanna Code is returning will be displayed in the place where you placed [[widget]]
// it will be specific to the page being viewed
echo $page->body;

If you want to go with Hanna Code, let us know and we'll give you example code

  • Like 3
Link to comment
Share on other sites

4 hours ago, MaryMatlow said:

I had been reading that Processwire is structured in such a way that all code is kept out of page edit level because of security concerns. Should I be worried about using code here?

Well, you should be a bit wary in that a person with edit access to the page could insert some malicious Javascript. If the person editing the website is the site owner then of course they would have no reason to do such a thing.

As a general principle I think you should only make editable the parts of the code that it is essential to keep editable. For example, if your client only needs to change the "data-widget-id" attribute then make a text field just for that part and keep the rest of the snippet static in your template file. As an added benefit it also minimises the chances that they accidentally mess up the snippet code.

  • Like 1
Link to comment
Share on other sites

What Robin S said.

Security

How does the widget communicate with the third-party server? Is that something in your control? Are there risks if the communication was intercepted?

User-Friendliness

As a general rule, I would never put any sort of code in front of editors, unless I have to. Edit 10 or 15 pages and one widget starts to look like another, we miss or add an extra apostrophe here and there, and soon, it gets a bit messy and our code trips.

In addition, the editors will probably be copying and pasting and that's somewhat tedious. Other than that, it doesn't look too friendly :). OK, we can mitigate this by asking the client to enter something like this in the text/textarea field

type:class_lists,partner:mb,id:123456WB,version:0.1

OK, a bit of progress, but that's still a bit cryptic for some clients. The ideal situation would be to create one input per editable-value. That would mean 1 field per editable-value. Maybe an overkill (to some). Better yet, I would create a custom field that will hold all those n number of inputs for n number of editable-values. The advantages of this are:

  1. It is user-friendly
  2. It is easy to sanitize and validate each individual input
  3. If needed, we can query each of those fields (e.g. in case we have lots of pages and need to find those that contain xxxx in their ID in order to edit them)
  4. Etc... :)

Below is an example custom widget field as per above. It is not very difficult (if you are a developer) to create one based on the Events Fieldtype.

Just my 2p. Something to consider.

widget-mockup-field.png

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...