silverstripe/addons.silverstripe.org

Website hosting Silverstripe Framework extensions

addons.silverstripe.org's Issues

Allow merging of maintainers

This is probably an admin-only feature, but it would be good if a single maintainer could be recognised as having multiple git-commit email addresses, so that Marcus isn't listed 3 times.

I'd probably manifest this as a "merge maintainers" function available to authorised users.

Add deprecation note to old ss.org/modules listing

See #31 for also disabling any state changing operations there.

Migrate live environment to SilverStripe infrastructure

Ensure elastic search still works, ideally as a third party service.

Confirm that we don't allow inline HTML in parsed Markdown

That would be a security risk

Addon build not working

Addon build no longer working. In first look it seems problem with PackagistService. I am looking into possibility of replacing this with new API, hope that should work. Otherwise we will have to think about github ways of doing this as suggested by @hafriedlander here

cc @chillu @simonwelsh

Remove SilverStripe Prefix From Package Names

For example, ajshort/silverstripe-gridfieldextensions should be displayed as ajshort/gridfieldextensions.

Add "submit module" trigger (and supporting docs)

Should be prominently placed, probably in the main navigation. It needs to link to Packagist, since we don't want to recreate the whole module management on our own site.

A simple external link will be too confusing and leave people wondering why they're on a different site. Should probably go to a help page which describes what Packagist is, how it relates to composer, a note about vendor prefixes, and that you have to wait a couple of minutes for the module to become available on exts.ss.org.

On the long run, it'd be better to use an API to submit packages to packagist, but that requires OAuth to link Packagist and exts.ss.org, so unlikely to happen soon.

Add "copy to clipboard" for composer require call

Same as rubygems.org: http://monosnap.com/image/GlaABiO7Um4J799bn82WZ50Ml

Browse by vendor

The "silverstripe/" part in the package name is actually supposed to be the vendor, and not an indicator that the module is part of SilverStripe.

To reinforce this, it would be good to have a "Vendors" view, that listed all the vendor prefixes used by SilverStripe modules.

As well as listing the packages, it would be helpful to list all the maintainers linked to any of the modules under that vendor.

Add comments

I would suggest we simply use Disqus, since we already use it on api.ss.org and doc.ss.org. Ask Ingo about setup, we already have an account there.

Add module installation help links

Each module detail page should have basic instructions around composer require ..., and link to more detailed docs at http://doc.silverstripe.org/framework/en/topics/modules. There should also be some blurb on the homepage.

Disable module updating logic and upload/edit functionality on ss.org

Depoyment task, not related to this codebase. The old updating logic causes a deluge of error emails due to wrong git paths, etc

Show module dependencies

They're exposed through the composer API, show them as well (and link them to our internal views for this module, if there's any match).

Friendly "not found" and "server error" pages

We don't need a failwhale, but a few nice words in the same design framing would be nice :)

Show docs/en/index.md as fallback for missing README

Add website footer to template

Link to extensions.ss.org project on github, potentially add copyright info

Search broken on live site

PHP Fatal error: Call to a member function obj() on a non-object in framework/view/SSViewer.php on line 90, referer: http://addons.silverstripe.org/add-ons?search=simon

https://gist.github.com/ss23/6459500 is a var_dump of $list just before the end of Addons()

Someone else should investigate, because I have no idea. Suspect it's related to the search?
Would be nice to have a better error message if there is an issue there.

Link to ZIP downloads if hosted on github.com

We can infer the download links from the github projects (or use their API?). One download per version.

Browse existing tags

Show by popularity. Doesn't have to be a tag cloud though.

I'm making this a pre-launch task because it'll be important for module authors to get an understanding of the used tags, so they don't create slight variations of the same stuff when porting their modules.

Queue implementation for extensions update and download

At the moment, we might get a new module or module release every couple of hours,
so a periodical update is adequate. But once we get to a higher frequency, it'll be ineffective
to download sources for many repos synchronously in a PHP task.

@ajshort How long does a full update take at the moment, for how many modules? Do you agree that a queuing solution is the right tool for the job here, or oversized?

Add stats to homepage

We want to visualize that our ecosystem is alive and growing, and give devs confidence in choosing SS, and its extensibility.

Show addon total count, number added in the last 30 days, number of releases in the last 30 days. We probably don't have enough activity yet to warrant "added this week", nor to show a "themes" count separately.

We could even graph the data, but that'd require us to either keep a record of the total counts, or change the internal structure to retain addons and go by their "created" date.

Rewrite relative links and images in README

Special case for github: Prefix all relative links with http://raw.github.com and their repo path, to avoid broken images.

Or see if we can use the Github rendering API with the context attr for it: http://developer.github.com/v3/markdown/

Example: http://addons.silverstripe.org/add-ons/heyday/silverstripe-dataobjectpreview

Document how to migrate a project from ss.org/modules to Packagist+composer+exts.ss.org

Should go on a (static?) help page on the site itself (would be too buried in docs.ss.org).

• If ZIP upload, convert to git project first
• Convert description to README on github, upload any images
• Ensure composer.json has author info (with email)
• Link to composer docs on how to decide on a namespace and declare dependencies
• Describe how to add "sub-tags" for previous releases to make them composer compatible (e.g. blog 3.0.1 copied from blog 0.3.0 with an existing composer.json file)

Environment checks, pingdom uptime monitoring setup

• Test HTTP connection to packagist.org, ensure we can retrieve a valid JSON file
• Check that homepage displays some module links
• Check that detail page for a popular module renders
• Check that search returns at least one result
• Add site to pingdom (under SS Ltd. account)-
• Set up error emails to the usual suspects

Note: Use https://github.com/silverstripe-labs/silverstripe-environmentcheck

Allow filtering by supported SilverStripe version

Critical feature since many modules are still in the process of making their codebase 3.x compatible.

Design theme list/grid view

• Separate "themes" menu entry (same level as extensions
• Show a small preview image of the them, preferrably in a gallery view (rather than the list view for extensions)

composer.json generator for existing ss.org modules

Natural followup work from #3: Provide a composer.json download for modules and themes hosted on ss.org already.

• Convert description to README, inline any attached images (hotlinked to ss.org)
• Author info from member profile
• Dependencies

Permanent redirects for popular modules on ss.org

Cool URIs don't change :)

Implement theme list/grid view

See #8 for design and approach. Ideally we can read the screenshot from custom "extra" field data in composer.json (see http://getcomposer.org/doc/04-schema.md#extra).

Allow blacklisting of modules

Prevent modules which are known to be broken or harmful from appearing on the site.

Rename Extensions to Addons

Avoid Unneccesary Locking When Building Extensions

A transaction is started for each module when it's being built, but this can take a long time, leading to locking issues.

Create a generic SS community sites base CSS

To be used with bootstrap-based sites, for now primarily api.ss.org, extensions.ss.org and eventually ss.org. Note that this is different from a SilverStripe theme, since it should be useable in non-SS projects like the staticically generated api.ss.org as well.

Link to maintainers view from extension detail view

E.g. "Will Rossiter" on http://extensions.andrewshort.name/extensions/silverstripe/userforms should link to http://extensions.andrewshort.name/maintainers/16

Fix Version Sorting

The newest version should be shown first.

Not all read me files being pulled in.

Example: http://addons.silverstripe.org/add-ons/simonwelsh/hasoneedit

Readme you get from a composer install of the module: http://svn.simon.geek.nz/hasoneedit/trunk/README.md

git repository URLS don't work.

Repository links in git format don't work.

Clicking on a link to the repo i get a 404 cause the link isn't formatted correctly:

http://addons.silverstripe.org/add-ons/azt3k/abc-silverstripe-social

clicking on

[email protected]:azt3k/abc-silverstripe-social.git

i get

http://addons.silverstripe.org/[email protected]:azt3k/abc-silverstripe-social.git

This is just a random example i just stumbled over.

Update module installation docs to include composer instructions

Update http://doc.silverstripe.org/framework/en/topics/modules
This is not strictly related to this project, but since its a pre-launch task I'm tracking it here.

Redirect packages which change their names through "replace" in composer.json

We want permanent URLs as much as possible, but names can change. Thankfully in a structured way through composer (http://getcomposer.org/doc/04-schema.md#replace) so we can pick up on that. Its unclear how ownership is handled, presumably we'd have to check that the old package name no longer exists to avoid somebody "stealing" a module.

no packages are being retrieved from the tasks /dev/tasks/UpdateAddonsTask?clear=1

Hi

I seem to have installed everything correctly, but I can not retrieve modules. I run the task (dev/tasks/UpdateAddonsTask?clear=1) , but I cant seem to get any packages.

I looked into it:
composer/composer#2137

but as I got deeper and deeper into composer, I have lost track of what is going on.

Let me know.

Nicolaas

Filtering addons by compatibility doesn't seem to work

See here:

http://addons.silverstripe.org/add-ons?search=&type=module&sort=downloads

Select any version and click search:

http://addons.silverstripe.org/add-ons?search=&type=module&compatibility%5B%5D=3.0&sort=downloads

No results

Add github "stars" and "forks" stats

Ideally serverside, so we can have it influence search results. At the most basic level, something like http://ghbtns.com/ will do though.

"Force update" abilities for module owners (requires login implementation)

As long as we only update with a periodical task, even a 5 minute wait for packagist updates to propagate will be inconvenient to module authors. Particularly since they have to wait for Packagist to regenerate its packages.json in the first place. Allow force updating the specific module for module owners. In order to restrict this feature, we need some way to determine ownership on a module (ideally via an email-based login).

Improve elasticsearch field boosts (README content too strong)

See http://addons.silverstripe.org/add-ons?search=*external*&type=&sort=
It should rank "silverstripe/external-content" above sqlite3. This has become a problem since we started indexing the README

Search without keyword doesn't work

http://addons.silverstripe.org/add-ons?search=&type=&compatibility%5B%5D=3.0&sort=
Its handy to show you all modules compatible with a specific version

/cc @sminnee

Implement screenshot extraction

Should allow extracting single or multiple screenshots defined in the extra section in composer.json. Should allow using local or remote images, and save them to local assets.

Single Signon with silverstripe.org

Ideally with ss.org as an OAuth server, but that might be too many dependencies for now. We should get it right the first time though, don't want to get into migrating partial user accounts for hundreds of users

Delete packages removed from Packagist

For example, http://extensions.andrewshort.name/extensions/silverstripe/basic-galleries no longer exists on Packagist (seems to have its vendor prefix renamed)

Only list latest releases for each compatible SS version

If a module has many releases and branches its easy to clutter up the page, and make it unclear what to install. Say the blog module has a bunch of 0.6.x releases, but you want the 3.0 compatible version. You'd have to scroll all the way down to the latest 0.5.x release to get there.

We should list dev-master plus whatever is the latest release compatible with the major SS releases (3.1, 3.0, 2.4). Ideally each in a tab, defaulting to our latest stable release.

"Star" a module

Similar to the github approach. Acts as a "favourite modules" list, from which we can build up, e.g. customized RSS feeds, new version alerts, etc.

Dev note: Since we don't allow login, a lightweight approach for this would be browser localstorage.