Extension talk:TableEdit

This page is for bugs, requests, and questions about Extension:TableEdit. Please add your item at the end of the page, and include your MediaWiki signature (" ~ ") at the end of your post.

Row Data spacing
I've noticed that when I save data in a cell, the way it applies to the page puts  tags around that data. The end effect causes the data to have extra spacing between rows. Example :  test It would appear this is caused by the way data is saved in wiki format from the editor. test
 * - bgcolor=#F7F9FA

Is it possible to force it to add the data to the same line as the start of the cell? Like this.. Thereby removing the  tag. test Using Version 0.8 --Bandophahita 19:06, 17 September 2008 (UTC)
 * - bgcolor=#F7F9FA
 * test

More Styling Information
Is there more styling information you can include? Like adding attributes to the other cells besides the header, add a border around the whole table? Or refer to a style class?

Rational for off page data
I was just wondering what the rational was for storing data off page. In a case like this it would seem that data entered would not be accessible to the standard wiki search. Is this true? --Dtsig 02:59, 21 April 2007 (UTC)
 * the text gets stored in the wiki as if it was a regular table. There are two reasons for storing it in the external database.  The first has to do with asynchronous data mining of the table content. The idea is that middleware can be written to work on the external db without interfering with the wiki's db or having to go through the MW interfaces.  I'm working on that kind of middleware right now, but it's in Perl, not PHP.  The second is laziness/lack of imagination/coding skill on my part in terms of how to implement it if it was just saved in the wiki.  In hindsight, I probably could have spent more time adapting whatever the parser already does with tables.  -- JimHu 03:15, 21 April 2007 (UTC)
 * Is it possible to simply switch off the external storage? Possibly a variable set so the external db is not required.? --Dtsig 17:22, 24 April 2007 (UTC)
 * not yet. The table loads from the database, not from the wiki page.  That could change in the future, especially with contributions from other coders (hint, hint) JimHu 23:59, 24 April 2007 (UTC)

Bulk load from a CVS or XML file
It would be great if you add the capability to read in a CVS or XML file

New TableEdit feature/enhancement --Dtsig 14:39, 6 August 2007 (UTC)
There should be a way to wrap it and have it create a table definition 2) If a user messes with the data or worse screws with the tag then we are really hosed For those who don't need the data in a DB for other use, wouldn't it be possible for the routine to parse out a generic table and process just as if it came from the db? I think this would be a great enhancement.  So a simple tage   Does anyone Know how to fix this or hide the "edit table" link when a user is not logged on?

Question about lines showing in the table
This was addressed somewhat (above), but I am seeking more clarification. When I click the "edit table" link, it displays the borders no problem. But when the table is saved/viewed on the portal, no borders are displayed. Is there a way to make the borders visible? Above, it references modifying CSS properties, but I am lost as to where/how to do that. Is that modification made in the portal code itself, after the table is generated? If so, what and where do I insert in the code to make the borders appear (and does it have to be done for each and every table)?

In addition, another comment relates to using the PrettyTable template. On my wiki (MediaWiki), when I edit the page containing the table, it uses the PrettyTable template, but it does not exist on my wiki (IE, when I click on it's link there is no content/page is not created).

Other than this minor visual issue, we love this table product and use it extensively on our intranets.

If anyone could assist us with this, we would appreciate it. Thank you very much!

Examples?
I could only find this page on your wiki where it's used in a template on a page (at the very top) and it's broken. This page has one example (in German, but it's something).

This extension looks very cool, but I can't get my head around it on my first look, and would like to see where it has been used. -- Chriswaterguy 08:35, 11 June 2008 (UTC)


 * you could always snoop around the EcoloiWiki table templates Category:Table_templates  --Russell Smithies

Installation: beware of «update_schema.php»
update_schema.php (from «TableEdit.0.8») is useless, because:
 * Works only under Linux (it use PHP function «getopt», it use some UNIX utilities, ...);
 * «ENGINE=MyISAM» and «DEFAULT CHARSET=latin1» are hardcoded in SQL texts.
 * TableEdit_tables.sql contains some syntax errors (L18, L33, ...).

Instead of running «update_schema.php», users must critically review TableEdit_tables.sql, fix errors and parameters («ENGINE», «DEFAULT CHARSET») and run it manually. --StasFomin 12:37, 28 July 2008 (UTC)
 * Note added to the installation instructions to note problems with update schema. We let the schema SQL docs and the installer get out of sync, since we're trying to reproduce schema adjustments we made manually, and I screwed up in manually editing the SQL (left out some commas). We're working on a new version of update schema, but it's not there yet (because I made some additional modifications - adding a timestamp to the metadata). We can try to make it more platform independent if you can give us some help; it was actually tested on Macs, not Linux --JimHu 15:30, 28 July 2008 (UTC)

Installation error;
mediawiki 1.12 php5  phpmyadmin

I just can't run the file "TableEdit_tables.sql", I kept receive this error message.

KEY `page_name` (`page_name`) ) ENGINE=MyISAM DE' at line 13
 * 1) 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'KEY `template` (`template`),
 * working on a new release to fix this. In the meantime, here is a dump of the structure of those tables from EcoliWiki, where it's running live - note that this is already slightly changed from the 0.8 release; but it should be compatible and will prepare you for the 0.81 release:

-- phpMyAdmin SQL Dump -- version 2.10.2 -- http://www.phpmyadmin.net -- -- Host: trimer.local:3306 -- Generation Time: Jul 30, 2008 at 05:14 PM -- Server version: 5.0.41 -- PHP Version: 5.2.4

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

-- -- Database: `colipedia` --

--

-- -- Table structure for table `ext_TableEdit_box` --

DROP TABLE IF EXISTS `ext_TableEdit_box`; CREATE TABLE IF NOT EXISTS `ext_TableEdit_box` ( `box_id` int(10) unsigned NOT NULL auto_increment,  `template` varchar(255) NOT NULL,  `page_name` varchar(255) NOT NULL,  `page_uid` varchar(255) NOT NULL,  `box_uid` varchar(255) NOT NULL,  `type` varchar(255) NOT NULL,  `headings` varchar(255) NOT NULL,  `heading_style` varchar(255) NOT NULL,  `box_style` varchar(255) NOT NULL,  `timestamp` int(11) NOT NULL,  PRIMARY KEY  (`box_id`),  KEY `template` (`template`),  KEY `page_name` (`page_name`),  KEY `page_uid` (`page_uid`),  KEY `box_uid` (`box_uid`) ) ENGINE=MyISAM  DEFAULT CHARSET=latin1;

--

-- -- Table structure for table `ext_TableEdit_box_metadata` --

DROP TABLE IF EXISTS `ext_TableEdit_box_metadata`; CREATE TABLE IF NOT EXISTS `ext_TableEdit_box_metadata` ( `box_metadata_id` int(10) unsigned NOT NULL auto_increment,  `box_id` int(10) unsigned NOT NULL default '0',  `box_metadata` varchar(255) NOT NULL default '',  `timestamp` int(10) NOT NULL,  PRIMARY KEY  (`box_metadata_id`),  KEY `box_id` (`box_id`) ) ENGINE=MyISAM  DEFAULT CHARSET=latin1;

--

-- -- Table structure for table `ext_TableEdit_row` --

DROP TABLE IF EXISTS `ext_TableEdit_row`; CREATE TABLE IF NOT EXISTS `ext_TableEdit_row` ( `row_id` int(10) unsigned NOT NULL auto_increment,  `box_id` int(10) unsigned NOT NULL,  `owner_uid` int(10) default NULL,  `row_data` text NOT NULL,  `row_style` varchar(255) NOT NULL,  `row_sort_order` int(11) NOT NULL,  `timestamp` int(10) unsigned NOT NULL,  PRIMARY KEY  (`row_id`),  KEY `box_id` (`box_id`) ) ENGINE=MyISAM  DEFAULT CHARSET=latin1;

--

-- -- Table structure for table `ext_TableEdit_row_metadata` --

DROP TABLE IF EXISTS `ext_TableEdit_row_metadata`; CREATE TABLE IF NOT EXISTS `ext_TableEdit_row_metadata` ( `row_metadata_id` int(10) unsigned NOT NULL auto_increment,  `row_id` int(10) unsigned NOT NULL default '0',  `row_metadata` varchar(255) NOT NULL default '',  `timestamp` int(10) NOT NULL,  PRIMARY KEY  (`row_metadata_id`),  KEY `row_id` (`row_id`),  KEY `row_metadata` (`row_metadata`) ) ENGINE=MyISAM  DEFAULT CHARSET=latin1;
 * hope this helps --JimHu 22:18, 30 July 2008 (UTC)


 * It really does help, thanks you very much.


 * Thank you, but how does one then install it properly if one is receiving this error? Do I copy the above text into the "TableEdit_table.sql" file and rerun the update php file.

Work with Extension:ParserFunctions?
What is the data structure? Is all the data store somewhere else within database? Can we retrive it on another page? On the other hand, can we do some calculation with those data?

For example:

I think Extension:WikiDB is an great idea but it's still very primitive.

Fix "Printable Version" page
I had a problem with the default skin of MediaWiki and TableEdit, when useing "Printable Version". In all of my tables the first column got way too wide, because MediaWiki displays "Edit Tanle" button with it's full URL.

I came up with a workaround: tr.sortbottom { font-size: 0px; display: none; }
 * 1) Edit file /path/to/mediawiki-root-dir/skins/common/commonPrint.css
 * 2) Add following to the end of file:

Done - the "Printable Version" page should now display without the "Edit Table" row at all. If you happen to wonder, "font-size: 0px;" is there to do the trick with some older browsers, in 99% of cases "display: none;" is all that is needed. Wyrmiyu 21:10, 14 October 2008 (UTC)

TableEdit stopped working
I had to migrate our wiki due to a server crash. Everything in the mediawiki seems fine except for the TableEdit. It won't allow me to create a new table nor edit an old table.

werd

Sending variables to the template?
Is it possible to send variables to the template in a similar way you do with a 'normal' template? eg. I'd like to be able to do something like this:   or this Template:Gene_data|gene=FABP3 or      </newTableEdit>

</tt>

thanx, Russell Smithies

Newest version
On http://ecoliwiki.net/ the version listed is 0.99 but the version publicly available is 0.8. Is 0.99 available somewhere?

First-time Installation problem with REL-0.99
update_schema.php expects the five SQL files for the table structure to have the .sql extension, but in the version of the package linked in this page ( trimer.tamu.edu/jh/TableEdit-v0.99.tar.gz ), the files in the sql directory do not have that suffix. DEinspanjer 19:37, 25 August 2009 (UTC)

Same here, .sql extensions missing --sandb 01:31, 15 October 2009

Other than the .sql extenstions missing from the filenames, the sql commands also fail to take into account databases with prefixes in their tables. table prefixes also needs to be added to SpecialTableEdit.body.php sql table calls. -- 218.186.13.227 08:38, 19 October 2009 (UTC)

Support for newer MediaWiki versions
The file INSTALL talks about AdminSettings.php, which disappeared in recent MediaWiki versions.

Is it possible to use TableEdit with MediaWiki versions 1.13 and newer? If so, is this documented anywhere?

(Note: prev. person didn't sign anything.)

It should be possible by editing the update_schema.php file:

if (is_file("$wikipath/AdminSettings.php")) {

require_once ("$wikipath/AdminSettings.php");

} elseif (is_file("$wikipath/LocalSettings.php")) {

require_once ("$wikipath/LocalSettings.php");

} else { die("Can't find AdminSettings.php in $wikipath\n");

}

That will go in order to check Admin*, then Local*. Now, I haven't been able to do this yet, due to an libldab.so.2 error, buuut I don't see why it wouldn't work. XtinaS 04:24, 18 January 2010 (UTC)

TableEdit-v2.0 coming...
I've been working with TableEdit a lot at work (EcoliWiki.net) and have produced a refined version. This project/extension was never meant to handle all the things we've added to it over the years, and I felt a major rewrite was in order. I have read all the above problems/concerns/fixes and am trying to address each this time. Check back later, and be glad...I'm writing documentation!!!

--Bluecurio 02:02, 25 March 2010 (UTC)