DZoneRick

Awesome! I had no idea it was so easy to drop straight to SQL. You continue to surprise me with practical, useful solutions! Best, Rick

Looks very sharp, Chris congrats! Is the page at http://chrisvaupel.de/leistungen/ constructed as a list of other pages? Cheers, Rick

Very cool module, and it looks like it can do exactly what I want. My original question about php in fields was driven by my specific need to use the value of $config->urls->templates inside markup fields. It looks like MarkupShortcodes makes this relatively easy. Thanks!

OK, I immediately went and tried it out, and the TinyMCE image plugin is merely hard-coding the path into the underlying html, which totally defeats the purpose. Here's an example of the html created by the TinyMCE plugin: <img src="/site/assets/files/1062/answerhub-logo-230x60.png" width="230" height="60" alt="AnswerHub" /> Hard-coding the path will only work UNTIL the site gets moved or the path changes, and then you're up a creek without a paddle. I'm looking for a simple, safe, reliable way to access $config->urls->templates and use it in markup stored in text fields. The TinyMCE plugin is not producing the outcome I was aiming for.

OK, it's encouraging that you and others here feel that producing such a site wouldn't be a problem with PW. The fact is, after all, that I have decided to invest time, money and energy in adopting PW because it really seems to be the best of the available options. I'll tell you guys truly, though, that it's a damned shame there's not a killer PW gallery of killer PW sites. Nothing I have seen in the examples promoted on the PW website comes close to the tour-de-force range of that Desk.com site. It would have been super helpful to be able to browse through a lot more examples of PW sites, and managing such a gallery is precisely where PW excels!

Dude, you're hired!!

@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?

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?

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.

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, 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.

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

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