Query String discrepancy in Adobe Contribute/Dreamweaver - dreamweaver

/**Update ***/
This seems to be a query string problem, as I didn't realize that a PHP error was being thrown in Contribute 3. So my question now is, why does this line work in Contribute 4, but not in 3: #include virtual="includes/scripts/name.php?eid=##(eid)##"
/********/
Hello everyone, I have a couple of different versions of Contribute in my organization. We built a template that works for the CS4 version, but has a peculiar error in the CS3 version, and I was wondering if a Contribute expert might provide some guidance.
We built the template in Dreamweaver, with the standard TemplateParam statements at the top. All of them are just editable regions except for one, the ID field:
TemplateParam name="eid" type="text" content="your eid"
Values based on that ID are fetched and formatted with a PHP script in the template body:
#include virtual="includes/scripts/name.php?eid=##(eid)##"
The problem is that if we attempt to edit any template properties in CS3, such as turning them on or off, it will disable our PHP script completely (all fields come back empty), and we have to abandon the changes. Not so in Contribute 4, which works as expected.
This is a pretty specific inquiry, so any assistance would be appreciated.

The answer seems to be to simply replace the double quotes in the includes path with single quotes. Works correctly for both versions now.

Related

Any way in Expression Engine to simulate Wordpress' shortcode functionality?

I'm relatively new to Expression Engine, and as I'm learning it I am seeing some stuff missing that WordPress has had for a while. A big one for me is shortcodes, since I will use these to allow CMS users to place more complex content in place with their other content.
I'm not seeing any real equivalent to this in EE, apart from a forthcoming plugin that's in private beta.
As an initial test I'm attempting to fake shortcodes by using delimited strings (e.g. #foo#) in the content field, then using a regex to pull those out and pass them to a function that can retrieve the content out of EE's database.
This brings me to a second question, which is that in looking at EE's API docs, there doesn't appear to be a simple means of retrieving the channel entries programmatically (thinking of something akin to WP's built-in get_posts function).
So my questions are:
a) Can this be done?
b) If so, is my method of approaching it reasonable? Or is there something stupidly obvious I'm missing in my approach?
To reiterate, my main objective here is to have some means of allowing people managing content to drop a code in place in their content that will be replaced with channel content.
Thanks for any advice or help you can give me.
Here's a simple example of the functionality you're looking for.
1) Start by installing Low Replace.
2) Create two Global Variables called gv_hello and gv_goodbye with the values "Hello" and "Goodbye" respectively.
3) Put this text into the body of an entry:
[say_hello]
Nice to see you.
[say_goodbye]
4) Put this into your template, wrapping the Low Replace tag around your body field.
{exp:low_replace
find="[say_hello]|[say_goodbye]"
replace="{gv_hello}|{gv_goodbye}"
multiple="yes"
}
{body}
{/exp:low_replace}
5) It should output this into your browser:
Hello
Nice to see you.
Goodbye
Obviously, this is a really simple example. You can put full blown HTML into your global variable. For example, we've used that to render a complex, interactive graphic that isn't editable but can be easily dropped into a page by any editor.
Unfortunately, due to parse order issues, EE tags won't work inside Global Variables. If you need EE tags in your short code output, you'll need to use Low Variables addon instead of Global Variables.
Continued from the comment:
Do you have examples of the kind of shortcodes you want to support/include? Because i have doubts if controlling the page-layout from a text-field or wysiwyg-field is the way to go.
If you want editors to be able to adjust layout or show/hide extra parts on the page, giving them access to some extra fields in the channel, is (imo) much more manageable and future-proof. For instance some selectfields, a relationship (or playa) field, or a matrix, to let them choose which parts to include/exclude on a page, or which entry from another channel to pull content from.
As said in the comment: i totally understand if you want to replace some #foo# tags with images or data from another field (see other answers: nsm-transplant, low_replace). But, giving an editor access to shortcodes and picking them out, is like writing a template-engine to generate ee-template code for the ee-template-engine.
Using some custom fields to let editors pick and choose parts to embed is, i think, much more manageable.
That being said, you could make a plugin to parse the shortcodes from a textareas content, and then program a lot, to fetch data from other modules you want to support. For channel entries you could build out of the channel data library by objectiveHTML. https://github.com/objectivehtml/Channel-Data
I hear you, I too miss shortcodes from WP -- though the reason they work so easily there is the ubiquity of the_content(). With the great flexibility of EE comes fewer blanket solutions.
I'd suggest looking at NSM Transplant. It should fit the bill for you.
There is also a plugin called Shortcode, which you can find here at
Devot-ee
A quote from the page:
Shortcode aims to allow for more dynamic use of content by authors and
editors, allowing for injection of reusable bits of content or even
whole pieces of functionality into any field in EE

Cannot locate a text_field with dynamic id

<div id="temp_1333021214801">
<input type="text"/>
</div>
$browser.text_field(:xpath,".//*[#id='temp_1333018770709']/input").set("apple")
I am getting error "unable to locate element", because the ID changes dynamically.
Please help me to set the text in the text field.
It seems like your dynamic id is temp_ so this should do it given information above:
browser.div(:id, /temp_\d+/).text_field.set 'something'
Issues with my solution is that it assumes id will always be temp_ regex matching any number set consecutively, which seems to be the case with your sample above. Also, it assumes there is no other div(:id, /temp_\d+/) combination in the DOM of that page, most likely should not be an issue.
If you have dynamic IDs I can suggest the following:
Code to object counts. For example
$browser.text_field(:index => 2)
gives the third text_field on the page.
Code to what is around the thing you're trying to find.
$browser.div(:name => 'mydiv').text_field(:index=>2)
gives the third text field in the div called 'mydiv'.
HOWEVER
If your front-end is less-than-testable in this way I highly suggest you put time into thinking over your commitment to automated testing in the first place. Any minor change to the software is going to have you working until 9pm pulling your hair out and rocking back and forth as you update all your scripts, so unless code maintenance is your weekend hobby think about semi-automation or exploratory testing or manual scripts. Talk to development (whomever that might be. It might be you!) or the higher-ups (unless that's you too) to see if it can be made more testable. Also don't use xpaths unless you take some deviant pleasure in it.
Hope that was helpful, I can't do anything specific without the source HTML.

Is there another way to fix Yesod's nicHtmlField?

I've been rewriting my (fairly simple) website using Yesod as a way to get familiar with the framework. Part of that involves serving some simple static (but formatted) content. To do that I decided to use the nicHtml field that is described in the Yesod book:
http://www.yesodweb.com/book/forms
It allows simple formatting and, as the book says, "thanks to the xss-sanitize package, all user input is validated and ensured to not have XSS attacks."
However, all is not well. Some formatting seems to work when you enter it into the field, but gets wiped out somewhere between entry and submission. In particular, the form uses css embedded in 'style' attributes to do things like center text, and it is these css based formatting elements that seem to get wiped out.
I used print statements to check that it wasn't my code which was somehow messing it up. Since it doesn't seem to be, I assume that xss-sanitize doesn't like any embedded css and removes it. Modifying Yesod.Form.Nic to remove the call to sanitizeBalance appears to fix the problem, so that would seem to be the cause.
Now, I can just leave it like that, since editing these static pages requires being a trusted user anyway (i.e. me at the moment), so I don't care too much about validating out nastiness. But it feels like what it is, a hack, so my question is - is there any other way around this? Or is there another package I don't know about that provides a non-broken HTML editor field for Yesod?
Will you file a bug on the Yesod issue tracker for this? I think we are going to have to allow basic css through the editor no matter which editor we use. In your case of a trusted user, right now you could find the NicEdit field type and create a similar type that won't get filtered at all. Perhaps we should create such a field.
We're actually looking at other possible rich text editors right now for use in the Yesod website, so most likely whatever we use there will end up with a module in yesod-form. Most recently Greg pointed out Aloha editor which on first glance looks pretty cool.

ReSharper - Is there any way to save code quality recommendations to a file?

I'm probably using the wrong terminology but basically I would like to dump the findings from the panel to the right of the scrollbar to a file for later review. See the screenshot below for what I mean. It's the part of the screen with the orange and green lines on. Does anyone know if this is possible?
If anyone is interested I have filed a feature request for this with JetBrains here.
As far as I know it's not possible, at least with the built in features. Maybe it's possible by writing a plugin.
The only thing which I know to get something like this:
Goto the 'Code Issues' Inspector: Resharper->Code Issues in Current Solution or any other of these options
On the window which shows the issues is a 'Export' button. With that button you can export the issues of the project/solution/file.
The report format is pretty simple list of issues as text. Like this:
5 issues found
Common Practices and Code Improvements (1 issue)
<DemoApp>\Program.cs (1 issue)
Property 'Title' can be made private
Potential Code Quality Issues (4 issues)
<DemoApp>\Program.cs (4 issues)
Auto-implemented property accessor is never used
Auto-implemented property accessor is never used
Class 'Comment' is never instantiated
Class 'Program' is never instantiated
It's now possible to use Resharper's Command Line to produce a xml with the issues on a given solution.
It's not exactly the 'export' functionality you wanted, but it might be useful still.
You just have to run the tool and pass the file where it will save the issues. For example:
inspectcode /o="D:\Resharper\MyIssues.xml" [PathToSolutionFile]
I've noticed this produces more issues than the plugin inside Visual Studio does, for some reason. I really think the Resharper's team should concentrate on using the same code to analyze the files instead of different implementations like it seems to be now.

where do I access the comment field for a core data model to add the "xmod" for mogenerator?

where do I access the comment field for a core data model to add the "xmod" for mogenerator?
hopefully not too dumb a question - but I just can't see where in my existing Xcode 4 model (*.xcdatamodel) to put the "xmod" to get mogenerator working
(reference https://github.com/rentzsch/mogenerator )
Xmo'd currently doesn't work with Xcode4. It is a .pbplugin and Apple removed support for them in Xcode4. There was a couple guys working on a new way of doing it, but I haven't seen any updates in awhile on it.
You can still use the AppleScript and command line though. You just have to manually trigger it and add the files. You lose the automation that Xmo'd gave you. Also, Xmo'd still works in Xcode3. So you can switch over to it when doing your modeling if you really wanted to.

Resources