I just checked in a change to the Semantic Drilldown that may fix this problem. If you can, please get the latest code and try it out.
Thu, Dec 13
Fri, Dec 7
Wed, Dec 5
Tue, Dec 4
Mon, Dec 3
I guess I could release a new version of Page Forms at any time.... should I?
Fri, Nov 30
@Arlolra - thanks, those links to the code look quite helpful. It could be that getting agreement that the change should be made will be much harder than actually making the change...
Thu, Nov 29
Hi - I may have access to developer resources to fix this bug, including possibly trying to create a fix myself. Is there anyone I can talk to about this? Is there at least a consensus that the current behavior should be changed?
Wed, Nov 28
By the way, a dropdown or autocompletion for the timezone input makes sense... it just seems like there are too many values to be able to get them all into the code. Or maybe I just don't want to do the work. :)
Sorry about that. This was a pretty recent bug... I just checked in what I think is a fix for it.
Good point - I just checked in a change for this, so now it only applies to content namespaces.
I suppose... I don't know what the statute of limitations is for IE bugs.
Tue, Nov 27
Wed, Nov 21
Thanks for the patch, and sorry for the delay!
@Kfield - what do you mean by that? What should change to use OOUI?
Mon, Nov 19
"Invalid" is probably the right status.
Thanks for the interesting suggestions. At the very least, warning the user that certain pages are going to be overwritten is probably a good idea.
Great! By the way, you can specify the property for a form field directly by adding the "property=" parameter to the field's tag in the form definition.
Well, I can't see your setup, unfortunately, but I haven't heard about this problem from anyone else, so my strong guess is that there's something wrong in your setup. If you want to try debugging it yourself, the relevant line is "$fsURL = $fs->getPageTitle()->getLocalURL();" in /includes/PF_ParserFunctions.php.
Nov 16 2018
You did indeed find a bug - I don't think many people are going directly to Special:FormStart, which is probably why no one has reported it until now. I just checked in what I think is a fix.
Is this a new wiki? It sounds like you have an error in the wiki's URL-creation setup - perhaps an error in setting the variable $wgArticlePath in LocalSettings.php, or a problem in any URL-rewriting code you may have.
Yes, Special:CreateClass overwrites everything. What do you think the logic should be - overwrite forms, templates and categories, but not properties?
That 2nd part, in the "Update", doesn't sound like a forms issue - you're seeing a problem in a page that calls a template, with no form involved. It sounds like there's an error in the property name(s) in the template. My guess is that that's what is causing the form problems as well - because there's an error in the template, the form can't figure out what values to use for the dropdown inputs.
Nov 15 2018
What's the problem with this? I mean, why not just create the missing table?
Nov 12 2018
Sorry for the very long delay. I just checked in what I think is a fix. I believe this was only ever an issue for the "text with autocomplete" input type (as opposed to "tokens"), which might explain why I never saw this problem myself. Feel free to re-open if this hasn't actually been fixed.
Nov 8 2018
Nov 7 2018
Thanks for letting me know about that - I just checked in a fix for all of of these.