Adam Casto asked 3 years ago
I posted this in Slack a while back but am still having issues. This is probably more of a feature request than a question, but maybe someone has come up with a better solution since.
Situation: If you have a view with a field, let's say the field id is 42 for example, and you need to output a literal [42], as is there is no way to do so due to how Formidable implements those view shortcodes.
Trying to use a custom enclosing shortcode to bypass it doesn't work because the preg_match will still catch it inside the shortcode, and if you try to pass just the number within brackets the double brackets will break that shortcode. You could pass the integer as an attribute to a custom shortcode which wraps it in brackets, but that's pretty hacky and wouldn't work in HTML attributes where this is mostly needed. In the past we've used a linebreak or whitespace to slip past the Formidable shortcode preg_match, but now that is breaking other things. At this point if I'm going to continue to use Views for this kind of output I'm going to have to resort to using javascript to piece it back together on the frontend. It would be nice if there was an attribute to just return the integer, or even an extension the existing "show" attribute.
Please login or Register to submit your answer
I don't understand what you are trying to do. A field shortcode returns the value of the field. If you want to show a literal number in a view, either just enter the literal number or create your own shortcode to return a literal value.
Hey Victor, we went through this on Slack a few months back. The issue is you can't use bracket+number+bracket - ie: [42] - because it gets caught up in the pseudo shortcode just using preg_match to catch anything with opening brackets and numerals. However they already have some attribute support built in, ex: show, so it wouldn't be that hard to add a way to fall through it for when someone needs the particular string of characters that is being interpreted as a shortcode.
I don't remember this conversation on Slack, but I understood the problem as "I can't use a shortcode in a shortcode". In some cases you can, but it depends on the shortcode. If you want to express a literal in brackets, you have to use the HTML entities &lsqb and &rsqb. I run into this all the time when writing tutorials that include shortcodes.</p>
<p>The question is, "How do I display a literal in a Formidable shortcode?"</p>
<p>My approach would be to write my own shortcode to preprocess the literal before passing it as one of Formidable's parameters, which is exactly why I said write your own shortcode. You can put a wrapper around any Formidable shortcode to do your own pre- or post- processing, then feed Formidable what it needs to display the field to your specification. It doesn't require changing Formidable. It requires using Formidable's hooks or public functions in your code. You can display content any way you want.
But the problem is this isn't a shortcode, it's a pseudo shortcode using preg_match to simulate a shortcode. If it were a shortcode in regular WordPress content you could use something like double-brackets to handle it, ex: [[testcode]]. I get why they don't use the WordPress shortcode API to implement it as actual shortcodes, that would be difficult to handle with all the various IDs, but just doing a preg_match with no way to skip leads to issues like this.
HTML entities doesn't work if you're using the text edit mode, in which you often are for the edge cases this pops up on.
A particular custom shortcode could work in certain circumstances but won't in HTML attributes where WordPress doesn't run shortcodes by default for this very reason due to the prevalence of brackets. Even if, that's still just a hack to get around Formidable blindly preg_match-ing content.
My solution for now is just to intentionally break it in the view with a whitespace, ex: '[ 42]', and catch it after in PHP and remove the white space. The real solution would be to not eat content without a way to bypass it. Those particular "shortcodes" already have some attributes to vary the output, it just needs one more.
Please let me correct an assumption you revealed when you said, "I get why they don't use the WordPress shortcode API". I'm assuming you mean the "they" to mean Formidable's talented team of developers.
The only way to create shortcodes in WordPress is through the WordPress Shortcode API. The Formidable developers use the WordPress Shortcode API just as every developer that's ever written a shortcode for any purpose in WordPress does. Formidable does not have its own shortcode API. Formidable shortcodes are WordPress shortcodes by inheritance.
You might want to check the code then. They use the WordPress plugin API for the main shortcodes that you use in normal WordPress content areas, but the last I checked, the ones used in Views such as [42] are implemented using preg_match to catch and replace the content, simulating shortcode like behavior. There's even a function named "replace_non_standard_formidable_shortcodes" with the comment: Replace Formidable shortcodes (that are not added with addshortcode) in a string.
I'm not going to do this with you, Victor. You do great with 90% of the questions on here but the defensiveness and aggressiveness anytime one falls outside your comfort zone is simply uncalled for. I'm not criticizing Formidable, I use the plugin for almost everything. I admit this is a corner case, but it's perfectly valid to point out the unintended consequences of a particular implementation.
I'm really sorry you feel I was being aggressive or defensive. I didn't think I was expressing either emotion, certainly not with any intent; and most certainly without any desire to be argumentative. I was only explaining what I know to be experientially true about Formidable.
I've been using Formidable for almost as long as it's been a product. I built the Formidable Masterminds Codex and documented every hook I could find. I never finished documenting the shortcodes however even though the Codex has views for them once they're added to the database.
From my conversations with members of the Strategy 11 development team, a good deal of their focus is making Formidable standards compliant and easy for developers to build and package applications. Since you've found non-standard shortcodes, it's entirely possible that you discovered code that has been part of Formidable's code base since before WordPress introduced shortcodes in Version 2.5. I don't know because I've never seen the code of which you're speaking. Thank you for making us aware. And knowing how focused the Strategy 11 is on producing the best products possible, I can surmise that any non-standard stuff is on the roadmap for deprecation.
Again, I'm sorry my responses rubbed you the wrong way. Everyone that answers questions here, in Slack, or the old community forum is a volunteer, myself included. We do this because we love Formidable and love helping people solve their problems, but we're only as good at answering questions as our experience building applications with Formidable allows us to be. We're end users just like you. I was just seeking to understand what the problem actually is that you were describing. Thank you for clarifying.
Thanks, Victor, I appreciate you saying that and your work on the codex and in the forums/slack. I've been using it for probably the same, maybe a decade? I don't know, I've lost track of time. As an independent developer the hooks and shortcodes in Formidable have been extremely powerful in allowing me to focus on business logic and rapid-prototype tools. Over the past year I've been developing a plugin internally to extend Formidable with custom function capabilities to help me avoid some of the spaghetti code that comes with mixing field keys and ids throughout backend PHP custom code. Utilizing the Views to generate HTML and then move it around with PHP and AJAX let's me keep Formidable focused presentation in the frontend and independent business logic in the backend.
As far as this particular issue goes, I know they've been changing some stuff regarding views since this last came up so relevant code for that may be in the separate views plugin, I haven't had a chance to dig through that, but back then I think I was looking at formidable-pro/classes/models/FrmProContent.php, and the function I mentioned above regarding non-standard shortcodes is in formidable-pro/classes/helpers/FrmProFieldsHelper.php. There's quite a bit of code in that file pertaining to this.
Regarding standardized WP shortcodes, I don't blame anybody for going this route. I'm not even sure if it would be feasible or performant to programmatically add a shortcode for every possible field ID, and since it's limited to intra-formidable functionality unintended consequences are quite limited. It would just be nice to have a way to skip through whether it's something like the double-bracket format or an attribute.