Hello, I am Petr Bena also known as Petrb (my SUL). I am a volunteer developer working on multiple projects, including Huggle, wm-bot and many others
I also commented out your call to Render() which I am not sure what would do, that function is used to render / display a WikiEdit in Huggle, it also refreshes all toolbars and so on, I think it could do something unwanted in case that CurrentEdit is not a null pointer (which it probably was when you tested this), if you know what you are doing, feel free to revert that
I merged it but you might also want to add this to preferences form, so that user doesn't need to hack their own config page and can change this easily. I also think there should be information that this page can be modified in HG preferences on the default version.
Does it happen every time you login to hrwiki?
Thu, May 25
what someone doesn't like my cat D:
Tue, May 23
It probably is related to talk page buffer which contains the source code of the page, it should be flushed but it's not for some reason
Mon, May 22
Sun, May 21
Sat, May 20
I am not sure though how would it look on wiki, we might check if page starts with <code> tag and trim it, so that config files look awesome on wiki as well, so the config pages would not be pure yaml, but yaml wrapped in wiki code, that we would unwrap before actually parsing it: https://test.wikipedia.org/wiki/Wikipedia:Huggle/Config.yml
Fri, May 19
It's happening in parallel, I can try doing it in serial though.
Yay just 2 years to fix this!
I think it works already, I can't reproduce this
So, I dropped botbot I don't really think there was anyone using it
Dumping anything to a channel doesn't sound like a best idea to me :( there are very strict limits set by freenode which require bot to send max 1 message per second. Given that it's already in almost 400 channels, it makes it really big problem for mq to stay low.
In case there is some ORES feature that needs to be implemented, please give me specs, either reopen this or make a new task, thanks!
I am just wondering, can we close this task? Huggle /does/ support ORES for long time, if there is a specific feature of ORES that isn't implemented in Huggle, then that would need to be specified in task description, right now I have absolutely no idea what to fix.
@Josve05a are you still having this problem, even with last beta: https://petr.insw.cz/huggle/huggle_3.2.0_beta2.exe
Fixed by @Isarra
Mon, May 15
this is example dump: http://petr.insw.cz/tmp/huggle.htm
Fri, May 12
at some point we might eventually rethink whole configuration file schema, maybe we could simply make whole another config format that would be based on some open formats, like YAML
Thu, May 11
@Framawiki probably because your wiki requires it in Huggle config, check if require-config on your wiki
Mon, May 8
try to update the config and let me know about the result!
You can get latest builds of huggle here: https://petr.insw.cz/huggle/
Tue, May 2
There is a syntax error in warning-template-tags: it needs to contains a dictionary of items if this format:
Mon, May 1
testing on production sites of anything is never welcome, you can run huggle in a dry mode if you need to test stuff (start huggle in debug mode, then help -> debug -> dry).
Sat, Apr 29
btw running telnet to bot and executing "send PRIVMSG chanserv: whatever command you wanted to execute" would probably work in this case
Apr 21 2017
Also right now there are filters for both "IP" and "Registered" which is redundant I think
Yes there seem to be some skeleton in the class itself, but the actual code that would make it work is missing
I don't remember, but it's possible, however I fairly sure the configuration wasn't finished otherwise this task wouldn't be still open. I think that warning templates and commons specific configuration is missing.
Apr 12 2017
Declining a task doesn't solve it.
Apr 9 2017
Apr 4 2017
it works to me: https://en.wikipedia.org/wiki/Special:Contributions/Petrb
This commit caused it https://github.com/huggle/huggle3-qt-lx/commit/ebecb24fa4bc8974a0b5c3cdfd5aa4d8cb8382ed
The problem is caused by possible change in revert logic in mainwindow.cpp (I don't know which commit caused this though) it seems that now for some reason we jump to next edit right after call to Revert() and subsequent WarnUser call work with this->CurrentEdit, which in that moment points to next edit in queue (or nullptr in case there is no more).
To reproduce you can revert and warn anything, huggle obviously use next edit as dependency for rollback
It might be also useful if someone could try to identify all users who use this version of huggle (3.2.0) either by scanning the edit summaries or huggle3.css and then notify these users about this issue
Is there any simple step to reproduce this?
Mentioned commit id is irrelevant though could be anywhere from 3.1.21
Mar 31 2017
Huggle was configured for wikispecies, but I set it to be read only until warning templates for it are created
2e596042ad27 adds this
I removed this string from localization now