[zjays]

(06-03-2015, 11:12 PM)rsjtdrjgfuzkfg Wrote:

(06-03-2015, 06:44 AM)zjays Wrote: Is it possible or feasible to hack the "Find Updates" portion of the Nightingale extension manager to check for add-on updates by checking either the last update date field, or the version number field (if implemented) on the addon page?

No. One could set up a server-side solution doing what you say, but I'd rather not change client update code, as it is standartized between all XULrunner applications (Firefox, Thunderbird, ChatZilla, SeaMonkey, ...). Also, any kind of update mechanism needs HTTPS, else all add-ons must be signed individually iirc. Add-ons can also use the update mechanism with custom endpoints, which may be disturbed if we change this in a quick-and-dirty manner (and I consider a proper implementation to consume more time than completing featherweight or a new add-on platform with update support).

Got it, thanks.

[zjays]

So, do we want to implement a download counter for each of the add-ons on the new add-on page?

The DokuWiki pluginrepo that was adapted for Nightingale has a sortable popularity column (see here). From what I understand, for DokuWiki, this column has a bar representing the total number of installs for each plugin divided by the total number of installs of all plugins. I believe DokuWiki collects their install numbers using a popularity feedback plugin that is bundled with DokuWiki. For us, I'm wondering if we can replace this with another DokuWiki plugin, DLCount, that counts the number of downloads and adds a download counter next to download links. The popularity column of our forked pluginrepo would then have to be modified to collect download counts from each of the meta-files that the DLCount plugin creates.

Thoughts? Does this make sense?

[rsjtdrjgfuzkfg]

(06-15-2015, 04:08 AM)zjays Wrote: For us, I'm wondering if we can replace this with another DokuWiki plugin, DLCount, that counts the number of downloads and adds a download counter next to download links.

Sounds reasonable.

(06-15-2015, 04:08 AM)zjays Wrote: The popularity column of our forked pluginrepo would then have to be modified to collect download counts from each of the meta-files that the DLCount plugin creates.

From what you wrote, popularity is currently something relative to the total number of installs. If the popularity structure can handle unbounded numbers, using the download counter seems resonable. If not, we'd need to define some kind of mapping (what is "60 %" Popularity in terms of download counts?), not sure about what would be a good aproach there. One could calculate it relative to the add-on with most downloads, or relative to a fixed table / function. I guess this depends on the way the numbers turn out to be; thus I'd not consider the popularity thing a high priority. Nevertheless feel free to work on it if you want to

[zjays]

Progress update:

See all commits here.

Summary:

• Change/add add-on categories as discussed here
  
• Remove add-on/feather from add-on name in the table
  
• Remove popularity column from table - I quickly found out that the DLCount Dokuwiki plugin doesn't work for the download button of the pluginrepo Dokuwiki plugin, and I don't want to work on this any more for now. As a sort-of substitute, we can use the Rating Dokuwiki Plugin on each plugin entry page and display the average rating statistics of all add-ons in a chart somewhere else on the wiki (see previews below). My goal with this is to see which add-ons people are using the most and which ones have major problems.
  
• Implement "Back to Add-ons Page" button on add-on entry
  
• Implement icon image on add-on entry
  
• Larger screenshot on add-on entry page
  
• Download Button Changes - rename to "Add to Nightingale" and move to top right of entry page
  
• Re-arrange entry page - Float all the detail stuff to right side
  
• Implement Version # into metadata and entry page
  

Previews: (MAFF Web Archives, let me know if you can't see these)
Add-on Entry Page
Add-ons Repo Page (not completely populated)
Add-on Rating Statistics

Still to do:

• Make a namespace template for pages under namespace "add-on:" (https://www.dokuwiki.org/namespace_templates) containing the required syntax
  
• If we want a discussion page under each add-on entry, as I have in my attached preview - Install Discussion Dokuwiki Plugin to the Nightingale Wiki (https://www.dokuwiki.org/plugin:discussion). (Needs Nightingale Admin)
  
• If we want the add-on pages (and the whole Wiki) to better match the new website theme - alter Nightingale's Dokuwiki template. For the previews attached, I changed the colour of existing inlinks to the coppery colour used on the forums (#B55029), and made the missing inlink colour a brigher shade of red (#FF0000) to better differentiate it from the coppery colour. (Needs Nightingale Admin)
  
• Install the updated pluginrepo (the ngale branch) to the Wiki (Needs Nightingale Admin).
  
  And after the above items are done, I will:
  
• Update add-on entries with new category names, version numbers, icon images, screenshots, and proper URLs with underscores for spaces (needed to make my planned namespace template work properly)
  

Let me know your thoughts on the above. I don't think I want to make any more big changes in the near future. So if everyone is okay with what GeekShadow and I have done, I think it's ready to deploy to addons.getnightingale.com after finishing the last to-do items!

[rsjtdrjgfuzkfg]

(07-17-2015, 12:00 PM)zjays Wrote: So if everyone is okay with what GeekShadow and I have done, I think it's ready to deploy to addons.getnightingale.com after finishing the last to-do items!

I don't see any issues with your list, however I did not have a look at the dropbox thing (downloading seems not to work without JS anymore).

I'd rather not have a second DokuWiki instance, or is the new add-on platform independent of DokuWiki itself? If not, I'd just keep it in the wiki (similar to the current add-on page) and redirect addons.getnightingale.com towards that, instead of directly deploying there. In that case, imho you can directly deploy to the current playground, and if it works and we have all content migrated we (read: GeekShadow, as he is the only wiki admin iirc) can rename the playground and link to it from addons.getnightingale.com.

[zjays]

(07-18-2015, 04:05 AM)rsjtdrjgfuzkfg Wrote: I don't see any issues with your list, however I did not have a look at the dropbox thing (downloading seems not to work without JS anymore).

Here's a couple screenshots of the add-on entry page (two images): http://imgur.com/3yW5xgl,mE3eQVE#0
The main add-on repository page is basically what Geekshadow already has on the current Nightingale Wiki (http://wiki.getnightingale.com/doku.php?...playground), except with the popularity column removed and the add-on categories updated.

(07-18-2015, 04:05 AM)rsjtdrjgfuzkfg Wrote: I'd rather not have a second DokuWiki instance, or is the new add-on platform independent of DokuWiki itself?

Sorry, I should have explained it better. It won't be a second DokuWiki instance - it's using a Dokuwiki plugin that Geekshadow already installed to the Nightingale Wiki a few years ago (he explains it earlier in this thread). We had to modify the plugin because it was originally intended just for Dokuwiki's own usage (to handle their own collection of plugins). I was just using a Dokuwiki instance installed locally on my computer to test out my changes. So if my modifications to the plugin are approved, the updated plugin will just have to be re-installed to the current Nightingale Wiki.

(07-18-2015, 04:05 AM)rsjtdrjgfuzkfg Wrote: If not, I'd just keep it in the wiki (similar to the current add-on page) and redirect addons.getnightingale.com towards that, instead of directly deploying there. In that case, imho you can directly deploy to the current playground, and if it works and we have all content migrated we (read: GeekShadow, as he is the only wiki admin iirc) can rename the playground and link to it from addons.getnightingale.com.

Actually, the way the plugin is coded right now, it needs to live on the "add-ons:" namespace. So I'm thinking when it's ready, we move the old add-ons page to something like "add-ons_old:", and move the playground to "add-ons:" (and then addons.getnightingale.com would already re-direct to it).

[rsjtdrjgfuzkfg]

(07-18-2015, 05:24 AM)zjays Wrote: So I'm thinking when it's ready, we move the old add-ons page to something like "add-ons_old:", and move the playground to "add-ons:" (and then addons.getnightingale.com would already re-direct to it).

I was thinking the same thing, we just seem to have talked cross purposes

[zjays]

The new add-on repository includes the option for a Donate button. I'll put the Nightingale Bountysource link (https://www.bountysource.com/teams/nightingale) as the Donation button for any add-ons developed by Nightingale devs (Geekshadow, freaktechnik, rsjtdrjgfuzkfg) and the core ones previously developed by POTI and now maintained by Nightingale devs. If anyone has any issues with this, or if you prefer a personal donation link, let me know.

[rsjtdrjgfuzkfg]

(07-22-2015, 05:38 AM)zjays Wrote: If anyone has any issues with this, or if you prefer a personal donation link, let me know.

For now that seems reasonable, although we should figure something better out for project donations if we see that people are actually interested in donating, as their fees are quite high (but proper donation handling is terrible due to legal stuffz, imho).

I'm unsure if/how we should mark the donation link clearly as belonging to the project and not the individual add-on, though.

[zjays]

(07-24-2015, 09:26 AM)rsjtdrjgfuzkfg Wrote: I'm unsure if/how we should mark the donation link clearly as belonging to the project and not the individual add-on, though.

I think that's a good point. How about this for now?
https://github.com/zjays/dokuwiki-plugin...f20cc5f50a
Preview: http://i.imgur.com/87ZEYCL.jpg