Extension talk:Cargo

Recreation doesn't work
Hi Yaron,

first of all a Happy New Year and all the best for you in 2017.

I have a big problem with Cargo recreation. I doesn't work on any way: wether the recreation button nor the call of runJobs.php nor the call of cargoRecreateData.php has any result on any table.

I use
 * MediaWiki 1.23.9
 * PHP 5.5.9-1ubuntu4.19 (cgi-fcgi)
 * MySQL 5.5.44-0ubuntu0.14.04.1

and some other extensions.
 * Semantic MediaWiki 2.2.1 => $smwgEnabledCompatibilityMode = true;
 * Semantic Forms 3.6
 * Cargo 1.2

Changes to the tables work, I proofed with phpAdmin. But i have to save any page containing a #cargo_store manually to fill up the table after recreation; purge doesn't work, too.

No SQL errors, no exceptions.

Here the result of cargoRecreateData.php: Recreating data for Cargo table Beispiel in 5 seconds... hit [Ctrl]-C to escape. Deleting and recreating table... Handling template that adds to this table: Cargo Beispiel Saving data for pages 1 to 0 that call this template... => There is one Page using cargo_store => the counter counts "... pages 1 to 0 ..."

Recreating data for Cargo table Test in 5 seconds... hit [Ctrl]-C to escape. Deleting and recreating table... Handling template that adds to this table: TestCargo Saving data for pages 1 to 0 that call this template... => There are two pages using cargo_store => the counter counts "... pages 1 to 0 ..."

So, what can i do?
 * Addition
 * same problem on an other server
 * the table "cargo_pages" is empty after recreation


 * Could you include here, or link to, the text of any of the relevant template pages? Yaron Koren (talk) 00:21, 2 January 2017 (UTC)
 * Here a small one; the admin has all rights on MySQL except 'grant'


 * and a bigger one; at this one the #cargo_store is used in another template.

--2003:72:2F23:8E00:8A1:CA60:AACD:E382 Klaus from Dresden

Q2: Only if i change or add fields and save the template Q3: Web interface doesn't work anyway. Today i installed a MW 1.27.1 (virgin with no extensions except Cargo) => recreation with phpRecreateData.php works, web interface not. Then i installed a MW 1.23.9 (virgin with no extensions except Cargo) => recreation with phpRecreateData.php works, web interface not. After that i used an existing MW 1.23.9 with Cargo and other extensions, rebuilding the template (now with #cargo_store in the template with #cargo_declare inside), resaving data content pages => recreation with phpRecreateData.php works, web interface not. Using this Wiki again, rebuilding the template (now with #cargo_store outside of the template with #cargo_declare ), resaving data content pages => recreation with phpRecreateData.php doesn't work, web interface too. => seems that the #cargo_store has to be in the same template as #cargo_declare. --2003:72:2F2D:1400:CCDE:82FC:7AD7:2085 Klaus from Dresden Joomla: no, i only host wikis on this server seems that cargoRecreateData.php doesn't work in cases with templates with #cargo_store without #cargo_declare or #cargo_attach => solved; Using web interface to recreate i get the information, that the datas were recreated and a link to view the table. When i follow the link, i get an empty table and see only the fieldnames. last but not least: Yaron, you are always ready to help and make so useful tools for MW - what can I do for You? --2003:72:2F2D:1400:CCDE:82FC:7AD7:2085 Klaus from Dresden
 * I couldn't replicate this problem, with that first template - it worked fine for me. Just to be clear - if you save a page calling that template, the Cargo data is stored correctly? But then if you call cargoRecreateData.php, the data disappears again? And what happens if you recreate the data from within the web interface? Yaron Koren (talk) 04:38, 3 January 2017 (UTC)
 * Q1: Yes, storing works fine.
 * Well, this sounds like it might be three different problems. For the last one - if a template calls #cargo_store but not #cargo_declare, it needs to also call #cargo_attach - that could be the issue. For the web interface not working - do you have Joomla running on that server? (See here.) Otherwise: what do you see when you press the "Recreate" button? And for the original issue: under what circumstances does cargoRecreateData.php not work for you, do you know? It sounds like it now works for you in most cases. Yaron Koren (talk) 14:32, 3 January 2017 (UTC)
 * Thanks, so i will put #cargo_attach into templates without #cargo_declare
 * Okay, now we're making some progress. It could be that the web-based recreate is actually working - it re-populates the table via MediaWiki jobs, so it could be that those jobs are still just waiting in the job queue and haven't run yet. Is that possible? As for helping me - that's nice of you. If you represent a company that uses this software and could potentially offer some funding, it would be great to talk about it; otherwise - just keep reporting problems as you encounter them. And of course, feel free to spread the word! Yaron Koren (talk) 18:06, 3 January 2017 (UTC)
 * Sorry, i had a heavy workload the last days. With #cargo_declare and #cargo_attach inside runJobs.php works fine. So, the project i need Cargo for, is unfortunately a non-commercial for the Dresden Museum of Technik. --2003:72:E00:3400:C492:1FB9:2508:F5C Klaus from Dresden
 * That's great to hear. And that's also cool to hear that the software is being used at that museum - I wouldn't have known otherwise. Yaron Koren (talk)

Duplicate entries
Hello Yaron,

Happy New Year 2017 :)

I have been trying out this extension, which I like very much - thanks for creating it, I am grateful :)

However, I'm having a big issue with it. I've been testing on a clean install of Mediawiki. The issue is as follows: when an item is created/edited (using Page Forms), it usually ends up duplicated. This results in hard-to-read query output, since everything is duplicated. As a temporary fix, I've been forced to create a cron job that recreates the tables once a day. For now there is only one table and around 20 items, but I shudder to think what it will be like once the wiki gets big.

Searching through this discussion page, I came across another entry describing such a behavior. But in the other post, it seemed to only happen sometimes. In my case, it happens on almost every single creation or update of an item.

I tried to compare my template to the one on semantic discourse DB, to see if there might be some issue. I wasn’t able to identify any meaningful difference.

The setup: MediaWiki        1.28.0 PHP      7.0.8-0ubuntu0.16.04.3 (apache2handler) MySQL 5.7.16-0ubuntu0.16.04.1 ICU       55.1 Page Forms       4.0.2 Cargo   1.2 MagicNoCache 1.3.1 ParserFunctions             1.6.0 And some other extensions

Best, Michel

Update
In order to eliminate the possibility that this might be due to a mistake in the template or form page syntax, I used Page Forms to create a new template and form for a super-simple, single-field cargo table. The problem is still there.

The template and form (in case useful)
Template: This is the "DaysTodos" template. It should be called in the following format: &lt;pre>

&lt;/pre> Edit the page to see the template text.

Form: This is the "DaysTodos" form. To create a page with this form, enter the page name below; if a page with that name already exists, you will be sent to a form to edit that page.



Free text:


 * That's not good. Do you have the VisualEditor extension installed? It has been known to cause this kind of problem. (That needs to be fixed.) If not, what other extensions are installed? Yaron Koren (talk) 14:40, 6 January 2017 (UTC)


 * I don't have VisualEditor. Here is the list of all the extensions I have: nuke, page forms, cargo, renameuser, cite, inputbox, magicnocache, parserfunctions, PDF handler, SpamBlacklist, Gadgets, Wikieditor. BTW I've noticed an issue with Page Forms: the createclass sheets only creates the category, not the template or form. (I've checked the output of runJobs.php to make sure.) Who knows, maybe the two are related? Could it be due to php7?

Michel


 * I don't know, then... those are all pretty standard extensions. I'm guessing that your two issues are related, especially since both involve the job queue. I doubt it has to do with the PHP version, but I could be wrong. Do you have any settings relating to the running of jobs, like a high or low job run rate? If not, I would try temporarily disabling all the extensions except for Cargo and Page Forms, and see if those two problems are still there when you do that. Yaron Koren (talk) 14:14, 9 January 2017 (UTC)


 * Sorry for the late response, I was (and still am) on a roadshow, and arriving back to the hotels exhausted each evening very late. I'll try that as soon as I get back. Michel (PS I left the job run rate at the default, though I'm planning to increase it at some point.)

Installation with Composer?
Are there plans to permit installation via Composer? It works well for SMW. Sam Wilson 16:42, 10 January 2017 (UTC)


 * Cargo already has a composer.json file, so I believe this is already possible - I don't know what the exact line(s) that need to be added are, though (I know very little about Composer). Whatever it is, it should probably be added to the documentation. Yaron Koren (talk) 18:21, 10 January 2017 (UTC)


 * No, the existing composer.json file is missing a few keys (mainly `name` but if you run `composer validate` it'll say more). Also, you'd need to register it on Packagist (which is pretty straight forward). Is this something you'd be willing do support? I could submit a patch if you like. My main reason for wanting it is for ease of upgrading. —Sam Wilson 19:13, 10 January 2017 (UTC)


 * Ah, okay. Sure - I'm definitely happy to approve a patch, or whatever else is required. Yaron Koren (talk) 20:07, 10 January 2017 (UTC)