bobbysmith007

Dates are highly non-trivial and I would gladly accept patches improving them.

To simply treat them as strings and use iso-format(yyyy-mm-dd), I believe you can just set the auto_date parameter on the add_db_table_editor call to false. I have waffled on what the default of this should be or how to otherwise improve this, but in my locality and with my customer base there seems to be a strong preference for mm/dd/yyyy and so that was what the default was set to originally.

This is included in the “ReleaseNotes.txt” file separately as well as via the github commit log.

https://github.com/AccelerationNet/wp-db-table-editor/commits

I will copy it into the wordpress README.txt file as well, as I didnt realise it was trying to link there regardless

Thanks for the review and thought about the video! I very much appreciate feedback.

The proper call is documented in both textual examples in the plugins file, and in the README for the plugin. Additionally, I tried to make it clear on the description for the plugin, that using it would require both SQL and PHP knowledge as well as editing the functions file in the theme. If you think I can do anything to make that more clear please do let me know.

I don’t have any setup for making videos and personally have never watched a video tutorial (much preferring step-by-step textual instructions and example code). As this is something I develop at work, without some possible revenue from this video, I am hard pressed to justify time spent on it (especially as I have no current way to make videos).

I have tried to provide good textual documentation, but if you make a suggestion for improvement, I would be happy to include it.

If someone else wants to provide a video of implementation, I would also be happy to include that as part of the standard documentation for this plugin, but I feel I will be unable to do so personally (though we have some new interns so perhaps I can task one).

Glad this was resolved for you ??

I have had other people report this: https://www.ads-software.com/support/topic/how-do-i-begin-2

But have not been able to recreate it or get feedback from the people for whom this doesnt work. Any insight will help this be a better plugin

Did you add calls to the add-db-table-editor function in your theme’s function file? Do you have appropriate permissions configured (by default you must have edit_others_posts)?

Once db table editors are configured, if you have the correct permissions, they show up in the admin side bar under “DB Table Editor” which leads to this url: /wp-admin/admin.php?page=wp-db-table-editor

If this menu is not available, either the user does not have correct permission or the plugin is not correctly installed / activated.

Thanks! I always mess up svn… its why I use git.

Ok, I see the problem and believe I have pushed a second and third patch pushed that will translate the page titles. I think this is probably done then.

Thanks again for the help and cheers!

I did find a bug where it was enqueueing the wrong js file. I pushed a patch resolving this to github. As far as page titles go, I couldnt recreate. Maybe an example of what you tried?

Everything that you committed looks pretty good! Thanks for the efforts!

As far as the menu titles goes, I believe it is figuring out the “current” table in the dbte_scripts function by finding the table name in the scripts hook. (The hook is expected to look like “db-table-editor_page_dbte_{table name}”). Then the name produced should match the id of one the data tables.

Currently testing this and looking to this issue more closely

I would certainly accept any patches internationalizing the plugin, but I probably don’t have time to work on this myself.

The plugin (by default) requires all tables to have an id_column specified which defaults to id. Perhaps this column is missing from the tables?

I have not tried to do this. You might try checking:

https://wordpress.stackexchange.com/questions/1604/using-wpdb-to-connect-to-a-separate-database

We use the global wpdb object, so in theory you could set this to something else while rendering the db-table-editor, though there is surely some code to work out along the way. If you figure it out, please provide an example so that others may benefit.

Cheers!

No worries, your english is very good ?? I think I understand what you are saying.

All plugins are already loaded at init time so for the current case, there is not a great need for a db_table_editor_init action. If my plugin *had* something it needed to do at initialization, then your plugin might need to wait till mine is initialized.

That said, it is arguably clearer for your code to have a direct action for this, rather than hooking init and checking for add_db_table_editor, so I am adding that hook and updating the documentation.

Thank you for the suggestion, look for version 1.3.2 soon