Is there any way to execute PHP loaded from textarea fields?

[DZoneRick]

My site has several pages that require access to one-off scripts the rest of the site doesn't use. To keep pages loading as fast as possible we don't load these scripts on every page. Instead, we typically include them on a per-page basis in an extra block loaded after the footer html.

When I first started trying to port to PW I added textarea fields for "extra_head" and "extra_footer" into my primary template, and I hoped I could include these script loading directives in the "extra_footer" block and be off to the races. In fact, this would have worked beautifully if I had hard-coded paths for these scripts.

There's the rub, however! I was trying to do things the PW way, so I used the php directives to get the path to my site's "templates" folder. When I output this "extra_footer" field in the page, the php doesn't get executed, so I never get the script path, and the whole thing fails.

<script src="<?php echo $config->urls->templates?>static/js/jquery.isotope.js"></script>

I don't know if I have output the field in my template the wrong way, so maybe there's some other php or api call that will cause it to actually interpret the code in this field during output? Here's what I have used:

<?php echo $page->extra_footer; ?>

I had this problem in other places, too. For example, during the port of the site we decided to start out with a "body" textarea that we bulk-dropped the html markup from the previous site into. This html had references to images and other static resources that we tried to access with the same type of php path reference as in the example above. Of course, none of it worked because that php code never gets executed.

Is there a way to have the php in fields get executed during the page production? If not, is there some other reasonable way to get the path to site resources like scripts and general-purpose images (that wouldn't usually be included in a page's "images" field?

Thanks,

Rick

[DaveP]

If I understand your question correctly, I tend not to include code in the page fields, but do it at a template level.

Say you have the usual kind of template file, such as you'll see in the default PW profile -

<?php

include('./head.inc');

echo $page->body;

include('./foot.inc');

and foot.inc reads something like this

<script
	type="text/javascript"
	src="<?php echo $config->urls->templates; ?>scripts/plugins/jquery.min.js"></script>
</body>
</html>

I'll add an extra bit to foot.inc thus

<script
	type="text/javascript"
	src="<?php echo $config->urls->templates; ?>scripts/plugins/jquery.min.js"></script>
<?php echo $extrajs; ?>
</body>
</html>

Then wherever it is needed in the template (say on home.php because you need an image carousel) I'd put the carousel code and create the <script> tag for the footer in $extrajs

$extrajs = "<script type='text/javascript' src='{$config->urls->templates}scripts/carousel.js'></script>";

So that when that is echoed in foot.inc, it shows correctly.

[Joss]

Generally, putting code via fields is not a great idea.

Without creating lots of different template files for lots of pages, you can get clever. So, for instance you can use a bit of php on the template file to include some extra script on a certain page only.

<?php

if($page->name = gallery){
   echo "<script ........ >";
}

?>

You can also use a text field or text area to list some names of scripts, eg:

gallery fancybox tabs

Each with just a space between them

Then, grab the field in your template file and turn it into an array using the space between each word to split up the words:

$myScriptArray = $page->myscriptfield;

$myScripts = explode(" ", $myScriptArray);
 

Now you can loop through them and do different things with them:

foreach($myScripts as $myScript) {

  if($myScript == gallery) echo "<script gallery.....>";
  if($myScript == tabs) echo "<script tabs.....>";
}

And so on.

WARNING!

I am not a php expert (or even much of a beginner) so I may have made mistakes above, or someone might have  a neater solution

[DZoneRick]

Thanks for your replies, guys. Honestly, we recognize that this idea of code in templates is not the normal "best practice" pattern by a long shot, but AFAIK there is no sanctioned way to include a reference to the templates directory path in markup that you include in a textarea block. This is the real problem!

I don't want any elaborate logic coded into a page field, I just want a simple way to acquire the correct path to the templates dir and all the static resources it contains like images and scripts, etc.

We specifically do NOT want to include these extras on every page, so we'd like to avoid adding them to the main"footer.inc" file we're using. For the moment we've added some sketchy conditional code into that file to check the page title and only include the page's extra script if it matches on the title. This is a poor resolution, however, because it breaks as soon as the page title gets changed.

Working with FormBuilder (just purchased, loving it!) today I noticed that it can apparently do replacements inside a textarea field (which is how it does the easy embed.) I'd like to propose a few critical tag values that could be used inside markup to provide a less brittle way to acquire the correct, current path to the templates dir and resources within it.

Thanks,

Rick

[pwired]

I think this is where modx evo shined with template variables that you could fill with custom html, css or js for a specific page.

[SiNNuT]

This is not an answer to your question but couldn't you just add a checkbox field to the templates you desire and just check for that in your footer.inc?

pseudo: if page->loadextrastuff is checked load extra stuff code

Allowing php code to be executed from user generated content/input sounds horrible.

[Joss]

On some of mine I include all kinds of variables - but I have a habit of creating libraries of them as includes or css files and then using page fields or other ways of just sticking them all over the place.

But I think with including a <script> one of the easiest ways is to just use a term so you can say IF this then include THAT.

THAT can be anything from just a script reference, to a whole ton of code - doesn't matter really. It could even just be a trigger to include another file which has lots of bits in it.

You can put that code in your footer and if it does not exist, then it just gets ignored.

Very simple that way. I know you have to update your footer, but then, you would have had to FTP the script up in the first place.

Having said all that, with things like galleries/carousels and so on, I tend to have a dedicated template file because the layout is very different. So this is not an issue.

As Sinnut says, allowing php code to be executed through a field does sound a bit horrible!

[Wanze]

We specifically do NOT want to include these extras on every page, so we'd like to avoid adding them to the main"footer.inc" file we're using. For the moment we've added some sketchy conditional code into that file to check the page title and only include the page's extra script if it matches on the title. This is a poor resolution, however, because it breaks as soon as the page title gets changed.

The possibilities are endless in Pw to achieve what you want.

Some Possibilities:

• Don't use $page->title but $page->id instead - this id is unique even if you change the title
• Better: Give the pages you need the additional js the same template => this way you only have to check for the template
• Add a checkbox field to the template(s) of pages that need the additional stuff and check if this is set

If you really, really need to access the templates url from inside a textarea, you could do something like this:

//in Textarea
blu blu blu {{templates}} blub blub blub

//In template
$blub = str_replace('{{templates}}', $config->urls->templates, $page->blub);

@pwired

What?

In Pw your fields ARE the template variables, just more flexible.

Who stops you from adding html/css/js into a textarea field in ProcessWire?

[Soma]

You can enter any php code in text and use eval like modx, but that's horrible practice not shining.

[pwired]

In Pw your fields ARE the template variables, just more flexible. Who stops you from adding html/css/js into a textarea field in ProcessWire?

Yes, you are right about that. It´s just that I´m porting 2 of my websites to PW, seeing how it was done with template variables in modx evo, that´s why I came up with it. Actually, I appreciate your reply because I didn´t

see it, in that so obvious comparison. I guess I still have to get used on switching to my new work in PW.

You can enter any php code in text and use eval like modx, but that's horrible practice not shining.

Yup, but not everybody is a high skilled coder like you are Soma. For the time being I have to do it that way

[Soma]

I get it that it can be useful to have this option (and there is).

But isnt it a two sided sword? You said to make pages load as fast as possible... But this technique also means when I browse your site to these pages I have to load extra files not there before and not cached yet. I get it that when therea really huge scripts needed on different pages it can be useful. But how aboit require.js?

[DZoneRick]

@Soma, I guess there's no way to avoid the latency on the first request for something that's not locally cached. But that's not the main point, anyway. The issue is that there's no obvious sanctioned way to acquire the path to the template resources from within markup. Something like a template path tag would be helpful.

I get it that it can be useful to have this option (and there is).

But isnt it a two sided sword? You said to make pages load as fast as possible... But this technique also means when I browse your site to these pages I have to load extra files not there before and not cached yet. I get it that when therea really huge scripts needed on different pages it can be useful. But how aboit require.js?

[DZoneRick]

You can enter any php code in text and use eval like modx, but that's horrible practice not shining.

There is nothing horrible about wanting a way to use your site's templates and static file resources from within markup in a body field.

@Wanze's method above is clever and will likely work, but it would be so much better for this to simply be present at the system level.

[Soma]

Pw has no template tag language and will never have in core level. However this is an easy task and would make a simple textformatter module. Basicly what wanze does but more convenient.

[DZoneRick]

I imagine we've all heard the old saying about "When the only tool you have is a hammer, then all problems start looking like nails." I am a longtime advocate of separation of data from presentation, and I think ProcessWire's templating approach is really cool. That said, however, there are a lot of times when it isn't practical or worthwhile to make much effort to separate your data into a bunch of separate fields and a template and then put them back together.

If I am writing a journal entry I may want to write a paragraph, insert an image inline with the text, write another paragraph and embed a Youtube video. I don't want to create a new page type with a text field or two, an images field, a movie field and a template to put them all together. I just want to sandwich some html markup with a header and a footer and move on.

ProcessWire is amazing for handling situations where you expect to manage a lot of repetitive "pages" (data structures) of a given type. For lists of skyscrapers, villas or lists of just about anything this CMS is the bomb - honestly it is amazingly clean! It's a little less clear that it is worthwhile to use a "template" approach when you're just making a one-off page or content block. Not all web content needs to be reduced to an abstraction of data and template before you can use it - this is the hammer issue.

Even if you load the images in a journal entry into the images field of a typical page template, how are you supposed to access them from within your rich text or markup? A lot of content doesn't need to be set up for easy re-use, it just needs to be conveniently used once. This is where I'm struggling a little. All in all, I think the ProcessWire approach is fresh and powerful, but it would be good to be able to put some images and scripts on the filesystem and discover that they are available below "/site/templates/mystuff". 

One of my competitors is Salesforce's Desk.com, and they have an outrageously good sales website. A site like this would be really tough to develop in ProcessWire since almost everything on the site is handcrafted, single-use content. Not much of their site is well-suited for templates, but the whole thing is pixel perfect. There's a place in the world for content that isn't generated by invoking a template on a set of page data.

ProcessWire is an awesome tool, but not all content is so rigidly aimed at separation into data and templates. Some content is just content, use it once and keep moving. Lots of other CMS's make that easy, but they don't excel at the structured repetitive stuff like ProcessWire does. It would be great if ProcessWire also made it easier to produce those conventional throwaway pages, too.

[Joss]

Just had a look at Desk.com and it would be no problem to put that together with ProcessWire at all.

With ProcessWire you can work anyway you want. Whether that is with repetitive content, like a blog, or a block based site like Desk.com

Even there you have repetitive content - if you look at the Customer testimonials page, they have one template for the short testimonials which is reused throughout the page, and another for the featured testimonials. And they have a blog too, of course.

With Processwire you can create very individual pages or you can produce very similar pages - PW does not work one way or the other, it is completely up to you.

You can create as many templates as you like, or as few, and you can use TinyMCE as much as you like and configure it differently for every single field, if you wish.

You can include templates within templates and pages within pages, allowing you to create a block based system where you create a library of blocks and call them with   a select field into another page.

If you talk to the designers that use PW you will find a huge range of sites from ones with thousands of pages to ones that are simple brochures with a completely different layout on every page and an dizzying array of effects.

The point is that ProcessWire is a CMS Framework, so it does not have a fixed way of working - that is down to you.

[pwired]

This is an interesting thread that touches on the difference between PW and other cms'es. Usually a cms is defined by it's rules and dashboard that you first have to learn before you can make websites with it. Advantage: it shows you defined ways of working and you'll know what to do. Disadvantage: you are bound to it's rules and dashboard and sooner or later this will limit your creativity. PW can make a developer with little coding experience float in it's open potential sometimes not knowing where to go. Look how this still pulls my leg with PW, so I can understand what DZoneRick is saying in his posts. But I prefer it this way over other cms'es because coding skills can always be learned. I really hope that PW will never build in out of the box fancy cms ways/rules on it's future roadmap, ending up just another cms. I'm not an experienced coder (yet) but I think DZoneRick can use .inc blocks or <?php include 'content.php'; ?> to accomplish throw away content where he needs it.

[Wanze]

Even if you load the images in a journal entry into the images field of a typical page template, how are you supposed to access them from within your rich text or markup? A lot of content doesn't need to be set up for easy re-use, it just needs to be conveniently used once. This is where I'm struggling a little. All in all, I think the ProcessWire approach is fresh and powerful, but it would be good to be able to put some images and scripts on the filesystem and discover that they are available below "/site/templates/mystuff". 

But you know that with Tinymce and soon also with the brand new CkEditor you can insert images from the images field into your html markup?

(http://processwire.com/talk/topic/627-ckeditor-module/page-2)

There's also a Youtube-video Textformatter by ryan. Just copy the Youtube-url inside and it gets replaced with the video.

If you have content-editors that understand html/css etc, you could use only a richtext/image field and write the complete markup there.

However, this is not a good solution for most of the editors because they can mess up the entire design. It's safer to split things up in different fields (headline, description, body, images, files, related_posts etc.). This way ou can also easy change the whole markup afterwards.

[SiNNuT]

If I am writing a journal entry I may want to write a paragraph,
insert an image inline with the text, write another paragraph and embed a
Youtube video. I don't want to create a new page type with a text field
or two, an images field, a movie field and a template to put them all
together. I just want to sandwich some html markup with a header and a
footer and move on.

There would be nothing stopping you from doing so with any text area field with tinymce turned on. Images added to the page become available in tinymce/rich text via the 'Select Image' button. You can also choose from different pages. By default the tinymce configuration is fairly bare-bones but you can change this to the point where it is a ms word clone. Not 100% sure about youtube stuff but you can prolly just insert the embed code where you want.

Ryan is also working on a CKEditor implementation which may be of interest to you.

Even if you load the images in a journal entry into the images field
of a typical page template, how are you supposed to access them from
within your rich text or markup?...

see the above

One of my competitors is Salesforce's Desk.com, and they have an
outrageously good sales website. A site like this would be really tough
to develop in ProcessWire since almost everything on the site is
handcrafted, single-use content. Not much of their site is well-suited
for templates, but the whole thing is pixel perfect. There's a place in
the world for content that isn't generated by invoking a template on a
set of page data.

I don't see anything on that site (which is indeed nice) that would be particularly tough to do in PW. In fact, it would suit PW well i think.

When you say  "Not much of their site is well-suited for templates, but the whole thing is pixel perfect." i don't understand. How do templates and fields relate to a design and layout being pixel perfect? In essence the desk.com site is a well executed Twitter Bootstrap site and i'm guessing that they have structured their content well in the backend. Or maybe it's just handwritten html, who knows.

ProcessWire is an awesome tool, but not all content is so rigidly
aimed at separation into data and templates. Some content is just
content, use it once and keep moving. Lots of other CMS's make that
easy, but they don't excel at the structured repetitive stuff like
ProcessWire does. It would be great if ProcessWire also made it easier
to produce those conventional throwaway pages, too.

I'm not saying that PW is perfect. Some things take getting used to, others could be improved upon and surely there are other systems out there that do a better job at a certain content management aspect. What i don't see is that PW makes it particularly hard to create content, throwaway pages, or otherwise.

[apeisa]

Interesting discussion. If "sandwich" type of website (without actually coding it by hand) is what you are building, then CMS like Concrete5 (http://www.concrete5.org/) or Apostrophe Now (http://www.apostrophenow.com/) is probably much better solution than ProcessWire.

ProcessWire strengths are definitely in it's data modelling and as a building platform (framework). When it comes to sites where each page should be a little different to each other with totally custom content (no clear templates) - then PW helps you very little out of the box. Of course it would be my weapon of choice, if I would start building simple cms for that need

[Soma]

I could build this site in PW in 1-2days and it will be fully flexible content block type you can build those pages and have all configurable and sortable just powerful with sliders and colorpickers. Think outside of the 'page' and step back. Use them as blocks. You got jquery at your fingertips for the whole page tree, repeaters, page references. This may sounds as it would be silly but see pages as repeaters and there's nothing that can stop you. See one one page as a page you look on the screen and you'll be limited by what it can do. PW is build to work this way and performs and scales very well. There's plenty of module already and they`re easy to understand and build/maintain. I'm not a very good coder but PW makes me look like one.

[apeisa]

You are crazy genius if you can build site like desk.com in 1-2 days. But wait.. you actually are crazy genius!

[Joss]

Yes, I think the resident "Crazy Genius" is right. It would not take long to put a framework of blocks that did what that site.

The hardest part is working out what you are going to put into the boxes, to be honest. 

[DZoneRick]

But you know that with Tinymce and soon also with the brand new CkEditor you can insert images from the images field into your html markup?

(http://processwire.com/talk/topic/627-ckeditor-module/page-2)

There's also a Youtube-video Textformatter by ryan. Just copy the Youtube-url inside and it gets replaced with the video.

Honestly, no, I did not know this. Thank you for the tip, and I will read that thread promptly.

I'm a little skeptical of TinyMCE because it always seems to add or remove something in its efforts to be WYSIWYG. I was trying the ACE Text Editor module instead. 

So, how are the images being inlined in TinyMCE? Is there some kind of underlying tag semantics we can use directly from within non-WYSIWYG markup?

[DZoneRick]

Interesting discussion. If "sandwich" type of website (without actually coding it by hand) is what you are building, then CMS like Concrete5 (http://www.concrete5.org/) or Apostrophe Now (http://www.apostrophenow.com/) is probably much better solution than ProcessWire.

ProcessWire strengths are definitely in it's data modelling and as a building platform (framework). When it comes to sites where each page should be a little different to each other with totally custom content (no clear templates) - then PW helps you very little out of the box. Of course it would be my weapon of choice, if I would start building simple cms for that need

@apeisa, you and I both share an admiration for these solid strengths of PW, and I think we can also both agree that C5 does not provide the level of power and tooling that PW offers for structured data. But the real world has everything in it, both structured and unstructured. PW is not as amazing for the unstructured... yet.

I have tons of respect for the passion and enthusiasm of the many PW champions and advocates here, and I'd like to point out that I am not attacking anything or anyone. This platform and community are awesome, and I mean to be a positive contributing member.

I *DO* have lots of data that is beautifully well-suited for the PW strategy, hence my choice to adopt PW! But I also have several places where I just need some content, and it doesn't need to be distilled into anything nearly as abstract as template+data. This isn't a battle, and PW can definitely provide unparalleled support for template+data while at the same time making it easy to work with more direct markup or WYSIWYG content.

The use-case that spurred me to create this thread was nothing elaborate, and it wasn't horrible or bad or any of the other stuff some of the folks above would seem to want to suggest. I merely hit a wall that I wouldn't have hit if I could have more easily used a tag/variable/symbol in my markup to get to the directory pointed at by $config->urls->templates. Mountain from molehill?