Does what I need

Hello; and thank you very much for taking the time to review.

my take on this revision of ultimate tiny mce is it is better for ordinary users and maybe not so much for developers.

Very interesting interpretation. You’ve hit the nail right on the head.

It was suggested to me by a few people to “tone down” my plugins; and try not to aim them at developers; but rather “normal” WordPress users.

I stopped using ultimate because of the constant advertising.

Yeah… well…. sorry about that. Lesson learned.

The colors for draft and status are interesting.

Thank you. And, agreed. It can certainly get a little “ugly” if you select colors that are too dark.

I use palleton for selecting color combinations that work well together. I’m color blind; so it’s even harder for me.

The one thing that needs to be added to the show ID option are taxonomy pages so category IDs will show.

I will certainly integrate this into the plugin; but I’d like to understand exactly what you are describing.

If you can provide me with the steps to replicate; and tell me exactly what needs to be done; I’ll add it to the plugin.

Again, thanks for the awesome feedback. Reviews of this caliper to two things for me:
1) Provides me with invaluable feedback; making me a better developer.
2) Makes WP Edit even better; user suggested features make up half the plugin.

Talk to you soon.

Thanks for your quick response.

Right now wp-edit shows id only for posts, pages, custom posts, custom pages but no categories. I have tested it with two different ecourse plugins and it shows the id for their custom posts and pages just fine. But there is no id for any type of category. I thought categories were in the taxonomy area in WP but I am just learning so am probably wrong.

See video
https://www.fly-fishing-colorado.com/testwp/wp-content/uploads/wp-edit.mp4

I don’t think wp-edit deletes any saved settings when the plugin is deleted. You might consider changing it to remove any saved settings from the db.

I thought there might be an issue or conflict with another plugin because when I deactivated wp-edit on another test bed, there were ids still showing on posts and pages. Turns out the Clean Retina theme from Theme Horse has some default setting to show ids for post and pages. With wp-edit set to also show a column of ids, I had two columns of ids. At least I know that wp-edit and wp-show-ids were not the issue.

My pleasure.

Right now wp-edit shows id only for posts, pages, custom posts, custom pages but no categories.

That is the intended functionality. It only adds the “ID” column to posts/pages/custom post types. It does not add any columns to categories or tags; of any type. (Thanks for taking the time to make the video).

I don’t think wp-edit deletes any saved settings when the plugin is deleted. You might consider changing it to remove any saved settings from the db.

That is correct… and intended. Sometimes it’s necessary to deactivate plugins to test for conflicts. For this reason; it’s not best practice to delete the plugin settings when the plugin is deactivated.

Unfortunately, there is no way to delete the settings when the plugin is deleted. This is because the plugin has to be deactivated before it can be deleted. And, once the plugin is deactivated.. the code never gets executed… so it’s impossible to delete plugin settings when the plugin is deleted.

For this reason… plugin developers (good ones ?? add an option (mine is under the “Database” tab) for deleting plugin options. This way, you check the box to delete and uninstall the plugin (from within the plugin settings page)… and this will delete all database options.

[]… With wp-edit set to also show a column of ids, I had two columns of ids.

Yeah, this is probably because each of us were using different names for the category to show the ID’s. Since they are both unique; both columns displayed.

The last 5 plugins I deactivated and the clicked delete produced a button that said delete files and data and another that said cancel. The delete takes the data out of the db. You just have your setup different and I could not find it. Thanks for the explanation.

The last 5 plugins I deactivated and the clicked delete produced a button that said delete files and data and another that said cancel.

Yes. Deleting “files and data” is one thing. Deleting “database options” is something else.

“Files and data” exist in the file directories. It will delete the plugin folder; all it’s files and folders inside; all javascript, php, html and whatever else files.

However, the “database options” will remain. These can only be deleted by code provided by the plugin author.

A plugin author can only “hook” to the uninstall option. We cannot “hook” to the delete option.

When you click “delete”… that is WP taking over. The plugin has to first be deactivated before it can be deleted. Once the plugin is deactivated… it cannot render it’s code anymore (it’s deactivated). That’s when WP takes over with the “delete” option. It will delete files, folders and data from the file directories… but it will not delete “database options”.

So… are you 100% certain the last 5 plugins you deleted removed the database options?

Now, a plugin author can hook to the “deactivate” button… and run code from there… which could remove the database options. But this is not preferred. A plugin author SHOULD NOT delete plugin data on plugin deactivation. This is because of what I mentioned about testing and troubleshooting.

Instead, a plugin author should ALWAYS provide a method to completely remove their plugin data (files AND database options).

Whew… thanks for reading ??

I was not specific enough. These plugins had installed and produced extra tables in the DB. I use a backup plugin that allows me to see the table names and sizes in the DB. When I deactivated the plugins, they were just deactivated like any other. When I clicked the delete button after deactivation, I got two choices. “Delete These Files and Data” and “Return to the Plugin Lists”. Most times I get “Delete these files” and “Return to the Plugin List”. On these plugins I used the delete files and data. Since this was something that I had not see very much, I thought maybe WP was requiring more cleanup on deleted a plugin.

After I used the “delete files and data” function the special tables were gone from the DB. Now these may have been only data or they may have been data plus plugin settings and options. Anyway they were gone. I did not look into the DB directly and search for the plugin name with phpMyAdmin so anything that was added to the wp_options table or other core WP tables may have still been there. This is what I meant.

Does wp-edit remove the data and any options set so after file deletion, the DB has no information about wp-edit?

Okay, thank you for the clarification.

Do you remember what the name of one of those plugins may have been? That’s interesting that it cleaned the DB entires as well. I’d love to try it and see what they are doing differently.

Perhaps there is another WP hook with which I’m not yet familiar.

Take a look at the PODS plugin. After activation, you should see a pods table in the db. After deactivation and delete, it is gone. Pods even says it is as if Pods was never here.

We actually turned that off, now it just clears our caches from the DB, it leaves the tables in place. Users can go to Pods Admin > Settings > Reset and be able to delete all Pods data (and deactivate the plugin at the same time). This was preferable since people may have tried deleting the plugin while trying to reinstall the plugin files, but unknown to them their data would get wiped and then on reactivation everything was missing.

Usage to hook into it is register_deactivation_hook( $your_plugin_file, 'callable_function_here' ); We hook during ‘init’ action.

Hi Scott, nice to e-meet you.
Thanks for chiming into the conversation.

Yes, I think we are talking about the same thing,

IF HOOKING TO “register_deactivation_hook”:
The applicable code will be executed every time the plugin is deactivated.

While this may seem logical… it is actually not very user-friendly.

People deactivate plugins all the time; for a variety of reasons (testing, compatibility, troubleshooting)… and they may not necessarily wish to also delete their settings.

If we delete the plugin options during this hook; each time the plugin is deactivated; it will delete all the user settings.

This frustrates a lot of users because their options are now gone.

INSTEAD:
We (plugin authors) provide an option in our settings page; to uninstall the plugin AND remove all plugin data (database options).

We code this option to specifically remove any plugin options from the database (may be a table; user meta; post/page custom fields; etc.).

This way… the plugin settings are still safe (when the plugin is deactivated) and can only be deleted by using the plugin option to remove all plugin data.

Sorry, I meant https://codex.www.ads-software.com/Function_Reference/register_uninstall_hook instead, we don’t have it in our code anymore so I got confused when looking at what we had left.

Sorry, I meant https://codex.www.ads-software.com/Function_Reference/register_uninstall_hook

Awesome!! Was not aware of that hook. I started my plugin with an option to uninstall; so I never looked at the uninstall hook.

Thanks bunches ??