Hi Antonino,

Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

-

Our management and the developers agreed that the buttons should be named like that.

For example, if you hit "Apply and duplicate" on any row,

it leaves the Editing Modal open so then you can keep hitting that button to quickly add more duplicates.

-

Or if you hit "Submit", in that case it just makes one duplicate of that row but it closes the Editing Modal and stops the action.

You can see more details explained behind that logic here : https://wpdatatables.com/documentation/front-end-editing/creating-editable-tables/.

If you have an idea how this can be improved, you can make a development suggestion.

Please feel free to search on our suggestions page, 

 to see if someone may be already suggested this feature. If you can't see it, feel free to add your suggestion there,  and as more people vote, the feature will move higher on the priority list.

You can certainly follow our changeLog page if you'd like ( it is also available in the plugin dashboard), where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

-

Or, if you just wish to simply edit the label of that Button, you can easily use any translation Plugin and just change it for your use-case.

The plugin can be translated using POEDIT or Loco Translate easily. 

I suggest installing Loco Translate since it's within WordPress and it has a simple UI,

you can simply "search and replace" any strings you need.

First, please check if the language you need is already one of our existing language folders in the Plugin

or if you need to add a new folder there.

You can use FTP or your Hosting File manager and go to this path :

../wp-content/plugins/wpdatatables/languages

Check if your language locale is there.  For example for Italian, folder should be named as 'it_IT'.

You can check the full list of all WordPress Locale proper folder and file names here.

-

If you can't see your language folder, then you need to add a new folder and name it appropriately for the WP locale.

-

Here is an example of how i add a new language in Loco Translate, let's say for Spanish ( locale es_ES) :

First, we add a new folder in the FTP path in the plugin languages files in this path :

../wp-content/plugins/wpdatatables/languages

For Spanish ( Spain) , i add es_ES folder :

then you can take the "default translations" from English, from en_US folder, copy the 'wpdatatables-en_US.mo' and 'wpdatatables-en_US.po' files and paste them in the new es_ES folder.

Then load Loco translate in your WordPress, choose wpDataTables / Spanish language, 

search any strings you wish to edit, and translate them as needed.

I hope that helps.

Hi Antonino,

Once again my apologies for all the waiting time.

I did my best to try and do tests according to what you described, and i am not able to understand what you mean.

1. When it comes to a difference between server-side and non server-side, it is absolutely the same.

It is because, in order to have Editing - you need to enable server-side.

If you disable server-side, then it's not possible to Edit Manual or SQL tables.

-

Just for Manual Tables we can not toggle it, but on SQL Tables you can disable server-side, which automatically also disables editing.

I recorded a Video where i did my last testing today and everything seems perfect in my opinion.

For example, if i take an existing row, click "duplicate" we got those offers, if you wish to edit it or just simply duplicate the row and keep going.

As long as you keep hitting 'Apply and Duplicate" , if you edited the row or not - the Table just keeps adding a new row exactly the same as duplicate;

Then you can edit any of the rows along the way - and when you're finished, hit "Submit" then the action stops and the modal closes.

You can download my Video here.  https://we.tl/t-WeYtTSAR1I

Let me know if anything is not clear, if you can still see any issue let me know, but please try to elaborate more to clarify what would be your preferred improvement to our existing logic, how the duplication should work compared to what it is now.

Thank you.

Hi Antonino,

You're welcome. Thank you again for your patience and for pointing us to the right details so that we can isolate the different behaviour of the duplicate row functionality for the action of "submit/ok" between Manual and SQL Query Tables.

We are still going through all the details/logic and to confirm what our developers initially intended to be the 'default' behaviour and doing more tests with the QA Team.

We will update you as soon as possible and to confirm if we plan to change/improve how it functions for the SQL Query tables.

Thanks again.

Hi Antonino,

Just wanted to let you know we are still testing how the intended logic for this use-case is meant to be, in regards to the row duplication;

we should be able to provide you with an update very soon.

Thanks again for all your patience.

Hi Antonino,

I just want to follow up to keep the ticket alive.

After further tests, at the moment we are not able to change how the duplication of rows works for the SQL Query Tables specifically.

As we saw - and as you pointed out, the Manual Tables behave in a way suitable for your desired use-case, while the SQL Query tables work differently.

Right now we can not change this behaviour, but our developers will inspect everything and we will do our best to make improvements on this functionality.

For the time being, you would have to use Manual Tables in order to have the duplication working as intended for your scenario.

If we make an improvement/change on how the duplicated rows work on SQL Query tables, we will make a note on that in one of our future Updates.

If you have an idea what you would like us to change; what would be the best improvement you would like to see;

Please feel free to search on our suggestions page, 

 to see if someone may be already suggested this feature. If you can't see it, feel free to add your suggestion there,  and as more people vote, the feature will move higher on the priority list.

You can certainly follow our changeLog page if you'd like ( it is also available in the plugin dashboard), where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

Hi Antonino,

Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

Thank you for this feedback.

I will check again with our Team, it seems to me you have a valid point.

We will do our best to perhaps either just treat this as a fix needed if that might be a better solution as you said.

We will check again and I will report back to confirm it for you, how it will be treated as a task.

Thank you again for your patience.

Hi Antonino,

I have an update from our end.

Our developers and the QA Team isolated exactly what the issue is.

The logic behing how that "OK/submit" button makes a new row, right now it is set to only 'look' when the origin Header of the "ID column for editing" is named exactly as on our Manual Tables, which is 'wdt_ID'.

If the Column is named anything else, then that "OK/submit" button does not properly make new duplicated row, and this bug happens.

So if we go to PHPMyAdmin for any Custom SQL Table, and just rename the "id" column we use for Editing to be "wdt_ID" and set it up to be unique and auto increment integer type;

now it works perfectly in this SQL Table, too.

Please download my Video to see a quick demonstration of this workaround solution.

So for the time being, you can either rename the ID column for editing to wdt_ID;

( Of course, you can change the displayed column name in the Column display settings to anything else)

or you can hide the "OK/submit" Button with CSS if you need it to be named differently.

But this is being flagged as a bug now.

Our developers isolated the bug, and they'll add it to their queue for fixing.

 They will do their best to build a fix as soon as possible.

 We don't have an ETA on when the fix will be available, but please keep a lookout on our wpDataTables changeLog.

It will be stated there during updates which bug fixes have been implemented at each update. If they create a fix in between updates, I will make sure to send it to you.