Johan Steen
Forum Replies Created
-
Thanks for your input and suggestion. I do definitely agree with you that being able to tweak how the settings screen is displayed according to user role would be useful.
Depending on how one uses the plugin, I can see some different variations of how you’d like users with non admin privileges see the settings page. So I was thinking of maybe adding filters to the settings page to control how you’d like to see the settings in other scenarios like a read-only mode that only displays shortcodes for instance.In other words, by using a filter, you get the access to remodel the settings page. Would that work for you?
Cheers,
JohanHi,
I don’t have any plans to add global/static variables at this time, as it could be solved by using the PHP enabling function for the snippets.
What I did do though, was that in the latest release (1.9.6) I added two new filters to the plugin,
post_snippets_importandpost_snippets_export.While it doesn’t do exactly what you are looking for, using them would at least simplify the process you are doing by adding a simple filter to your site/s to replace the urls on either export or import.
Here is two examples to get you started of either import or export filter you could add to your site/s.
Example that modifies data in snippets before the export file is created:
function ps_export( $snippets ) { $snippets = unserialize($snippets); foreach ($snippets as &$snippet) { $snippet['snippet'] = str_replace('old-url', 'new-url', $snippet['snippet']); } return serialize($snippets); } add_filter( 'post_snippets_export', 'ps_export' );Example that modifies data in snippets before an imported file populates the site:
function ps_import( $snippets ) { $snippets = unserialize($snippets); foreach ($snippets as &$snippet) { $snippet['snippet'] = str_replace('old-url', 'new-url', $snippet['snippet']); } return serialize($snippets); } add_filter( 'post_snippets_import', 'ps_import' );If you don’t want to modify snippets, but variables or variables’ default values, you can use
$snippet['vars']instead of$snippet['snippet'].Cheers,
JohanThanks for the suggestion. Using the wp_editor() for editing the snippets have crossed my mind.
It would need a redesign of the snippets settings page though. As the snippets currently are displayed all at the same time, it would be a lot of wp_editors displayed at the same time and by that probably slow down the speed of the page.
So I’d need to change the workflow to edit one snippet at a time instead. I’ll keep it in the back of my head, and see if I come up with some nice solution to incorporate wp_editor() down the road.Cheers,
JohanClifford,
Get Post Snippets v1.9.5 and this issue is fixed. Thanks for the report.
Cheers,
JohanThanks for the info. This is fixed in the latest update of Post Snippets (v1.9.5).
Cheers,
Johan@wp-fish
Thanks for your report. I installed the “Enable posts order” plugin to take a look what the problem might be. I noticed that Enable posts order doesn’t use the jQuery UI provided in WordPress, but tries to deregister jQuery UI and then loads an older jQuery UI lib on top of WordPress’.
That’s what’s causing the problem.The best solution would be if Enable posts order was updated to use
wp_enqueue_script( 'jquery-ui-core' );to load the current UI library, to avoid conflicts.Cheers,
JohanAdding a drop down menu to the widget is a bit too special functionality to include in the plugin by default imho. But what I did, was that I added a filter for the purpose in the latest update of the plugin (version 1.6).
With the filter it’s simple to add such a functionality yourself, which will survive plugin updates.
Here’s a piece of code you can add to your functions.php for your theme to get you started.
function paypal_purpose( $purpose ) { return ' <select name="item_name"> <option value="Donation Purpose 1">Donation Purpose 1</option> <option value="Donation Purpose 2">Donation Purpose 2</option> </select> '; } add_filter( 'paypal_donations_purpose_html', 'paypal_purpose' );Cheers,
JohanI’ve just uploaded version 1.6 of the plugin. Included in this update is an option under extras to set a checkout language. I believe this should do it. 🙂
Cheers,
JohanBaden,
Awesome! Thanks for digging and getting this information. the lc setting seems to do what you are looking for and I’ll add an option for that with the next update of the plugin.
Cheers,
JohanWell, as far as I know, PayPal doesn’t offer any setting that can be added to the form to force the landing page into a certain language. At least not what I’ve been able to find, so the plugin shouldn’t be able to affect what language that PayPal displays.
It’s strange though if the other plugin you linked to has a different behavior concerning language as you noted, especially as they have basically just copied my plugin and changed the name (but forgot to change the name on language files etc 😉 ), so that plugin should generate an identical PayPal form button as my plugin does.
If you do find something that controls the PayPal language from the site that sends the user to PayPal, please let me know and I’ll look into it as well.
Cheers,
JohanThanks for the notification. I’m aware of that issue, and I’ll have it addressed in an update quite soonish.
Cheers,
JohanThe plugin is now updated to v1.9.4 which should take care of this bug. If not let me know.
Cheers,
JohanThanks for the report. I tested the example you posted and I can confirm that I see the same behavior as you do. In the next version, coming in a few days, I’ll have this bug fixed.
Thanks again.
Cheers,
JohanCool that you found a workaround. I’ve added this to my to-do list for the future as well, to look into if I can get some further control via the API into the visual editor, for some more controlled inserts. But that will be after I’ve finished v2 which I’m working towards at the moment.
Cheers,
JohanAha, I see, it’s div snippets.
Well, what’s happening is that in the visual editor, the first snippet is inserted, and then TinyMCE places the cursor after the last inserted text (not after the last inserted HTML in other words), as it assumes you will continue writing where the text ends.That means that the cursor is inside the div after insert. Then when you directly add another div it will add it inside the one it’s already located in. So that’s what you see happening.
Checking the TinyMCE API, there doesn’t seem to be any control to override that behavior on insert, so I’d have to write my own addition to TinyMCE to change that behavior, which would demand a bit too much time than I can spare at the moment.
Anyway, the general recommendation is that when you are working with HTML via the editor in WordPress, is to use the HTML mode and not visual to avoid problems with HTML elements. So I’d suggest to adapt that method when using Post Snippets as well. Then you also don’t risk that the HTML get’s changed on save, as it can be when saving from the visual editor.
Another option, if you want to stay in the visual editor, could be to use a shortcode to insert the divs, then the visual editor doesn’t see the HTML at all, and the insert cursor will be placed at the very end on insert. By using the reserved {content} variable with shortcodes you can wrap content inside a shortcode, so you can have both opening and closing divs in the snippet and freely add content in between.
Hope this helps.
Cheers,
Johan