I'm creating an inline CMS using ckeditor. The idea is:
Client logs into admin area
Login beings a session
Client is directed to pages on their website where they can edit predefined regions
The regions are specified with the contenteditable attribute:
<div contenteditable="true">
safsdfdfsdfdfsdfsdfds
</div>
Since a session is created when the client logs in, I've written some PHP that knows to enable ckEditor and all the CMS functionality if the client is logged in.
The issue I have, is when not logged in, contenteditable="true" on divs still allows you to edit them without a WYSIWYG as the default behaviour for the browser. Obviously this is no good. How do I stop users being able to edit the page?
You could setup the divs like that:
<div data-contenteditable="true">
And have a JavaScript (if in admin mode) go over all divs (document.getElementsByTagName("div")) and if they have data-contenteditable set the real contenteditable.
Otherwise let the server only include contenteditable if in admin mode
In PHP:
Create first a function that returns true if the user is logged in, then, for each editable region (in your views):
<div<?php if (your_login_check_function()) echo ' contenteditable="true"'; ?>>Lorem ipsum</div>
It's a bit tedious but it should work.
Or in jQuery (as proposed by Moritz):
Add a data-contenteditable="true" to your editable nodes, then add a script to the end of the page when the user is logged in:
<script>$('[data-contenteditable]').attr('contenteditable', true);</script>
Related
I am relatively new to wordpress plugin development and I have read through the wordpress codex but outside of best practices and simple example of the uninstall functionality I am not getting much in the way of what the plugin can do when the user actually uninstalls it.
What I am looking to achieve is when an user uninstalls my plugin a popup appears asking them if they want to just remove the plugin files or the plugin files and all of the content the plugin has uploaded to their site. For a bit more context my plugin's primary function is to migrate data stored on a separate server into the user's instance of wordpress as posts and those posts are what I am looking to remove if the user selects that option.
Below is my current setup for the uninstall and when I click uninstall in wordpress, wordpress does uninstall my plugin(removes the plugin folder and files from its directory) but the popup isn't displaying during this process. I originally thought it was a styling issue but the HTML in the popup file isn't being loaded. I have also checked the file path variable and it's the correct path. So I am not sure what is preventing the popup from being displayed and allowing the user to select whether or not the content should be deleted along with the plugin or not.
Any help or insight in this matter would be greatly appreciated!
uninstall.php
<?php
//checks to make sure Wordpress is the one requesting the uninstall
if (!defined('WP_UNINSTALL_PLUGIN')) {
die;
}
$my_plugin_file_path = trailingslashit(plugin_dir_path(__FILE__));
include $my_plugin_file_path . 'templates/my-plugin-uninstall-popup.php';
my-plugin-uninstall-popup.php
<!-- styling for popup -->
<!-- end of styling for popup -->
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<h2 class="modal-title" id="myModalLabel">Uninstall popup</h2>
</div>
<div class="modal-body">
<form action="<?php echo esc_url( $my_plugin_file_path . 'my-plugin-uninstall-executor.php' ); ?>" method="post">
<label>Do you want to remove the content that this plugin has uploaded?</label>
<input id="delete-content-yes" name="delete-content" value="YES" type="radio" />Yes
<input id="delete-content-no" name="delete-content" value="NO" type="radio" />No
<input type="submit" name="submit" value="Submit" />
</form>
</div>
</div>
</div>
my-plugin-uninstall-executor.php
<?php
if (isset($_POST['delete-content']) && $_POST['delete-content'] === 'YES')
//delete content from user's wordpress db
Unfortunately, as far as I know at least, there's no official hook available to display a custom uninstall screen.
In older versions of WordPress there used to be an Uninstall confirmation screen -although I'm pretty sure there was no way to hook into it either- but nowadays WordPress simply shows a JS confirmation box ("Are you sure you want to delete [Plugin Name] and its data?") before running uninstall.php -if found- and deleting its files.
What I've seen other plugin developers do in this case is include a custom Uninstall screen in the plugin's Settings / Config page which allows them to do pretty much what you described in your question. It's not an ideal solution as some users might uninstall the plugin the "traditional" way if they're unaware of your custom Uninstall screen so you won't be able to show your confirmation screen/popup, but that's the best you can do at this time.
If you want to take it a step further this answer tells you how to uninstall a plugin programatically. It's pretty old now (2011) but if that still works then maybe you could delete your own plugin after running your custom actions.
do_action( 'pre_uninstall_plugin', function( $plugin ) {
if ( $plugin === 'path to your main plugin file from plugins directory' ) {
wp_redirect( 'url of your custom uninstall script' );
exit();
}
} );
This will abort the builtin wordPress uninstall code and your custom uninstall script can do anything you want but of course you will need to implement quite a bit of code and this would be difficult if you do not know WordPress well but if you do this you will learn quite a bit on how WordPress works in admin mode.
ADDENDUM
On further thought I think this can be done quite easily. Your custom script should show your form in a custom admin page. Submitting this form can save your settings in transients in the wp_options table and then redirect to the original delete URL. In the action 'pre_uninstall_plugin' if the transients exists then do nothing and let WordPress call your uninstall script. Of course your uninstall script should read your settings from the transients in the wp_options table and process accordingly. Redirecting back to the original delete URL will let WordPress handle the generic part of deleting your plugin and your uninstall script needs to handle only the plugin specific part of deleting your plugin. If this delete was done as part of a bulk delete request then before redirecting you should clean the original delete URL by removing previously deleted plugins.
ADDENDUM to ADDENDUM
In fact it is possible to do even better. The basic idea is to intercept the plugin delete request, do a HTTP redirect to a page that configures the delete request, saves the delete configuration to the database and then do a HTTP redirect to the original delete request. When the plugin's uninstall script is called it reads its delete configuration from the database and deletes accordingly. In this case the interception should be done as early as possible so action 'admin_init' would be a good choice. The advantage to early interception is if the plugin is being deleted as part of a bulk request since the interception is done before anything has been processed the original delete URL is still valid and you do not need to worry about previously deleted plugins.
There is quite a lot of code to write to implement this solution which I do not have the time to do but I can give you an outline of what to do.
Using add_submenu_page() create an admin page to configure the uninstall for your plugin. Although this page will be invoked by a HTTP redirect, admin pages are invoked via a hook and this hook requires an entry in the global $menu. add_submenu_page() is used here only to create an entry in the global $menu for the function that will display the admin page. The menu item that is also created is not needed and can be hidden.
Using an action on 'admin_init' intercept delete requests for your plugin. The delete request looks like this.
http://aaa.bbb.ccc/wp-admin/plugins.php?action=delete-selected&checked[0]=your-plugin-path.php&plugin_status=all&paged=1&s&_wpnonce=027649d7ff
You can use $_SERVER and $_GET global variables to help you parse the request URL. (The global $pagenow may be useful here.) If the request is a delete request for your plugin. Use wp_redirect() to do a HTTP redirect to the admin page you created using add_submenu_page(). You need to pass the original URL after encoding using urlencode to your admin page as a query parameter. The URL of your admin page looks like this.
http://aaa.bbb.ccc/wp-admin/admin.php?page=your-settings-page
You can get this URL from the menu item as it is just the href of a HTML A element.
Your handler for your admin page should show your settings form for configuring the uninstall of your plugin. You can pass the original delete URL as a hidden input field so when submitting this form it will also send the original delete URL.
The handler for the submitted form should use set_transient() to save the settings as transients in the database. Then it should do a wp_redirect() to the original delete URL.
The 'admin_init' handler will be called again and should check if the transients have been set and if they have been set do nothing and let WordPress handle the delete request.
Your uninstall script should read the transients from the database and process accordingly and then remove the transients from the database.
Alternatively, you can use jQuery to intercept the click on the 'delete' HTML A element and display your form instead. Then use an AJAX request to save your delete settings in transients in the wp_options table. When the AJAX request returns you can then forward to the original delete URL. Your uninstall script needs to read the delete settings previously saved in the transients.
This approach involves less code but is dependent on the specific HTML implementation of the HTML delete element (currently a HTML A element with class 'delete'). Since, WordPress can change this implementation this approach is not safe with respect to upgrades. Of course, this will not work with bulk deletes but in that case you could intercept the bulk delete action and show your form and proceed as before.
The website I am working with is a property sales site where the user can freely advertise their property. Properties can be for sale or for rental: http://ev-villa.com
The search panel I designed has 2 tabs: For Sale and To Rent. To get a clearer understanding of the following problem I would advise you to load the site from the above URL. As the site is multi-lingual you may have to change the language to English by clicking on the flag icon in the top right of the page.
So the tabs in the search panel (left side of the page) can be clicked by the user and this tab will now change colour to show that it has been selected. This is handled by a variable in the URL called saleType. So if the value of this variable is equal to "torent" then the "To Rent" tab will change colour (The css on the page changes when the variable's value changes). Apart from changing colour this variable also affects the search results gained when the user clicks the search button.
The issue here is that the variable change is done by a link which requires reloading/redirecting. So if these tabs are clicked a few times, the result is that the user will have to click the browser's back button quite a few times to leave the website or to get to other parts of the website.
I am basically looking for an alternative solution to changing the value of this variable in php without using a link so that the value is set without redirecting the browser to a new page. I am trying to avoid the use of JavaScript and other languages, to ensure maximum cross-browser and cross platform compatibility, making sure this website works for browsers that don't support JavaScript or don;t have JavaScript enabled at the time of use.
I wasn't happy with my previous answer, so I gave it a little bit more thought.
Here's a workaround, completely without JavaScript and without requesting the server:
Instead of 1 form for both types of search (rent/sale), create two identical forms but with different action attributes.
<!-- Rental -->
<form action="search.php?saleType=torent" method="get">
...
<!-- Sale -->
<form action="search.ph?saleType=forsale" method="get">
...
Use CSS to position the forms on top of one another, and to hide one of the forms.
Use the Checkbox Hack to detect a click event on the form "For Sale" and "To Rent" links (you'll need to make them a <label>), and to hide/show the respective form.
Goal
I would like to be able to dynamically create javascript and serve it based on preset configuration from the application. The url of the javascript resource can remain the same. The idea is to make available the option to change javascript parameters depening on backend configuration.
An example of this:
The administrator has a set of classes that when clicked upon open a modal pane for the end user. lets say that those classes follow the format of *_modal where the * portion of the class will indicate a portion of the url where the content of the modal pane will be pulled from via ajax.
For example:
click me
would then trigger an ajax event on click where the contents from #contents would be pulled from http://www.myurl.com/modal/orange and displayed in the div #modal_output at the client side.
lets say for some odd reason the administrator for the site decided that he wanted to change the id of the display modal pane for some reason to #modal_output_view . Normally this would require some modification of the javascript and possibly the static output of the page.
I would like to forgo that and offer a configuration option whereas the administrator can choose what the div id would be for the modal output.
At run-time the resource would be requested, php would grab the configuration value for that div's id and return a string in the form of a javascript resource.
Secondly I will be using magento, is there a good way to improve the performance via cache?
Is there any way to use a cdn?
Questions
1) I know how to do the configurational portion, asside from doing this within an appended block or inside of a template file:
<script type="text/javascript">
(function(){
configuration_value = <?= Mage::getStoreConfig('my/config/value');?>;
})();
</script>
is there another easier way to interface between magento's configuration values and client side javascript?
2) Will this work correctly? are there any issues I might face? The key being the .php extension
3) Are there existing core javascript classes/methods that may be useful? Any documentation?
I am trying to get people that are not logged in to log in by linking them to the log in fields in the sidebar.
So far I managed to accomplish this:
<?php comment_form(array(must_log_in => sprintf(__('You must be logged in to comment.')))); ?>
So I am using the Login with AJAX widget, or I could just place the plugin's template tag in there which is <?php login_with_ajax() ?>. Right before the widget I have placed <a name="reg"></a>, so when they click the link to log in they get to where the log in form is, but they are not placed in the username field. Is there a way (I doubt it) where I can place the focus in the username field? That is to have a blinking cursor in there?
"It is not possible" is also an acceptable answer, so I can move onto my next problem.
Assuming something like <input type="text" id="username">, you could use
document.getElementById("username").focus();
in JavaScript.
I am currently designing a 'Sign In' dropdown much like Twitter login dropdown. You can see the current progress of it at http://mashup2.sunnydsouza.com/index3.php
As you can see there, for some reason, there are certain css issues because of which am not exactly the same effect as shown in this tutorial http://aext.net/example/twitterlogin/#
Am not sure where am going wrong in this css (front.css) file. Is there some over-riding issues?
I want the same exact effect as shown in the example site.
On another note, also, am using JQuery validation plugin to check whether the username/pass fields are entered before clicking submit. What I want is that if a user enters an incorrect username/password, the error login message should come within the dropdown itself, without reloading the entire page again
But when user enters correct username/password, the page would refresh and the 'Sign In' would now replace with the username of the user entered (that will a dropdown too, with Control panel,logout options etc)
One of the problems is because in your stylesheet you say #topnav {...} but in your HTML topnav is assigned as a class, not an ID. None of the #topnav styles are being applied.