Re: [Radiant] Extensions with 0.8
Shouldn't we just use rubygems? It already supports dependency management and versioning (this looks like the rails plugins vs gems discussion). We could version them with the radiant version so we could automate getting the proper version: - 0.7.1.2 (works on radiant 0.7.1) - 0.8.0.2 (works on radiant 0.8.0) This would actually be my preferred solution, and I'd like to do some investigative work to see what (if any) modifications would need to be made to the extension architecture to support this. I don't think it removes the need for a better set of community standards/guidelines for the development and management of extensions, though -- if anything, if you're going to maintain a product with actual concurrent releases you probably want a schema like the version- branches we've been discussion. But to the point, I like where this is headed. There's another thread out there about using application templates to bootstrap a Radiant instance; that plus `config.gem 'radiant-awesome-extension'` could be some powerful mojo. j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
On 23.06.2009, at 15:43, Josh French wrote: My take on this is that it's best to keep separate branches. Following a consistent naming scheme for the branches would be a necessity for any sort of automated management, and would be a good idea in general. ... My thoughts exactly. Tags are fine for small things, but either branches or version-checking methods are the way to go for more advanced support. This is the pattern we've been moving toward internally -- do three votes count as consensus? :) I can (maybe) find some time soon to start going through the core extensions and making sure everything's got at least a 0.7 or 0.8 branch, if not both. For some of our own not-yet-released extensions, I've actually done away with the master branch and set the default HEAD ref to 0.8, just so there's no confusion as to what the current line of development is. Yea? Nay? Yeah. And I would suggest to tweak ray a bit. ray could have a look at what is set in environment.rb and switch branches according to the radiant gem version. that would be good for the not so tech savvy people out there :-) just my 2 cent cu edi -- DI Edmund Haselwanter, edm...@haselwanter.com, http://edmund.haselwanter.com/ ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
My take on this is that it's best to keep separate branches. Following a consistent naming scheme for the branches would be a necessity for any sort of automated management, and would be a good idea in general. ... My thoughts exactly. Tags are fine for small things, but either branches or version-checking methods are the way to go for more advanced support. This is the pattern we've been moving toward internally -- do three votes count as consensus? :) I can (maybe) find some time soon to start going through the core extensions and making sure everything's got at least a 0.7 or 0.8 branch, if not both. For some of our own not-yet-released extensions, I've actually done away with the master branch and set the default HEAD ref to 0.8, just so there's no confusion as to what the current line of development is. Yea? Nay? The biggest problem as I see it is that many extensions are graciously released to the world for use, but that doesn't mean the author will be everyone's tech support. So they are released at version X and by the time version Y comes around many people are using it but the author is off doing something else (and not busy updating his/her extension). I think it would be nice if Radiant had some way to check for features that were added in different versions. I've been tinkering with the extension_config features and I may toss in some way of specifying that an extension is compatible with a particular version(s) of Radiant -- something that would work both when Radiant is gemmed and vendored. Not a perfect solution, since as you point out this isn't necessarily future-proof, but it would at least alert a developer up-front when they try to install something that isn't backwards compatible. j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
On Jun 22, 2009, at 15:50 , Josh French wrote: Not obvious, but Josh French has committed changes for the next release that will allow extension developers to configure dependencies from the extension which might help with the installation process as far as things like error messages go. There will be more development on this in the future. One thing that we don't have is a way of ensuring that the proper version of an extension is installed from the get-go. I'm in the arguably bad habit of manually installing everything, so I was unaware of some of the problems that occur when trying to install extensions via script/extension or ray. To wit, using an installer to install a 0.8-style extension will fail if your base Radiant install is 0.7 or earlier. Because the extension is checked out at its head, the environment fails and neither rake:migrate nor rake:update can be run until the extension is frozen to a compatible tag/version. This could be solved by adding a version argument to the install method, or by baking knowledge of the current Radiant version into the installer. I've been tagging the extensions I'm involved with for compatibility at versions 0.7.1 and 0.8.0, but I've also been wondering if it wouldn't be better to maintain those via branches instead of tags -- have a 0.7 branch to hold bugfixes, but continue new development in 0.8 and so on. Thoughts on how best to manage extensions across multiple, possibly incompatible, versions of Radiant? Shouldn't we just use rubygems? It already supports dependency management and versioning (this looks like the rails plugins vs gems discussion). We could version them with the radiant version so we could automate getting the proper version: - 0.7.1.2 (works on radiant 0.7.1) - 0.8.0.2 (works on radiant 0.8.0) You can also have a nice list of all radiant extension: gem list --remote | grep radiant*.extension Petrik ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
On Jun 22, 2009, at 9:50 AM, Josh French wrote: Not obvious, but Josh French has committed changes for the next release that will allow extension developers to configure dependencies from the extension which might help with the installation process as far as things like error messages go. There will be more development on this in the future. One thing that we don't have is a way of ensuring that the proper version of an extension is installed from the get-go. I'm in the arguably bad habit of manually installing everything, so I was unaware of some of the problems that occur when trying to install extensions via script/extension or ray. To wit, using an installer to install a 0.8-style extension will fail if your base Radiant install is 0.7 or earlier. Because the extension is checked out at its head, the environment fails and neither rake:migrate nor rake:update can be run until the extension is frozen to a compatible tag/version. This could be solved by adding a version argument to the install method, or by baking knowledge of the current Radiant version into the installer. I've been tagging the extensions I'm involved with for compatibility at versions 0.7.1 and 0.8.0, but I've also been wondering if it wouldn't be better to maintain those via branches instead of tags -- have a 0.7 branch to hold bugfixes, but continue new development in 0.8 and so on. My thoughts exactly. Tags are fine for small things, but either branches or version-checking methods are the way to go for more advanced support. Thoughts on how best to manage extensions across multiple, possibly incompatible, versions of Radiant? The biggest problem as I see it is that many extensions are graciously released to the world for use, but that doesn't mean the author will be everyone's tech support. So they are released at version X and by the time version Y comes around many people are using it but the author is off doing something else (and not busy updating his/her extension). I think it would be nice if Radiant had some way to check for features that were added in different versions. An example being some extension that changes defaults in ResponseCache (which no longer exists in 0.8.0) and Radiant catching the undefined constant and reporting back an appropriate error or ... something. It would need to happen much like the move from Shards to the core, where extensions check admin.respond_to? :page Stats on version usage would be good too. It might be nice to have that infamous radiantcms.org/button.png image actually work in the filter reference, but be upgraded with each release so that we could track the number of referrers to radiantcms.org/button.0.8.0.png Who needs to worry about release 0.5.2 if nobody is using it. What's considered old? j Jim Gay http://www.saturnflyer.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
Josh French wrote ... > I've been tagging the extensions I'm involved with for compatibility at > versions 0.7.1 and 0.8.0, but I've also been wondering if it wouldn't be > better to maintain those via branches instead of tags -- have a 0.7 branch > to hold bugfixes, but continue new development in 0.8 and so on. > > Thoughts on how best to manage extensions across multiple, possibly > incompatible, versions of Radiant? My take on this is that it's best to keep separate branches. Following a consistent naming scheme for the branches would be a necessity for any sort of automated management, and would be a good idea in general. I have one extension that, due to the changes between Rails 2.1 (as used in Radiant 0.7.x) and Rails 2.3 (as used in Radiant 0.8), requires separate branches. Although I intend to only add new features for use in 0.8, I still need to be able to apply bug fixes and minor enhancements for 0.7.1. Tags just won't work in this case. The other extensions I've been working on follow the same pattern even though they probably could be merged into a single branch with runtime checks to deal with the differences between 0.7 and 0.8. However, since I don't intend to add any new functionality to the 0.7 branch, having separate branches does provide a good indication of the differences and will probably save me some future pain if I introduce a feature that works in 0.8 but not in 0.7. -- David Cato o...@crunchyfrog.net ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
On Jun 22, 2009, at 9:20 AM, Jeff Casimir wrote: Jim, Yeah, thanks for your work on "comments". The only thing I ran into off a checkout of Master that appeared to be a bug/missing feature was in the comments form where it uses the tag like "if_simple_spam_filter_enabled" or something -- Radiant complained that the tag was unknown. Given that you're working on that right now, I'm sure I just got a version that wasn't 100% ready. I like that simple spam protection, though, so I just removed the conditional and everything is great. That's my fault. David Cato did some great work on the spam filtering stuff, but I changed the tag name to fit in with other methods. I've fixed the repository now, but the problem was changing from if_comments_use_simple_spam_filter to if_comments_simple_spam_filter_enabled There will be more to come in this area. As far as the automation/testing plan, it would seem like a combination of EC2 + Chef would be an ideal setup. I have been interested in some of that automated setup technology, so if no one jumps on it by the time I hit summer vacation, I'll take a look. I'm also interested in working on more "narrative" documentation for Radiant. Right now there is a lot of great information, but some is in the wiki, some in github pages, some in the list archives, and there isn't necessarily a clear story. Probably within the wiki itself, it would be nice to walk a totally new user through the major processes, maybe even going beyond "novice" and starting them into extension customization/development. I'm a decent Rubyist and sys admin, and it took me some work to get everything going in the right direction. I'm sure there are a lot of normal users out that who would be good community-members if we can get them started. If anyone has thoughts on this, I'd love to hear them. - Jeff PS: Postgres? I knew you seemed like a smart guy. :) On Mon, Jun 22, 2009 at 8:44 AM, Jim Gay wrote: On Jun 21, 2009, at 7:30 PM, Jeff Casimir wrote: Jim, Wow, great info. I was actually fighting with "comments" among others for a few hours, but I'm sure I made it more work than necessary. Now everything is going great and I have a lot better understanding of how the extensions are managed and work. I'm maintaining comments so it's probably my fault. But let me know what you ran into, I made a few commits to the main repository that I shouldn't have pushed until I had the fixes in so you may have pulled it down in that window. Also, I'm integrating built-in spam filtering and other things, so the code is getting a lot of updates. It would be pretty awesome if some kind, free-time having soul were to implement "isitradiant.com" like "isitjruby.com". Especially with Radiant being at 0.8 and, at least from the version number, reserving the right to break compatibility at will, it would be awesome if there were a site that did nightly integration tests of all the extensions in the registry. It would be tougher to do "Radiant + Extension A + Extension B" combinations, but at least "Radiant + A" singles would be really useful information. I would personally love to see that. I've been meaning to contact the folks at http://runcoderun.com/ to see if they'd have a way to do it. The way I think we'll need to address it for now is to have people from the community help test. I, for example, use PostgreSQL so I try to make sure that the Radiant core will pass all of those tests, wheras others use MySQL or SQLite and test there. - Jeff On Sun, Jun 21, 2009 at 7:20 PM, Jim Gay wrote: On Jun 21, 2009, at 3:33 PM, Jeff Casimir wrote: Hi All, Is the expectation that unless the GitHub page specifically says that an extension works with 0.8, that it WON'T work? Maybe. It depends. Some extensions might not require an update. I've tried and failed to install a few extensions, and now there's so much non-working cruft that I'm thinking it'd be easier to start a new instance and transfer all my content then debug what's wrong with different rake tasks, migrations, etc. Different pages have different suggestions for installation process, is it "more preferred" to use: script/extension install extension_name or rake radiant:extensions:extension_name:install These are entirely different things. Using "script/extension install extension_name" will get information from the extension registry http://ext.radiantcms.org/, pull down the extension, run the migrate task, and run the update task. The command "rake radiant:extensions:extension_name:install" would just be some command to perform the "install" rake task (assuming it exists) in the extension "extension_name" To see what rake tasks your extensions provide, you may do "rake - T" from the root of the project. I've had better luck with the former, but many of the github pages suggest the latter. Using "script/extension" will pull down the information.
Re: Re: [Radiant] Extensions with 0.8
Not obvious, but Josh French has committed changes for the next release that will allow extension developers to configure dependencies from the extension which might help with the installation process as far as things like error messages go. There will be more development on this in the future. One thing that we don't have is a way of ensuring that the proper version of an extension is installed from the get-go. I'm in the arguably bad habit of manually installing everything, so I was unaware of some of the problems that occur when trying to install extensions via script/extension or ray. To wit, using an installer to install a 0.8-style extension will fail if your base Radiant install is 0.7 or earlier. Because the extension is checked out at its head, the environment fails and neither rake:migrate nor rake:update can be run until the extension is frozen to a compatible tag/version. This could be solved by adding a version argument to the install method, or by baking knowledge of the current Radiant version into the installer. I've been tagging the extensions I'm involved with for compatibility at versions 0.7.1 and 0.8.0, but I've also been wondering if it wouldn't be better to maintain those via branches instead of tags -- have a 0.7 branch to hold bugfixes, but continue new development in 0.8 and so on. Thoughts on how best to manage extensions across multiple, possibly incompatible, versions of Radiant? j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
Jim, Yeah, thanks for your work on "comments". The only thing I ran into off a checkout of Master that appeared to be a bug/missing feature was in the comments form where it uses the tag like "if_simple_spam_filter_enabled" or something -- Radiant complained that the tag was unknown. Given that you're working on that right now, I'm sure I just got a version that wasn't 100% ready. I like that simple spam protection, though, so I just removed the conditional and everything is great. As far as the automation/testing plan, it would seem like a combination of EC2 + Chef would be an ideal setup. I have been interested in some of that automated setup technology, so if no one jumps on it by the time I hit summer vacation, I'll take a look. I'm also interested in working on more "narrative" documentation for Radiant. Right now there is a lot of great information, but some is in the wiki, some in github pages, some in the list archives, and there isn't necessarily a clear story. Probably within the wiki itself, it would be nice to walk a totally new user through the major processes, maybe even going beyond "novice" and starting them into extension customization/development. I'm a decent Rubyist and sys admin, and it took me some work to get everything going in the right direction. I'm sure there are a lot of normal users out that who would be good community-members if we can get them started. If anyone has thoughts on this, I'd love to hear them. - Jeff PS: Postgres? I knew you seemed like a smart guy. :) On Mon, Jun 22, 2009 at 8:44 AM, Jim Gay wrote: > > On Jun 21, 2009, at 7:30 PM, Jeff Casimir wrote: > >> Jim, >> >> Wow, great info. I was actually fighting with "comments" among others >> for a few hours, but I'm sure I made it more work than necessary. Now >> everything is going great and I have a lot better understanding of how >> the extensions are managed and work. > > I'm maintaining comments so it's probably my fault. But let me know what you > ran into, I made a few commits to the main repository that I shouldn't have > pushed until I had the fixes in so you may have pulled it down in that > window. Also, I'm integrating built-in spam filtering and other things, so > the code is getting a lot of updates. > >> >> It would be pretty awesome if some kind, free-time having soul were to >> implement "isitradiant.com" like "isitjruby.com". Especially with >> Radiant being at 0.8 and, at least from the version number, reserving >> the right to break compatibility at will, it would be awesome if there >> were a site that did nightly integration tests of all the extensions >> in the registry. It would be tougher to do "Radiant + Extension A + >> Extension B" combinations, but at least "Radiant + A" singles would be >> really useful information. > > I would personally love to see that. I've been meaning to contact the folks > at http://runcoderun.com/ to see if they'd have a way to do it. > The way I think we'll need to address it for now is to have people from the > community help test. I, for example, use PostgreSQL so I try to make sure > that the Radiant core will pass all of those tests, wheras others use MySQL > or SQLite and test there. > >> >> - Jeff >> >> On Sun, Jun 21, 2009 at 7:20 PM, Jim Gay wrote: >>> >>> On Jun 21, 2009, at 3:33 PM, Jeff Casimir wrote: >>> Hi All, Is the expectation that unless the GitHub page specifically says that an extension works with 0.8, that it WON'T work? >>> >>> Maybe. It depends. Some extensions might not require an update. >>> I've tried and failed to install a few extensions, and now there's so much non-working cruft that I'm thinking it'd be easier to start a new instance and transfer all my content then debug what's wrong with different rake tasks, migrations, etc. Different pages have different suggestions for installation process, is it "more preferred" to use: script/extension install extension_name or rake radiant:extensions:extension_name:install >>> >>> These are entirely different things. >>> Using "script/extension install extension_name" will get information from >>> the extension registry http://ext.radiantcms.org/, pull down the >>> extension, >>> run the migrate task, and run the update task. >>> >>> The command "rake radiant:extensions:extension_name:install" would just >>> be >>> some command to perform the "install" rake task (assuming it exists) in >>> the >>> extension "extension_name" >>> >>> To see what rake tasks your extensions provide, you may do "rake -T" from >>> the root of the project. >>> I've had better luck with the former, but many of the github pages suggest the latter. >>> >>> Using "script/extension" will pull down the information. This is the same >>> as >>> a download, git clone, svn checkout, or whatever else. "script/extension >>> install" assumes the presence of "migrate" and "update" tasks for each >>> extension
Re: [Radiant] Extensions with 0.8
On Jun 21, 2009, at 7:30 PM, Jeff Casimir wrote: Jim, Wow, great info. I was actually fighting with "comments" among others for a few hours, but I'm sure I made it more work than necessary. Now everything is going great and I have a lot better understanding of how the extensions are managed and work. I'm maintaining comments so it's probably my fault. But let me know what you ran into, I made a few commits to the main repository that I shouldn't have pushed until I had the fixes in so you may have pulled it down in that window. Also, I'm integrating built-in spam filtering and other things, so the code is getting a lot of updates. It would be pretty awesome if some kind, free-time having soul were to implement "isitradiant.com" like "isitjruby.com". Especially with Radiant being at 0.8 and, at least from the version number, reserving the right to break compatibility at will, it would be awesome if there were a site that did nightly integration tests of all the extensions in the registry. It would be tougher to do "Radiant + Extension A + Extension B" combinations, but at least "Radiant + A" singles would be really useful information. I would personally love to see that. I've been meaning to contact the folks at http://runcoderun.com/ to see if they'd have a way to do it. The way I think we'll need to address it for now is to have people from the community help test. I, for example, use PostgreSQL so I try to make sure that the Radiant core will pass all of those tests, wheras others use MySQL or SQLite and test there. - Jeff On Sun, Jun 21, 2009 at 7:20 PM, Jim Gay wrote: On Jun 21, 2009, at 3:33 PM, Jeff Casimir wrote: Hi All, Is the expectation that unless the GitHub page specifically says that an extension works with 0.8, that it WON'T work? Maybe. It depends. Some extensions might not require an update. I've tried and failed to install a few extensions, and now there's so much non-working cruft that I'm thinking it'd be easier to start a new instance and transfer all my content then debug what's wrong with different rake tasks, migrations, etc. Different pages have different suggestions for installation process, is it "more preferred" to use: script/extension install extension_name or rake radiant:extensions:extension_name:install These are entirely different things. Using "script/extension install extension_name" will get information from the extension registry http://ext.radiantcms.org/, pull down the extension, run the migrate task, and run the update task. The command "rake radiant:extensions:extension_name:install" would just be some command to perform the "install" rake task (assuming it exists) in the extension "extension_name" To see what rake tasks your extensions provide, you may do "rake - T" from the root of the project. I've had better luck with the former, but many of the github pages suggest the latter. Using "script/extension" will pull down the information. This is the same as a download, git clone, svn checkout, or whatever else. "script/ extension install" assumes the presence of "migrate" and "update" tasks for each extension and runs them. If you were to use some other process for getting the code (download, git clone, etc) you'd still need to run whatever tasks are necessary to fully "install" the extension. Some extensions need a database migration, others need to put files in the public directory (the "update" rake task) and others need nothing. Help (http://ext.radiantcms.org/extensions/5-help), for example, was written to just be a drop-in extension (no migrate or update tasks) where you just put it in your project and start up the server. Dashboard (http://ext.radiantcms.org/extensions/40-dashboard) however requires an update task to be run but no migration. RBAC Base (http://ext.radiantcms.org/extensions/87-rbac-base) requires both migrate and update to be run. Apologies if I'm missing something obvious, Not obvious, but Josh French has committed changes for the next release that will allow extension developers to configure dependencies from the extension which might help with the installation process as far as things like error messages go. There will be more development on this in the future. And the Ray extension (http://ext.radiantcms.org/extensions/36-ray) has a way to manage dependencies from within an extension (as well as min/ max versions of Radiant), but I'm not sure how many take advantage of it. Jeff You might be able to get a lot of help by simply emailing the list with something like "I want to upgrade to Radiant 0.8.0 and I have extensions X, Y and Z. Are all of those extensions ready?" You're likely to get replies from the extension authors, or other users of those extensions who might know. So... what extensions do you have? I personally have many extensions which I wrote and manage and updating them is not my full-time j
Re: [Radiant] Extensions with 0.8
Jim, Wow, great info. I was actually fighting with "comments" among others for a few hours, but I'm sure I made it more work than necessary. Now everything is going great and I have a lot better understanding of how the extensions are managed and work. It would be pretty awesome if some kind, free-time having soul were to implement "isitradiant.com" like "isitjruby.com". Especially with Radiant being at 0.8 and, at least from the version number, reserving the right to break compatibility at will, it would be awesome if there were a site that did nightly integration tests of all the extensions in the registry. It would be tougher to do "Radiant + Extension A + Extension B" combinations, but at least "Radiant + A" singles would be really useful information. - Jeff On Sun, Jun 21, 2009 at 7:20 PM, Jim Gay wrote: > On Jun 21, 2009, at 3:33 PM, Jeff Casimir wrote: > >> Hi All, >> >> Is the expectation that unless the GitHub page specifically says that >> an extension works with 0.8, that it WON'T work? > > Maybe. It depends. Some extensions might not require an update. > >> I've tried and failed to install a few extensions, and now there's so >> much non-working cruft that I'm thinking it'd be easier to start a new >> instance and transfer all my content then debug what's wrong with >> different rake tasks, migrations, etc. >> >> Different pages have different suggestions for installation process, >> is it "more preferred" to use: >> >> script/extension install extension_name >> >> or >> >> rake radiant:extensions:extension_name:install > > These are entirely different things. > Using "script/extension install extension_name" will get information from > the extension registry http://ext.radiantcms.org/, pull down the extension, > run the migrate task, and run the update task. > > The command "rake radiant:extensions:extension_name:install" would just be > some command to perform the "install" rake task (assuming it exists) in the > extension "extension_name" > > To see what rake tasks your extensions provide, you may do "rake -T" from > the root of the project. > >> >> I've had better luck with the former, but many of the github pages >> suggest the latter. > > Using "script/extension" will pull down the information. This is the same as > a download, git clone, svn checkout, or whatever else. "script/extension > install" assumes the presence of "migrate" and "update" tasks for each > extension and runs them. > If you were to use some other process for getting the code (download, git > clone, etc) you'd still need to run whatever tasks are necessary to fully > "install" the extension. Some extensions need a database migration, others > need to put files in the public directory (the "update" rake task) and > others need nothing. > Help (http://ext.radiantcms.org/extensions/5-help), for example, was written > to just be a drop-in extension (no migrate or update tasks) where you just > put it in your project and start up the server. Dashboard > (http://ext.radiantcms.org/extensions/40-dashboard) however requires an > update task to be run but no migration. RBAC Base > (http://ext.radiantcms.org/extensions/87-rbac-base) requires both migrate > and update to be run. > >> >> Apologies if I'm missing something obvious, > > Not obvious, but Josh French has committed changes for the next release that > will allow extension developers to configure dependencies from the extension > which might help with the installation process as far as things like error > messages go. There will be more development on this in the future. > And the Ray extension (http://ext.radiantcms.org/extensions/36-ray) has a > way to manage dependencies from within an extension (as well as min/max > versions of Radiant), but I'm not sure how many take advantage of it. > >> Jeff > > You might be able to get a lot of help by simply emailing the list with > something like "I want to upgrade to Radiant 0.8.0 and I have extensions X, > Y and Z. Are all of those extensions ready?" > You're likely to get replies from the extension authors, or other users of > those extensions who might know. > > So... what extensions do you have? > > I personally have many extensions which I wrote and manage and updating them > is not my full-time job, so some may not work yet. If it's a simple fix and > I know somebody needs it, I'm happy to address the changes. > > This is a pretty helpful community, so just ask away. > > -Jim > > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant > ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Extensions with 0.8
On Jun 21, 2009, at 3:33 PM, Jeff Casimir wrote: Hi All, Is the expectation that unless the GitHub page specifically says that an extension works with 0.8, that it WON'T work? Maybe. It depends. Some extensions might not require an update. I've tried and failed to install a few extensions, and now there's so much non-working cruft that I'm thinking it'd be easier to start a new instance and transfer all my content then debug what's wrong with different rake tasks, migrations, etc. Different pages have different suggestions for installation process, is it "more preferred" to use: script/extension install extension_name or rake radiant:extensions:extension_name:install These are entirely different things. Using "script/extension install extension_name" will get information from the extension registry http://ext.radiantcms.org/, pull down the extension, run the migrate task, and run the update task. The command "rake radiant:extensions:extension_name:install" would just be some command to perform the "install" rake task (assuming it exists) in the extension "extension_name" To see what rake tasks your extensions provide, you may do "rake -T" from the root of the project. I've had better luck with the former, but many of the github pages suggest the latter. Using "script/extension" will pull down the information. This is the same as a download, git clone, svn checkout, or whatever else. "script/ extension install" assumes the presence of "migrate" and "update" tasks for each extension and runs them. If you were to use some other process for getting the code (download, git clone, etc) you'd still need to run whatever tasks are necessary to fully "install" the extension. Some extensions need a database migration, others need to put files in the public directory (the "update" rake task) and others need nothing. Help (http://ext.radiantcms.org/extensions/5-help), for example, was written to just be a drop-in extension (no migrate or update tasks) where you just put it in your project and start up the server. Dashboard (http://ext.radiantcms.org/extensions/40-dashboard) however requires an update task to be run but no migration. RBAC Base (http://ext.radiantcms.org/extensions/87-rbac-base ) requires both migrate and update to be run. Apologies if I'm missing something obvious, Not obvious, but Josh French has committed changes for the next release that will allow extension developers to configure dependencies from the extension which might help with the installation process as far as things like error messages go. There will be more development on this in the future. And the Ray extension (http://ext.radiantcms.org/extensions/36-ray) has a way to manage dependencies from within an extension (as well as min/max versions of Radiant), but I'm not sure how many take advantage of it. Jeff You might be able to get a lot of help by simply emailing the list with something like "I want to upgrade to Radiant 0.8.0 and I have extensions X, Y and Z. Are all of those extensions ready?" You're likely to get replies from the extension authors, or other users of those extensions who might know. So... what extensions do you have? I personally have many extensions which I wrote and manage and updating them is not my full-time job, so some may not work yet. If it's a simple fix and I know somebody needs it, I'm happy to address the changes. This is a pretty helpful community, so just ask away. -Jim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
RE: [Radiant] Extensions with 0.8
Jeff, I find that a combination of checking the last updated date stamp, with tags and text in most docs are the most reliable 'filters' for checking if stuff might work on .8. It would be helpful if Radiant utilizied something similar to the approach wordpress' plugin directory takes (ie http://wordpress.org/extend/plugins/intensedebate/ ) but for now there is no such solution that I'm aware of. > Date: Sun, 21 Jun 2009 15:33:12 -0400 > From: j...@casimircreative.com > To: radiant@radiantcms.org > Subject: [Radiant] Extensions with 0.8 > > Hi All, > > Is the expectation that unless the GitHub page specifically says that > an extension works with 0.8, that it WON'T work? > > I've tried and failed to install a few extensions, and now there's so > much non-working cruft that I'm thinking it'd be easier to start a new > instance and transfer all my content then debug what's wrong with > different rake tasks, migrations, etc. > > Different pages have different suggestions for installation process, > is it "more preferred" to use: > > script/extension install extension_name > > or > > rake radiant:extensions:extension_name:install > > I've had better luck with the former, but many of the github pages > suggest the latter. > > Apologies if I'm missing something obvious, > Jeff > ___ > Radiant mailing list > Post: Radiant@radiantcms.org > Search: http://radiantcms.org/mailing-list/search/ > Site: http://lists.radiantcms.org/mailman/listinfo/radiant _ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
