If I disable the issue tracker on my project, will all of the existing tickets be deleted, or will they become viewable again if I later re-enable the issue tracker?
Without going into detail, I'll just say I feel the new issue tracker is a downgrade from the old (already not very good) one in nearly every regard, and I want to try using an external solution instead. However, if it turns out users really really hate it, I might re-enable the Curse issue tracker at a later date, and it would be nice if that didn't mean re-copying all the tickets again.
For now I'm going to try GitLab; their issue tracker isn't as nice as GitHub's, but they do have the option to sign in with an existing Google, Facebook, Twitter, or GitHub account, so users won't need to register on yet another website just to submit a bug, which I feel is very important.
I just deleted several issue tags on Grid ("Defect" because I added a better-named "Bug" tag to use instead, "Enhancment" because it's embarrassingly mis-spelled, "New" because it's useless, etc.) but even after confirming their deletion and clicking Save at the bottom of the page, those tags are still displayed on issues:
The first five tickets are tagged Defect / Enhancment / Defect / New, Defect / Defect, Started. The only one of those tags that should still exist is "Started".
It's not a browser caching issue; I still see the tags when refreshing with Shift-F5, and when I open that page in another browser that's never visited it before.
When I click "Edit" above a ticket on one of my projects, make changes, and click Submit, any changes I made to the actual content of the ticket are not saved. Other changes (closing, adding tags, adding a comment) are saved correctly.
Typically when someone submits a ticket with an error message, I prefer to edit the ticket to format the error message as a code block and remove the list of installed addons so I don't have to scroll through 5 screens of irrelevant crap every time I look at the ticket.
Thats not how file handling works, however. To modify and/or delete lines in a file, you need to read at least everything after those lines and re-write it, for sake of sanity everyone would just read the entire file (instead of half of it), modify it in memory, and write it out again.
I wasn't talking about the implementation details --- those are irrelevant and I don't care in the slightest what happens between "reading" and "rewriting" --- but about the end results. There's no good reason why the file that eventually gets distributed should have any differences from the originally uploaded version of the same file that aren't the direct result of text being added, removed, or commented based on packager tags.
It doesn't really matter why the Curse system was implemented the way it was, who implemented it, what they were thinking about when they implemented it, whether or not it was tested, etc. --- at the end of the day, it's still a problem that needs to be fixed.
The old packager was able to make insertions/changes to files without mangling the encoding or making other unrelated changes to the file contents, so if Curse is having trouble figuring out how to do that, they should just look at their own older code.
Related to this, it would be nice if the notification emails had useful titles. Under the old system, I'd get emails with titles like "New comment on Grid" or "Comment on ticket for PhanxChat", but now every email is just titled "What's happening at CurseForge".
Files should only be edited when you, the author, uses some of our advanced features like localizations or replacement tags and only those files should be touched.
Building on that, rather than trying to guess when you should modify our manually uploaded files, you should just add a setting for the project that we can turn off. I do use the Curse localization system, but I don't use the Curse packager. The ZIP files I upload already have the localization data inserted, so there's no need for the Curse packager to do anything.
Furthermore, there's not really any excuse for making modifications (like changing line endings or making Unicode replacements) to existing code. If there's an "insert localization here" tag in a file, just insert the localization in place of the tag. If there's a block of code wrapped in "debug/end-debug" tags, just replace each tag with the appropriate symbols to start and end a block comment. If there's a "do-not-package" tag block, just delete the lines in between. No reason to touch any other lines in the file.
Markdown defines `backticks` as producing a <code> tag, which the HTML spec defines as an inline element (flow/phrasing content).
However, your CSS is redefining <code> as a block element, causing my inline code snippets (such as slash commands) to be displayed in a big black box that breaks the text flow (and looks totally out of place with the otherwise snow-white site theme).
This is wrong. This block styling should be applied only to <code> tags inside a <pre> tag, which is the output from a Markdown code block (text indented with 4 spaces or 1 tab, or fenced by ``` [three backticks] lines if your parser supports those) -- not backticks.
I didn't bother mentioning the obnoxious blinding white and small fonts again because I already wrote my own CSS to make the site usable.
After years of posting the same complaints and suggestions and explanations, and seeing every iteration of the site just make things worse and worse and worse, it's pretty obvious that Curse doesn't give a damn about even the most basic accessibility concerns and isn't going to change anything in this regard. If they do actually offer a dark theme in the future, it will undoubtedly be just as unusable, with tiny fonts and low contrast.
Your forum WYSIWYG editor is still horrible. Easily the worst web-based WYSIWYG editor I've ever had the misfortune to be subjected to.
The UI design is terrible, for one; it looks like the bastardized love-child of Windows 3.1 and an early 2000s cell phone UI. I could overlook that if it actually worked, but it doesn't.
Copying and pasting with Ctrl+C (or Ctrl+X) and Ctrl+V don't work in Firefox; I have no idea why you would think it's a good idea to intercept system-wide hotkeys in the first place, but whatever your copy/paste event handlers are supposed to be doing (I didn't bother looking), they're not doing it correctly. Ctrl+X removes the selected text, but doesn't copy it into the clipboard. Ctrl+C and Ctrl+V do nothing at all.
Basic typing and formatting are also unreliable. Pressing the "Enter" key on my keyboard sometimes inserts two linebreaks instead of one. Selecting text and clicking the "bold" button, for example, might bold the selected text... or it might just move the cursor to the end of the entered text and not bold anything.
When pasting text (by right-clicking and then clicking Paste in the context menu, since Ctrl+V doesn't work) from unformatted sources (eg. Notepad), actual linebreaks in the text are doubled (probably CRLF is being incorrectly treated as two linebreaks) and sometimes additional linebreaks are inserted in the middle of lines for no reason (there's definitely not any break-related character in the text there). When pasting text from formatted sources (eg. select all the entered text, copy from the context menu, then paste it back into the same place) the formatting also gets mangled -- again with the random linebreaks, and sometimes things are bolded or turned into headers for no apparent reason.
Similarly, when copying (again, using the context menu) from the forum input area into Notepad, linebreaks get doubled again. CRLF is not a hard problem to solve, guys!
Please just get rid of this monstrosity and use a standard textarea with Markdown or BBCode formatting support. Anyone posting on a forum dedicated to online gaming knows how to use one or both of these formatting systems, and you can even still have UI buttons to insert the appropriate formatting codes/symbols for the people who don't.
Alternatively, get a WYSIWYG editor that isn't terrible -- I can't offhand remember ever using one that I didn't find annoying, but there's got to be something better than this -- or just add an option to disable WYSIWYG editing per-user. As it stands I doubt I will be using the new forums very often. I even enabled commenting on Grid, though I hate comment pages as a communication medium in general, because that's still better than using these forums. :(
Such an addon isn't possible. You can only check for the availability of names on your current server, eg. by trying to add the name to your non-Battle.net friends list. Just type "/friend Thenameyouwant". If it says "Player not found" then the name is available.
While it would be possible to write an addon that automatically did the above to notify you if/when the name ever became available on your server, it doesn't really seem worth writing or using, since the odds of someone renaming/moving/deleting the character with the name you want are so low.
If you want to check other servers, you have to create a character and log into them.
You can also search for the character name on the WoW site, but if it doesn't show up in the results, that's not a guarantee it's available, since low-level characters and characters that haven't logged into the game in a long time aren't shown on there.
Yes, but remember that order matters. What you posted will work if Battlegrounds.lua is loaded first, but will throw an error if BGCallouts.lua is loaded first.
1. If you just want to use the table as a place to store things, you do not need a metatable. The metatable for localization just means you don't have to write in all the default values for the default language by hand. There are other uses for metatables, but based on what I've seen in this thread, you do not need one here.
2. You can't create a new namespace. Your addon gets one namespace, which is really just a table that's private to your addon's files. If you're currently using it exclusively for your localization (I don't have time to download look at your code right now) then just change it to store the localization as a sub-table instead:
Change this:
local ADDON_NAME, L = ...
setmetatable(L, <localization thingy here>)
L["Something"] = "Bla bla bla"
local ADDON_NAME, L = ...
someFontString:SetText(L["Something"])
To this:
local ADDON_NAME, private_table = ...
local L = setmetatable({}, <localization thingy here>)
private_table.L = L
L["Something"] = "Bla bla bla"
local ADDON_NAME, private_table = ...
local L = private_table.L
someFontString:SetText(L["Something"])
Now you can store whatever you want in "private_table" -- that's your addon's namespace.
3. Yes. Use an indexed table rather than key/value pairs:
-- Table only has values:
local t = {
"something",
"something else",
"another thing"
}
-- Print the values in order:
for i = 1, #t do
local v = t[i]
print(v)
end
vs
-- Table has keys and values:
local t = {
["something"] = "hi",
["something else"] = "yes",
["another thing"] = "no",
}
-- You can only print them in "undefined" order:
for k, v in pairs(t) do
print(k, v)
end
In reality, the indexed table does have keys; it's the same as this:
local t = {
[1] = "something",
[2] = "something else",
[3] = "another thing"
}
...but you don't actually have to write the keys. You can still refer to the values as t[2] no matter how you constructed it.
... so they're still in order, but you can store multiple values in each top-level value. You'd access "no" in the above example as t[3][2].
The subtables can use key/value pairs:
local t = {
{
name = "something",
value = "hi"
},
{
name = "something else",
value = "yes"
},
{
name = "another thing",
value = "no"
}
}
for i = 1, #t do
local v = t[i]
print(v.name, v.value)
end
Here's an example of having the core files at top-level and moving "plugin" folders with the packager, that works both as-is (for you during development) and after packaging (for users):
The TOC and .pkgmeta files will be of most interest; the "Config" folder gets moved to "oUF_Phanx_Config" up at the same level as the main "oUF_Phanx" folder. In an un-packaged copy (eg. your working copy) the Config/* files get loaded from the main addon's TOC, wrapped in @do-not-package@ keywords so the packager removes those lines.
Just a thought, "L" isn't the best choice for such a table name. Anyone else looking at that code is going to assume "L" is the name of a table containing the localized strings for your addon, since that's what 99% of existing addons do.
Please use [ code ] tags around code blocks. I edited your posts to add them. Without these tags, your code loses all indentation, and gets emoticons inserted in the middle of it, making it basically unreadable.
As for the question, you have the right idea, but please don't use things like "ab" as a global frame name. If there's ever a problem with your addon, or someone is just curious, nobody will be able to figure out what "ab" or "tbfg" means in a /framestack tooltip or an error message.
All global variables -- including frame names -- should follow two rules:
1. They should clearly identify the addon that created them ("ab" offers no clues) and ideally clearly identify what purpose they serve within that addon ("ab" is only helpful once you figure out which addon it belongs to).
2. They should be unique, so there's no chance of colliding with global variables from other addons or the default UI ("ab" is really generic, so there's a high probability of collision).
An easy way to satisfy both rules is to prepend your addon's name to a meaningful name, eg. "MyAddon_ArathiBasinFrame". This is descriptive, identifying, and unique.
0
If I disable the issue tracker on my project, will all of the existing tickets be deleted, or will they become viewable again if I later re-enable the issue tracker?
Without going into detail, I'll just say I feel the new issue tracker is a downgrade from the old (already not very good) one in nearly every regard, and I want to try using an external solution instead. However, if it turns out users really really hate it, I might re-enable the Curse issue tracker at a later date, and it would be nice if that didn't mean re-copying all the tickets again.
For now I'm going to try GitLab; their issue tracker isn't as nice as GitHub's, but they do have the option to sign in with an existing Google, Facebook, Twitter, or GitHub account, so users won't need to register on yet another website just to submit a bug, which I feel is very important.
0
I just deleted several issue tags on Grid ("Defect" because I added a better-named "Bug" tag to use instead, "Enhancment" because it's embarrassingly mis-spelled, "New" because it's useless, etc.) but even after confirming their deletion and clicking Save at the bottom of the page, those tags are still displayed on issues:
https://wow.curseforge.com/projects/grid/issues
The first five tickets are tagged Defect / Enhancment / Defect / New, Defect / Defect, Started. The only one of those tags that should still exist is "Started".
It's not a browser caching issue; I still see the tags when refreshing with Shift-F5, and when I open that page in another browser that's never visited it before.
0
When I click "Edit" above a ticket on one of my projects, make changes, and click Submit, any changes I made to the actual content of the ticket are not saved. Other changes (closing, adding tags, adding a comment) are saved correctly.
Example:
https://wow.curseforge.com/projects/grid/issues/866
Typically when someone submits a ticket with an error message, I prefer to edit the ticket to format the error message as a code block and remove the list of installed addons so I don't have to scroll through 5 screens of irrelevant crap every time I look at the ticket.
0
0
Related to this, it would be nice if the notification emails had useful titles. Under the old system, I'd get emails with titles like "New comment on Grid" or "Comment on ticket for PhanxChat", but now every email is just titled "What's happening at CurseForge".
0
0
Markdown defines `backticks` as producing a <code> tag, which the HTML spec defines as an inline element (flow/phrasing content).
However, your CSS is redefining <code> as a block element, causing my inline code snippets (such as slash commands) to be displayed in a big black box that breaks the text flow (and looks totally out of place with the otherwise snow-white site theme).
This is wrong. This block styling should be applied only to <code> tags inside a <pre> tag, which is the output from a Markdown code block (text indented with 4 spaces or 1 tab, or fenced by ``` [three backticks] lines if your parser supports those) -- not backticks.
See here for an example of the fail:
https://wow.curseforge.com/projects/grid
And here for an example of how the same Markdown document should be rendered:
https://github.com/phanx-wow/Grid/blob/master/README.md
Please fix this.
0
I didn't bother mentioning the obnoxious blinding white and small fonts again because I already wrote my own CSS to make the site usable.
After years of posting the same complaints and suggestions and explanations, and seeing every iteration of the site just make things worse and worse and worse, it's pretty obvious that Curse doesn't give a damn about even the most basic accessibility concerns and isn't going to change anything in this regard. If they do actually offer a dark theme in the future, it will undoubtedly be just as unusable, with tiny fonts and low contrast.
0.960138220412193
Your forum WYSIWYG editor is still horrible. Easily the worst web-based WYSIWYG editor I've ever had the misfortune to be subjected to.
The UI design is terrible, for one; it looks like the bastardized love-child of Windows 3.1 and an early 2000s cell phone UI. I could overlook that if it actually worked, but it doesn't.
Copying and pasting with Ctrl+C (or Ctrl+X) and Ctrl+V don't work in Firefox; I have no idea why you would think it's a good idea to intercept system-wide hotkeys in the first place, but whatever your copy/paste event handlers are supposed to be doing (I didn't bother looking), they're not doing it correctly. Ctrl+X removes the selected text, but doesn't copy it into the clipboard. Ctrl+C and Ctrl+V do nothing at all.
Basic typing and formatting are also unreliable. Pressing the "Enter" key on my keyboard sometimes inserts two linebreaks instead of one. Selecting text and clicking the "bold" button, for example, might bold the selected text... or it might just move the cursor to the end of the entered text and not bold anything.
When pasting text (by right-clicking and then clicking Paste in the context menu, since Ctrl+V doesn't work) from unformatted sources (eg. Notepad), actual linebreaks in the text are doubled (probably CRLF is being incorrectly treated as two linebreaks) and sometimes additional linebreaks are inserted in the middle of lines for no reason (there's definitely not any break-related character in the text there). When pasting text from formatted sources (eg. select all the entered text, copy from the context menu, then paste it back into the same place) the formatting also gets mangled -- again with the random linebreaks, and sometimes things are bolded or turned into headers for no apparent reason.
Similarly, when copying (again, using the context menu) from the forum input area into Notepad, linebreaks get doubled again. CRLF is not a hard problem to solve, guys!
Please just get rid of this monstrosity and use a standard textarea with Markdown or BBCode formatting support. Anyone posting on a forum dedicated to online gaming knows how to use one or both of these formatting systems, and you can even still have UI buttons to insert the appropriate formatting codes/symbols for the people who don't.
Alternatively, get a WYSIWYG editor that isn't terrible -- I can't offhand remember ever using one that I didn't find annoying, but there's got to be something better than this -- or just add an option to disable WYSIWYG editing per-user. As it stands I doubt I will be using the new forums very often. I even enabled commenting on Grid, though I hate comment pages as a communication medium in general, because that's still better than using these forums. :(
0
While it would be possible to write an addon that automatically did the above to notify you if/when the name ever became available on your server, it doesn't really seem worth writing or using, since the odds of someone renaming/moving/deleting the character with the name you want are so low.
If you want to check other servers, you have to create a character and log into them.
You can also search for the character name on the WoW site, but if it doesn't show up in the results, that's not a guarantee it's available, since low-level characters and characters that haven't logged into the game in a long time aren't shown on there.
0
0
2. You can't create a new namespace. Your addon gets one namespace, which is really just a table that's private to your addon's files. If you're currently using it exclusively for your localization (I don't have time to download look at your code right now) then just change it to store the localization as a sub-table instead:
Change this:
To this:
local ADDON_NAME, private_table = ... local L = setmetatable({}, <localization thingy here>) private_table.L = L L["Something"] = "Bla bla bla"Now you can store whatever you want in "private_table" -- that's your addon's namespace.
3. Yes. Use an indexed table rather than key/value pairs:
-- Table only has values: local t = { "something", "something else", "another thing" } -- Print the values in order: for i = 1, #t do local v = t[i] print(v) endvs
-- Table has keys and values: local t = { ["something"] = "hi", ["something else"] = "yes", ["another thing"] = "no", } -- You can only print them in "undefined" order: for k, v in pairs(t) do print(k, v) endIn reality, the indexed table does have keys; it's the same as this:
local t = { [1] = "something", [2] = "something else", [3] = "another thing" }...but you don't actually have to write the keys. You can still refer to the values as t[2] no matter how you constructed it.
The values can also be sub-tables:
local t = { { "something", "hi", 9000 }, { "something else", "yes", true }, { "another thing", "no", false } }... so they're still in order, but you can store multiple values in each top-level value. You'd access "no" in the above example as t[3][2].
The subtables can use key/value pairs:
local t = { { name = "something", value = "hi" }, { name = "something else", value = "yes" }, { name = "another thing", value = "no" } } for i = 1, #t do local v = t[i] print(v.name, v.value) endYou'd access "no" in that example as t[3].value
0
https://github.com/Phanx/oUF_Phanx
The TOC and .pkgmeta files will be of most interest; the "Config" folder gets moved to "oUF_Phanx_Config" up at the same level as the main "oUF_Phanx" folder. In an un-packaged copy (eg. your working copy) the Config/* files get loaded from the main addon's TOC, wrapped in @do-not-package@ keywords so the packager removes those lines.
0
0
As for the question, you have the right idea, but please don't use things like "ab" as a global frame name. If there's ever a problem with your addon, or someone is just curious, nobody will be able to figure out what "ab" or "tbfg" means in a /framestack tooltip or an error message.
All global variables -- including frame names -- should follow two rules:
1. They should clearly identify the addon that created them ("ab" offers no clues) and ideally clearly identify what purpose they serve within that addon ("ab" is only helpful once you figure out which addon it belongs to).
2. They should be unique, so there's no chance of colliding with global variables from other addons or the default UI ("ab" is really generic, so there's a high probability of collision).
An easy way to satisfy both rules is to prepend your addon's name to a meaningful name, eg. "MyAddon_ArathiBasinFrame". This is descriptive, identifying, and unique.