Supposed I have an extension named "Slider" and would like to rename it to "Slider Field".
Would that be possible in the symphony extension eco-system or would I face unsolvable problems?

1. On github itself it wouldn't be a problem.
2. How would it work on symphonyextensions.com? Would it be possible? Would I have to post an issue here and request renaming or could I do it myself?
3. Regarding Symphony CMS itself. Would it be possible to change the name of an extension while updating or would this be impossible due to the way Symphony uses names to identify extensions? If so would this mean, that a renamed extension would only be possible to include in Symphony as a new extension?

Would be great to clarify this and would be some useful information to include in a kinde of "FAQ" in the readme of this repo.

@nitriques - I'd like to label this issue with FAQ, but it looks like I can't create new labels. Could you take care of this?

There are way too many places where we have doc.

The only place where I feel comfortable putting my trust in would be to create a .docs folder in the main git repo.

I would not store anything else than markdown files. Any other fancy generator could live elsewhere. But there are two major win

1. We tie the doc with the release version.
2. We allow PR on docs!

Am I pretty confident that this is the good way. Please show me that I am wrong/right. ;)

Extensions belonging to an organization can be added but not removed. This is a show-stopper for certain cleanup efforts of the community.

Hey Nicolas,

I just adopted Member Last Visit from Mark Lewis, drafted a new release for Symphony 2.4-2.6 compatibility and will now start working on an update for Symphony 2.7.

Could you please change ownership of the extension on symphonyextensions.com – Thank you very much!

It's been 6 days since I published the latest release 2.1.0 of Output Field, but it's still not showing up on symphonyextensions.com. Could you have a look @nitriques?

@twiro contacted me to transfer one of my old extensions to his account. He also suggested to transfer other extensions to the symphonists organisation. I'm happy to do that as I stopped using Symphony a couple of years ago. I was not able to transfer this extension directly, so here is the PR :-)

https://github.com/klaftertief/content_negotiation/

symphonyextensions.com has some serious issues in understanding some content in markdown-formatted readme-files. For example it can't handle multiple H1-elements, tables or code-blocks that use spaces for indenting instead of tabs.

As these issues come to show very obviously in the readme of the latest version of reflection field I think it would be a good moment to discuss what we could to to improve this.

I see two options:

1. Improve the capabilities of symphonyextensions.com (might be a little tricky as far as I remember) (But I would gladly take care about any CSS-related stuff if @nitriques could fix the markup/formatter-related part)
2. Set up some more restrictive guidelines/recommendations regarding the formatting of readme-files that play nicely together with symphonyextensions.com and publish them here in the network-repo.

Option 2 would be easy to do, but option 1 might be the better solution in the long run... what do you think?

I took the introduction of github topics as a reason to finally add a second chapter to this repo - it's about recommendations and best practices regarding "Extension Publishing".

This is only a draft for now and at least the two following points need to be discussed and agreed upon before publishing the chapter to the master-branch.

1. Should the 1.0.0-syntax be promoted as the official best practice for version-tags of github-releases or should we stick with github's own recommendation of adding a prefixed "v":v1.0.0? I'd vote for the first option as this is how Symphony has used version-tags on github since the repo moved there. And not to forget - the prefixed "v" results in missing links in the compatibility-tables on symphonyextension.com... though I guess & hope this could be fixed.
2. Should publishing extensions on getsymphony.com still be recommended? I'm not so sure...

Any other feedback or ideas hot to optimize this chapter are welcome!

@twiro contacted me to transfer one of my old extensions to his account. He also suggested to transfer other extensions to the symphonists organisation. I'm happy to do that as I stopped using Symphony a couple of years ago. I was not able to transfer this extension directly, so here is the PR :-)

https://github.com/klaftertief/language_redirect/

Please remove the Storage extension (from the extensions site). Afterwards I will re-add it, because I am the maintainer now.

Hey Nicolas,

I've adopted the extension geocodingfield from @klaftertief, so it would be cool if you could change things accordingly on sympohnyextensions.com.

Extension-Updates will follow & big thanks to Jonas for originally crafting this!

On behalf of a healthy extension ecosystem I would like to propose an extension transfer of the Text Box Field extension:

• Text Box Field is currently actively maintained by the symphonists and 20 commits ahead of Rowans repo that hasn't been updated in 3 years.
• Symphonyextensions.com is still listing Rowans repo as the official extension resource.
• Multilingual Field also lists Rowans repo as a dependency.

I think this should be changed by...

1. ...transferring ownership of the extension to either the symphonists account or (even better) to someone who is willing to personally take care of the extension.
2. ...fixing the entry on symphonyextensions.com and linking to the new "official" repo (will also solve the problem for multilingual field).

@nitriques , @psychoticmeow, @brendo

@twiro contacted me to transfer one of my old extensions to his account. He also suggested to transfer other extensions to the symphonists organisation. I'm happy to do that as I stopped using Symphony a couple of years ago. I was not able to transfer this extension directly, so here is the PR :-)

https://github.com/klaftertief/imagecropper/

The lang_german extension has been moved to a repo in my github account. It redirects properly on github but should have the proper owner in the first place. If I log into the extensions-site via github I don’t see any repositories I could add.

Looks like github just reinvented "tags" and introcuded "topics" to offer a "completely new way to discover similar repositories":

"Topics are labels that create subject-based connections between GitHub repositories and let you explore projects by type, technology, and more."

While this doesn't feel like a big innovation it's still pretty useful and it would be nice to have one or two "official recommended" labels for Symphony that could be documented here and promoted in the community as best practice to be used for tagging github-repos.

I'd suggest...

• symphony-cms for everything Symphony related
• symphony-cms-extension for Symphony extensions

...as these two terms are pretty distinct and don't interfere with other systems/technologies like solely using symphony or extension does. (sorry for abusing your first extension's repo as example @SeanVella - but as topics are pretty new there aren't many symphony-related repos around that do have any topics attached ;)

Any thoughts?

Not sure which one is wrong, but the lint tool and the documentation on symphonyextensions.com disagree on certain things.

From symphonycms/symphonycms#2285

cc @alexnantel88

Just noticed that older minor releases now get bundled as 2.2.x, 2.3.x, 2.4.xetc. in the compatibility table on symphonyextensions.com.

While it's a good move in general to clean & tighten up the tables I think the current solution is somehow saving at the wrong end:

While almost every extension that's compatible with 2.6.0 will also be compatible with 2.6.7 and every 2.6.x-release in-between the same is not true for compatibility of "patch"-releases in-between older minor releases (before the introduction of semver) .

For example: Symphony 2.3.3 came with a breaking change regarding file upload paths. Thus all upload extensions needed to treat file uploading and storing different in Symphony 2.3.3 than they did in 2.3.2.
I just resubmitted the Reflected File Upload extension and the compat-table on symphonyextensions now shows version 1.1 as compatible with Symphony 2.3.x - but this is only true for Symphony 2.3.0, 2.3.1 and 2.3.2 - as of Symphony 2.3.3 version 1.1 of the extension will break things as Symphony 2.3.3 requires version 1.2 of the extension due to the above mentioned change regarding the file upload path.

I still have some old sites running on Symphony 2.2.x and 2.3.x (I know, better should update) and the detailed compat-tables on symphonyextensions always were of great help when updating
to a newer Symphony version and fighting the fact that every single extension might break with every single patch-release.

So I guess these detailed compat-tables for older symphony releases (at least 2.2.x and 2.3x) are still pretty useful for every developer who needs to update these installations to a newer version.

tl;dr

I would vote for bundling patch-versions of all minor releases starting with Symphony 2.5.0 (the introduction of semver) and keeping single patch-versions listed for older Symphony releases that were not following semantiv versioning (at least for 2.3.x, better also for 2.2.x).

So the latest parts of the compat-table would look something like that:

Note: This proposal is meant for the single extension pages that offer more space for a detailled compat-table than the compatibility matrix does. In the matrix (that's mainly used to get a quick overview) a general bundling of all patch-versions (just listing 2.2.x, 2.3.x, 2.4.x, 2.5.x and 2.6.x) would be totally sufficient in my eyes.

a "how-to-transfer-ownership-on-symphonyextensions.com" guide as well as the possibility to file a new issue to request the change if I can't do it myself would be a pretty good start!

Good point!

Here we go - first issue on this repo :)

Ownership of the "slider" extension has been transfered to my github-account today:

• http://symphonyextensions.com/extensions/slider/
• https://github.com/twiro/slider

It would be great to reflect that change on symphonyextensions.com.

It would be even greater to include a first "FAQ" in the readme that would give me instructions how a change of ownership on symphonyextensions.com works and what i should best do to accomplish it.

@twiro contacted me to transfer one of my old extensions to his account. He also suggested to transfer other extensions to the symphonists organisation. I'm happy to do that as I stopped using Symphony a couple of years ago. I was not able to transfer this extension directly, so here is the PR :-)

https://github.com/klaftertief/page_prototypes/

I'd like to add a short third chapter about extension development to this repo. Not a a real guideline or tutorial, rather a curated list of helpful links - at least for the beginning that would be better than nothing!

The information about extension development I found are mostly somehow out of date, but nonetheless still helpful - does anyone know other / better resources?

• http://symphonycms.github.io/docs.getsymphony.com/community/developing-extensions.html
• http://www.getsymphony.com/learn/articles/view/creating-a-field-extension-for-symphony/
• http://www.getsymphony.com/learn/concepts/view/extension-file-structure/
• http://www.getsymphony.com/learn/concepts/view/delegates/
• https://github.com/lewiswharf/sedk
• https://gist.github.com/brendo/901476

Sadly the "We have a tutorial on developing extensions that walks you through how to create a simple extension from scratch." part on the first linked page doesn't seem to be true - the link is dead :(

I just updated the slider extension I recently adopted and included some tables (written as markdown) to the readme... sadly markdown tables don't seem to get formatted by the markdown-formatter on symphonyextensions.com - Any chance that could be changed?

I really think tables can be a quite useful addition to readme-files and would gladly help with css/styling-tasks regarding updating symphonyextensions.com

Symphony 2.7 will be compatible with PHP7, but many extensions won't. But how can a developer see if an extension will run on PHP7?

I wonder if we should define a "best practice" for marking extensions compatible with PHP7. Maybe we should add an (interim, to be removed later?) element or attribute to the meta XML scheme?

For example:

<release version="7.4" date="2017-04-28" min="2.7.x" max="2.x.x" php7="yes">

In lang_german version 2.1.0 it states Symphony 2.4.0 as minimum requirement. Thus it should be shown as compatible with Symphony 2.5.x as well if not stated otherwise by some newer version.

    <release version="2.2.1" date="2015-10-29" min="2.6.0">
        - Transliteration for non-breaking space
    </release>
    <release version="2.2.0" date="2015-07-21" min="2.6.0">
        - Symphony 2.6 compatibility
    </release>
    <release version="2.1.0" date="2014-03-18" min="2.4.0">
        - Symphony 2.4 compatibility
    </release>
    <release version="2.0.0" date="2013-04-03" min="2.3.0">
        - Symphony 2.3 compatibility
    </release>

But instead it says Symphony 2.5.x is not compatible.

@twiro contacted me to transfer one of my old extensions to his account. He also suggested to transfer other extensions to the symphonists organisation. I'm happy to do that as I stopped using Symphony a couple of years ago. I was not able to transfer this extension directly, so here is the PR :-)

https://github.com/klaftertief/markdown_editor/