I have a plugin that utilizes shortcodes. I am using this plugin on my own site, but I'm also trying to provide documentation with usage samples on my site.
When placing the shortcode on my page, though, it's actually triggering and displaying the shortcode output instead of the code example of the shortcode itself.
For example, when I have this...
[paypal_ipn_list field1="txn_id" field2="payment_date" field3="first_name" field4="last_name" field5="mc_gross"]
The shortcode is actually triggered because I'm using the plugin myself. I need it to actually display that line, though, as a usage sample.
I tried replacing the actual []'s with ASCII values, so I used this...
[paypal_ipn_list field1="txn_id" field2="payment_date" field3="first_name" field4="last_name" field5="mc_gross"]
That actually displays that way, though, instead of converting to an actual [ or ] character. So that's not good for usage sample purposes, of course.
Is there some way I can disable or escape these shortcodes in this one place so I can output the usage sample, but still allow them to function everywhere else where I may actually be using them myself?
Any information on this would be greatly appreciated. Thanks!
You can escape shortcodes using a double bracket: [[shortcode_here]]
[[paypal_ipn_list field1="txn_id" field2="payment_date" field3="first_name" field4="last_name" field5="mc_gross"]]
Related
I have encountered a strange hiccup with a Wordpress site that has a graphical editor requirement (Tatsu). It is 97% mature, and of course there is now a problem.
Contact Form 7 was used to create a simple form capable of accepting a file attachment. With the classic editor the form embeds and functions without issue. With Tatsu and a couple of other graphical editors the form works as embedded with their formatting and in all preview modes...until it is saved by the graphical editor. Then we see the 404 error for the form.
If I use a traditional wordpress form, the embed is successful in both traditional editors and the graphical editors. What I have found is the Contact Form 7 (form) has a space in the shortcode whereas the traditional Wordpress forms do not. Example. I can't use the traditional Wordpress form for the file upload form because it requires an expensive paid version to accept the file upload and that PRO version isn't in the budget.
It appears as though the graphical editors are truncating the form's shortcode leading to the 404.
I tried modifying the page's code and was moderately successful, until the required graphics-editor re-saves the page and chops off the form's shortcode. When the graphical editor sees the space in the shortcode, it appears to truncate the shortcode leading to the 404 error. I can switch back to the classic editor and see the modified shortcode--the truncation. With the classic editor I can correct it, but the formatting of the page is wonky until it is opened and re-saved by the graphical editor (Tatsu)...then the formatting is spot on but the form is broken.
-I tried the default wordpress form generator, but making the file upload happen required a costly PRO subscription.
I think I'm searching for the wrong thing based on buzzword mismatches. I've looked for how to alias a shortcode (I was thinking I could create a different form shortcode without a space and point to the Contact Form 7 shortcode with a space), but most information I find in that approach is lower-level concerning form fields.
A more direct approach--I thought about modifying the shortcode, but can't find where the auto-generated form shortcodes are stored to attempt modification for the subject form's shortcode.
A more aggressive approach--I tried a do_shortcode php approach, but it did not work.
For grins I tried %20 in the shortcode reference, but met the same demise...404. Suggestions to get past the hump are appreciated.
I worked with this in several combinations through the day. I really dislike what some of these editors are doing to conform to their own style, but I understand.
The solution I found--there is another editor called PageSlayer. Unlike the Classic editor, it allowed me to edit the html and save it precisely, preserving the style of the graphical interface. This isn't a good solution because when anyone else goes into the graphical interface (Tatsu) to edit something they will lose the form...but it looks right and plays right this moment.
I have sent a request to support Contact Forms 7 to Tatsu. Thanks for the time!
Problem
I need Wordpress to stop turning underscores into hyphens in its slugs/permalinks.
Situation
Moving an old site over to a clean Wordpress installation. Old site uses underscores in its urls. We need to preserve the old urls including underscores at this time (please do not recommend any SEO advice here, thank you).
Wordpress cleans up its slugs/permalinks. Underscores are turned into hyphens.
I want to be able to use both underscores AND hyphens in my slugs. I am not looking to replace one with the other completely, which is what most suggestions/solutions I've found boil down to.
Examples of a solution that does not meet my criteria:
https://wordpress.stackexchange.com/questions/78334/convert-hyphen-to-underscore-in-permalinks
Example of a solution to allow dots that may be useful:
https://wordpress.stackexchange.com/questions/231448/how-to-add-dot-in-post-slug
What I've tried
I have searched for a solution but was unable to find a satisfying one. Supposedly the cleaning up of slugs/permalinks is defined in /wp-includes/formatting.php using the sanitize_title_with_dashes function.
I pasted the code related to sanitizing here:
https://pastebin.com/jRqV8iB8
The only line I can see that targets underscores is:
$title = preg_replace( '/[^%a-z0-9 _-]/', '', $title );
For testing purposes I removed the underscore from that line, replaced formatting.php on the server and tried putting underscores in a slug again. But it didn't do anything. I also only just figured out based on the "allow dots in permalinks" link mentioned earlier, that that line supposedly ALLOWS underscores in urls.
This also fits the comment content "* Limits the output to alphanumeric characters, underscore (_) and dash (-)."
So... this code is saying that underscores are allowed (in slugs/permalinks?), but they're still being stripped in my slug/permalink.
Can anyone see something here that I cannot. Or suggest a filter that will allow both underscores and hyphens in the slug/permalink? Right now I'm stuck.
Thank you in advance for any help you're willing to offer.
Solution found
The Gutenberg editor forces hyphens in the slug of a post or page at this time: https://github.com/WordPress/gutenberg/issues/13091
In my case, I have enabled the Classic Editor plugin: https://wordpress.org/plugins/classic-editor/
I'll rebuild the website and the old urls with underscores that way. When I'm done I'll switch back to Gutenberg. The old urls will be changed carefully and gradually in the future and the new ones will use hyphens. So it should work out.
Alternatively, as user #admcfajn pointed out, you can modify the page/post slug from the page/post overview screen using the Quick edit functionality. Underscores added to the slug that way will stick, even with the Gutenberg editor active.
If you're looking to replace hyphens with underscores permanently, create a filter using the solution presented for this question instead:
https://wordpress.stackexchange.com/questions/78334/convert-hyphen-to-underscore-in-permalinks
Thanks to those who took the time to reply (one user deleted their reply or had it removed). I hope others will find this solution through Google in the future.
Hopefully either Gutenberg will be fixed or the comment in the formatting.php file will be amended to avoid confusion if it is the developers' intent to only allow users to use hyphens.
We shouldn't have any problem using both hyphens and dashes with WordPress
The url-slug of test_page-of-awesome is perfectly valid. So, I imagine there must be a setting somewhere in a plugin or theme which is rewriting or modifying those.
You mention that:
Wordpress cleans up its slugs/permalinks. Underscores are turned into hyphens.
... This is not expected behavior of WordPress and is being caused by a plugin, theme, or something else... But it is not how WordPress is expected to work.
Try the following:
enable a core-theme ( twentyninteteen, twentytwenty )
disabling all plugins
ensure that you're able to use pretty-permalinks wp-admin/wp-admin/options-permalink.php Settings >> Permalinks
& if you can't get url-slugs to save then the issue is likely coming from elsewhere on your server. Depending on the configuration of your web-hosting environment there may be something else affecting the url slugs. It might be apache mod_rewrite rules or something
I update my original post as well, but adding an accepted answer for visibility.
The Gutenberg editor forces hyphens in the slug of a post or page at this time: https://github.com/WordPress/gutenberg/issues/13091
In my case, I have enabled the Classic Editor plugin: https://wordpress.org/plugins/classic-editor/
I'll rebuild the website and the old urls with underscores that way. When I'm done I'll switch back to Gutenberg. The old urls will be changed carefully and gradually in the future and the new ones will use hyphens. So it should work out.
Alternatively, as user #admcfajn pointed out, you can modify the page/post slug from the page/post overview screen using the Quick edit functionality. Underscores added to the slug that way will stick, even with the Gutenberg editor active.
If you're looking to replace hyphens with underscores permanently, create a filter using the solution presented for this question instead: https://wordpress.stackexchange.com/questions/78334/convert-hyphen-to-underscore-in-permalinks
Thanks to those who took the time to reply (one user deleted their reply or had it removed). I hope others will find this solution through Google in the future.
Hopefully either Gutenberg will be fixed or the comment in the formatting.php file will be amended to avoid confusion if it is the developers' intent to only allow users to use hyphens.
My new WordPress site is using a predefined number of characters on its front page instead of allowing me to use the tag where I see fit. How can I resolve this? I understand it is against policy to post my url, but if you could find a way to help me it would be much appreciated.
Is WordPress truncating before your more tag? If so, you could try increasing the excerpt length with the excerpt_length filter. Just have it return a suitably high number of words.
As the codex says, make sure you use a high priority (eg 999, as in the example) to make sure your filter runs after any others.
I'm creating a short-code generator for the WordPress Add/Edit Post/Page screen.
I want to make sure that there does not exist more than one short-code in the same post/page. So I added an onclick function for the button so that whether there already exist a short-code, could be checked.
How do I go on doing this?
I searched around the TinyMCE API and the closest I got was the tinymce.Formatter.match method. But there's no example on this page. I don't really think that this has anything to do with the content search anyway.
Another way would be to simply use the getContent method and run javascript code against it. But I guess this wouldn't be the best option if there's something built-in for this already.
I do not know exactly what you mean by the term "short-code".
But i guess it is a string you can find using getContent-Method.
There are several other ways to search the editor content.
Since tinymce editor is rendered inside an iframe and is indeed real html code you can use all regular DOM-Methods of your browser. There are even some additional DOM-Methods provided in tiny_mce/classes/dom/DOMUtils.js.
I've got TinyMCE installed on frontend of my wordpress website…it's separate from the default Wordpress version, however, I need it to NOT turn raw URLs into anchor tags because it screws up Wordpress's ability to then oEmbed it. I have it installed on a form where users can submit articles in the frontend (not Dashboard). Is there a way to disable this? I thought convert_urls: false would to the job, but it's not meant for that. I've looked for over two hours now and cannot find a suitable answer. Thanks for the help.
well, usually it is not such a good practice to include 2 versions of the same script ..
at any rate -
I do not know specifically about TinyMCE, but you can use str_replace () php function (or preg_replace() ) to repair just about anything (if it is a string ..)