Editing large tables

Hi,

thanks for your question, and sorry for the trouble.

Yeah, the experience of editing large tables is bad at the moment, I agree ??
But there are good news: I’m already working on a redesigned “Edit” screen that will work much better and faster with large tables. Unfortunately, as this is not trivial, and as I’m very busy at the moment, this will still take some time.
This should also remedy some issues with quicker access to the buttons.

For the size of the edit fields: This might help at the moment: https://tablepress.org/extensions/input-field-size/

Regards,
Tobias

Hi Tobias,
thanks for your prompt response (excellent support!) —?I’m looking forward to that new version then! Meanwhile, I’ll see what that extension does for me!
Best wishes,
-Rolf

Hi,

no problem, you are very welcome! ?? Good to hear that this helped for now!

Best wishes,
Tobias

Hi Tobias,

Any updates on the issue with table slowness with 1000 records? Thanks,

My solution to the large table issue is to export the table (HTML exporting with UTF-8 or UTF-16 coding works best for me). I then import the entire table into a FileMaker database, where I now do the maintenance —?effortless, fast, painless. I then periodically export the complete database (again, HTML / UTF-8) and re-import it into TablePress, replacing the existing database with every import. OK, the refresh after the import is still painfully slow, and it seems to take ages until I can update the “last modified” entry in the comment to the table?—?but at least, I can avoid any editing other than in the comment. The same would work with MS Excel, I’m sure —?though I really prefer a database over a spreadsheet. I only edit small tables in the TablePress GUI directly.
On the bright side: Tobias fixed one sticky speed issue (thanks a lot! Or was this a WP update that had this effect?): always the first “Save” in a TablePress session used to take forever, no matter how big or small the database was. With the latest update(s) (1.8.1?), this issue is entirely gone.

Best wishes,
Rolf

Hi,

@mowill: No, sorry, nothing new yet. I can only suggest to try different browsers (they really show significant differences in the speed here!) or try the workaround with editing e.g. in Excel and then re-importing the table.

@rkyburz:
That issue with the “first Save” sounds weird. That should never happen like that and therefore there was no “fix” for this in TablePress. It must have been a WordPress or server software update that fixed this for you ??

Regards,
Tobias

Hi Tobias,

Whatever fixed it?—?the saving issue is gone. It must have been WP, as that’s the only thing that changed, apart from the occasional plugin updates. I haven’t changed browser. The issue with large tables is linked to the browser (Chrome in my case) loading the entire table into the buffer. But also subsequent changes in the width of individual columns, etc. are incredibly slow, hence I really prefer external editing with any table with more than, say, 100 – 200 records.

Best wishes,
Rolf

Hi Rolf,

yes, that is the classical way how this issue shows itself ??

Unfortunately, at this time, your method of external editing or the mentioned try of different browsers are the only good work arounds.

Best wishes,
Tobias

Hi TobiasBg, any status on a fix for the slowness with large tables?

Hi,

no, sorry, no real progress here ??

Regards,
Tobias

Hi there,

let me just throw in my 2c worth of advice, partly doubling up on what I stated above. As mentioned, some of my tables are large (1300 & more records, up to 10 fields), and right now, editing in the admin GUI is so slow, clumsy and unhandy that I concluded that simple amendments / speedup fixes etc. won’t do: the editing GUI needs a serious rework / redesign for editing large tables becomes usable. Understandably, this is not going to happen in a matter of weeks, even months.
So, for most of my tables (except very small ones) I now export into CSV, then import into an external, local utility (Filemaker in my case, but MS Excel should work as well). From then on, I do all editing in that external utility. I never re-import from TP again, but just periodically export (UTF-8 into HTML works best for me), and then reimport those updates (the full table, every table, replacing the old one) into TablePress. Filemaker fills empty cells with “<br/>” — but that is OK with me (TP is fine with that, too).
I noted that even just importing a large table can be painfully slow, because apparently the browser needs to load the entire table before it can display any contents, and (for example) further mods in the header info (which are not touched by the import) are possible. The current version of Chrome behaves much better in that respect than older ones, but it still may be painful. So, before importing a large table, I open any other table, make sure the “Content” tab/segment is closed, then select “Import” -> select the local file to import, select the target table (replacing entire content), then import. The import still takes a few seconds (my upload is about 0.5 MB), and editing the header takes another few seconds, but nowhere near what it used to be. Just don’t open the “Content” tab for this table, but open a small table before re-opening the tab.
It’s a livable situation for me (and I simply don’t know of any alternative to TablePress anyway!).

Best wishes,
Rolf

Hi Rolf,

yes, this procedure is indeed the best workaround for large tables as of now.

Regards,
Tobias

Just chiming in to say that I’m another user with a large table that has many rows… almost 2,000. The Tablepress backend UX with this amount of rows reminds me of dial up days, except even worse… so I do all of my editing in Excel, and then import the table as needed.

If this plugin didn’t have the import option, I wouldn’t be able to use it at all.

Not knocking Tablepress (I’ve even donated in the past) but hopefully we’ll see some further development in the future for users that have tables with a lot of data.

Hi,

sorry to hear that you are also affected by this. Yes, I’m working on a faster solution, but it turned out that it’s more difficult than I had hoped, especially in regard to cross-browser support and responsiveness.

Regards,
Tobias