| 30 Mar 2024 |
 revansx | I'm not sure what I did to fix it but it works now | 18:37:54 |
| revansx | Thank you both | 18:39:49 |
| 3 Apr 2024 |
 Jonathan Lee | Hi folks - I'm investigating an issue where creating a large number of redirects quickly on a wiki using SMW can cause the webserver to get overwhelmed with parses of the target page. After some investigation, I think the it's because any time a redirect gets created, it triggers a "ChangeTitleUpdate" deferred job, which does a full parse of the target page | 03:30:35 |
| Jonathan Lee | Does anyone know what the purpose of this job is? I am having a hard time understanding why the creation of a redirect would require a re-parse of the target page | 03:31:30 |
| Jonathan Lee | If it's indeed necessary, I wonder if it would be better to move it to the job queue, rather than a deferred update. Since it's deferred (but still on the main webserver), it's quite easy for someone bot-creating a bunch of redirects to subtly DOS the server with all the re-parses, since their api.php edit requests won't wait for the parse to finish | 03:33:24 |
| Jonathan Lee | digging a bit more, it seems to be related to https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/895 | 04:06:44 |
| Jonathan Lee | but I still don't understand why this requires a re-parse of the target page | 04:06:54 |
| 4 Apr 2024 |
 Bertrand Gorge | Hello, I just logged what seems to be a regression in SMW 4.1.3 - it seems linked to ElasticStore. I am available with a debugging environment if someone with knowledge of the SMW code wants to dig this out...! https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/5618 | 07:55:52 |
| 10 Apr 2024 |
|  Heric Dreri joined the room. | 09:06:51 |
| 17 Apr 2024 |
| revansx | Bernhard Krabina, Great MWCon presentation, Bernhard! Thank you! | 19:33:54 |
| 23 Apr 2024 |
| revansx | We are testing a new MW 1.39 wiki server running SMW 4.1.3 and have encountered a strange behavior; namely, that "null edits" (editing a page source by adding a white space at the end and hitting save) no longer forces the SMW properties to update as it does on our existing production MW 1.34 server running SMW 3.2.3. Does anyone confirm this new (to us) behavior between SMW 3.2.3 and SMW 4.1.3? Thanks! | 20:07:45 |
 justinl | I can try to test ours. | 20:08:50 |
| revansx | In reply to @justinl:matrix.org
I can try to test ours. Thank you! | 20:10:43 |
 Bernhard Krabina | I did not notice differences. Null edits don't need inserting spaces btw. They should ttigger jobs and if your job queue is working, everything is fine. | 21:21:04 |
| revansx | ok. we'll look for the jobs. We're done testing for the day. I'll follow-up tomorrow. Thank you! | 21:26:30 |
| justinl | I'm still waiting a response from asking our editors to test this on our wikis. | 21:27:13 |
| 24 Apr 2024 |
|  @eisenvig:matrix.org left the room. | 00:51:53 |
| Bertrand Gorge | I can confirm that it still works on ours, I did it yesterday... | 07:34:38 |
| revansx | In reply to @bertrandgorge:matrix.org
I can confirm that it still works on ours, I did it yesterday... Thanks! Hopefully it's just a configuration issue then . | 09:39:22 |
| Bertrand Gorge | I'd rather look for a glitch in the DB and run some maintenance scripts... | 11:43:50 |
| 25 Apr 2024 |
|  @sergiomassa:sibnsk.net removed their profile picture. | 22:04:15 |
| @sergiomassa:sibnsk.net left the room. | 22:39:46 |
| 26 Apr 2024 |
| Bernhard Krabina | Next Friday the Wikimedia Hackathon will start. You will be able to participate remotely if you can devote some time next Friday-Sunday for SMW related tasks:
https://www.semantic-mediawiki.org/wiki/Wikimedia_Hackathon_2024 | 14:24:13 |
| revansx | Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms Class (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form the sets multiple form fields (like Has Bar and Has Zaz) with the "|value from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Form itself. I think this has to do with the added processing that PF adds to the parser process. | 16:13:32 |
| revansx | * Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms "Class" (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form the sets multiple form fields (like Has Bar and Has Zaz) with the "|value from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Form itself. I think this has to do with the added processing that PF adds to the parser process. | 16:14:03 |
| revansx | * Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms "Class" (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form the sets multiple form fields (like Has Bar and Has Zaz) with the "|value from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Forms itself. I think this has to do with the added processing that PF adds to the parser process. | 16:14:16 |
| revansx | * Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms "Class" (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form the sets multiple form fields (like Has Bar and Has Zaz) with the "|value from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Forms itself. I think this just has to do with the ability of using PF to add the additional processing complexity to the parser process that SMW needs to expose the issue. | 16:15:12 |
| revansx | * Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms "Class" (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form that sets multiple form fields (like Has Bar and Has Zaz) with the "|value from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Forms itself. I think this just has to do with the ability of using PF to add the additional processing complexity to the parser process that SMW needs to expose the issue. | 16:53:20 |
| revansx | * Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms "Class" (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form that sets multiple form fields (like Has Bar and Has Zaz) with the "|values from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Forms itself. I think this just has to do with the ability of using PF to add the additional processing complexity to the parser process that SMW needs to expose the issue. | 16:53:34 |
| revansx | * Not sure where to document this, but we've discovered that we can reliably produce the infamous "SMW dropped properties bug" by making the page a member of a Page Forms "Class" (i.e. Category:Foo, Form:Foo, Template:Foo, and Property:Has Bar and Property:Has Zaz) and designing it to use a form that sets multiple form fields (like Has Bar and Has Zaz) with the "|values from category=Foo|" where Category:Foo has many (> 1000) pages. Once this is the case, all pages in the class Foo will reliably drop all SMW categories upon PF #autoedit from another page.
Note - I don't think this has anything to do with Page Forms itself. I think this just has to do with the utility of using PF as a means of adding the additional processing complexity to the parser process that SMW needs to expose the issue. | 16:54:27 |
