From: <ja...@so...> - 2007-03-20 19:47:39
|
A while ago there was some discussion at length about the MinGW website. I ignored it mostly because it hinged on an argument between CVS and SVN. Where do we stand on the website? Do we simply need to update it? Are there updates already in the pipeline that simply need to be posted? Do we want it revamped? Sorry to bring up the topic again, but depending on what exactly needs to be done I might be willing to lend my efforts to the website. --Jason A. Craig |
From: techtonik <tec...@us...> - 2007-03-20 20:40:47
|
On 3/20/07, ja...@so... <ja...@so...> wrote: > A while ago there was some discussion at length about the MinGW website. I > ignored it mostly because it hinged on an argument between CVS and SVN. And IIRC something about total responsibility and editorship what drove the web site to the current state. > Where do we stand on the website? The main problem is that we need hosting. SF is insecure by design. I can offer my DreamHost plan, but it is unlikely that my offer will be accepted. There were also some talks about SourceWare hosting, so as a last resort we can use their facilities. > Do we simply need to update it? No. We need to setup a CMS for it and migrate content (the last thing is the one I could be able to help with). There was a very nice MediaWiki about MinGW somewhere, but the common opinion was to try Drupal. Its new version 5 looks very promising. The problem was that Drupal hadn't had wiki module and we've got a lot of wiki pages. > Are there updates already in the pipeline that simply need to be posted? > Do we want it revamped? Definitely. > Sorry to bring up the topic again, but depending on what > exactly needs to be done I might be willing to lend my efforts to the > website. Exactly: 1. Decide hosting options. 2. Install Drupal. 3. Tune Drupal. 4. Migrate content. 5. Tune Drupal even more, add a bits of design. -- --anatoly t. |
From: Julien L. <ju...@fa...> - 2007-03-21 15:25:51
|
techtonik wrote: > On 3/20/07, ja...@so... <ja...@so...> wrote: >> Do we simply need to update it? > > No. We need to setup a CMS for it and migrate content (...) Migrating the content without losing any relevant parts is a daunting task which requires the full attention of someone who has great amounts of time to spare on the task. The point I wish to make is that the sandbox I created (see below) took me a hell of an amount of time for less than 10% of migration. > There was a very nice MediaWiki about MinGW somewhere, Maybe you're talking about the MediaWiki sandbox I had created to propose the MediaWiki solution to Earnie. It's still available here: http://www.amanitamuscaria.org/MinGWiki/Main_Page Some relevant (read: almost complete, and pretty nice) pages: http://www.amanitamuscaria.org/MinGWiki/Packages http://www.amanitamuscaria.org/MinGWiki/Binutils (and it's 'building' counter-page) I'll just point out that MediaWiki had it's pros/cons, resumed partially by Earnie: Earnie Boyd wrote: > A wiki is nothing more than a CMS with a specific purpose. Drupal > without any additional coding is enough of a wiki to use it for one. > The choice of CMS will be ease of aggregation with the SF feeds. I couldn't agree more; but I believe that if it were possible to automate the creation of a wiki page every day from a SF feed, a MediaWiki would be at least as good a choice as another CMS such as Drupal. My judgment is also biased in favor of MediaWiki, since I barely tested Drupal. AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist. Julien |
From: Earnie B. <ea...@us...> - 2007-03-21 17:04:05
|
Quoting Julien Lecomte <ju...@fa...>: > techtonik wrote: >> On 3/20/07, ja...@so... <ja...@so...> wrote: >>> Do we simply need to update it? >> >> No. We need to setup a CMS for it and migrate content (...) > > Migrating the content without losing any relevant parts is a daunting Currently we have two pieces of content, the main site and the phpwiki data. My main concern at the moment is the main site. > task which requires the full attention of someone who has great amounts > of time to spare on the task. > The point I wish to make is that the sandbox I created (see below) took > me a hell of an amount of time for less than 10% of migration. > If I remember correctly what you had in your sand box included the wiki data. >> There was a very nice MediaWiki about MinGW somewhere, > > Maybe you're talking about the MediaWiki sandbox I had created to > propose the MediaWiki solution to Earnie. > It's still available here: > http://www.amanitamuscaria.org/MinGWiki/Main_Page > And the wiki data needs consideration. The work you did was nicely put together. There are nicities with both MediaWiki and Drupal. > Some relevant (read: almost complete, and pretty nice) pages: > http://www.amanitamuscaria.org/MinGWiki/Packages > http://www.amanitamuscaria.org/MinGWiki/Binutils > (and it's 'building' counter-page) > > I'll just point out that MediaWiki had it's pros/cons, resumed partially > by Earnie: > > Earnie Boyd wrote: >> A wiki is nothing more than a CMS with a specific purpose. Drupal >> without any additional coding is enough of a wiki to use it for one. >> The choice of CMS will be ease of aggregation with the SF feeds. > > I couldn't agree more; but I believe that if it were possible to > automate the creation of a wiki page every day from a SF feed, a > MediaWiki would be at least as good a choice as another CMS such as Drupal. I agree. > My judgment is also biased in favor of MediaWiki, since I barely tested > Drupal. And mine vice versa. > AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist. > This might be troublesome. What you have though may well be suited for formatting in Drupal. I'll have to dig in my email to find a link I tried to save where someone templated Drupal to work similar to MediaWiki. Earnie |
From: <ja...@so...> - 2007-03-20 21:45:22
|
techtonik writes: > > No. We need to setup a CMS for it and migrate content (the last thing > is the one I could be able to help with). There was a very nice > MediaWiki about MinGW somewhere, but the common opinion was to try > Drupal. Its new version 5 looks very promising. The problem was that > Drupal hadn't had wiki module and we've got a lot of wiki pages. > Is Drupal set in stone? I've worked on one and built another Plone site from the ground up recently and have become very comfortable with it, as well as a big fan. Zope (it's underlying 'engine' so to speak) has a ZWiki product. I haven't used the ZWiki product yet, but it looks good. I would be willing to set up and admin a Plone site. Drupal or any other CMS I would not be willing to invest the time to learn the system enough to admin it, but I would be willing to contribute to it. > Exactly: > 1. Decide hosting options. > 2. Install Drupal. > 3. Tune Drupal. > 4. Migrate content. > 5. Tune Drupal even more, add a bits of design. With Plone, one consideration is that it doesn't play too nice on a virtual private server, a dedicated server is best. --Jason A. Craig |
From: Earnie B. <ea...@us...> - 2007-03-21 11:42:52
|
Quoting ja...@so...: > techtonik writes: >> >> No. We need to setup a CMS for it and migrate content (the last thing >> is the one I could be able to help with). There was a very nice >> MediaWiki about MinGW somewhere, but the common opinion was to try >> Drupal. Its new version 5 looks very promising. The problem was that >> Drupal hadn't had wiki module and we've got a lot of wiki pages. >> > > Is Drupal set in stone? Absolutely NOT. > I've worked on one and built another Plone site I know this is a templating thing but the Plone.org site makes me run from it. > > With Plone, one consideration is that it doesn't play too nice on a virtual > private server, a dedicated server is best. Well that leaves it pretty much out in the dark and not a serious consideration. Actually, Joomla.org may be better suited for MinGW but I haven't given it any play time. The JoomlaCode.org GForge interface is strikely good. However, Drupal has its own strikingly good project interface that may work just as well. I may have some time May or June to implement a new web interface for MinGW using one of these; I am familiar with Drupal but it is all about data->process->data so I am open to other possibilities if given proof that it should work well for MinGW. Earnie |
From: Earnie B. <ea...@us...> - 2007-03-21 12:10:27
|
Quoting techtonik <tec...@us...>: > > The main problem is that we need hosting. We already have one. > SF is insecure by design. Not a concern! Do you plan to put your secure information on the MinGW website. > I can offer my DreamHost plan, but it is unlikely that my offer will be > accepted. There were also some talks about SourceWare hosting, so as a > last resort we can use their facilities. > Keith and I have both told you we were not using DreamHost. If we move MinGW it will be somewhere more like GForge which is built on older versions of SF code when SF code was Open. >> Do we simply need to update it? > > No. We need to setup a CMS for it and migrate content (the last thing > is the one I could be able to help with). There was a very nice > MediaWiki about MinGW somewhere, but the common opinion was to try > Drupal. Its new version 5 looks very promising. The problem was that > Drupal hadn't had wiki module and we've got a lot of wiki pages. > A wiki is nothing more than a CMS with a specific purpose. Drupal without any additional coding is enough of a wiki to use it for one. The choice of CMS will be ease of aggregation with the SF feeds. >> Are there updates already in the pipeline that simply need to be posted? >> Do we want it revamped? > > Definitely. > >> Sorry to bring up the topic again, but depending on what >> exactly needs to be done I might be willing to lend my efforts to the >> website. > > Exactly: > 1. Decide hosting options. The choice is currently SF. > 2. Install Drupal. Hopefully to be done by the end of June. > 3. Tune Drupal. This includes a template design. Drupal works best with phptemplate but can use smarty; I'm don't know what template engines Joomla supports. If someone wants to design a template for MinGW based on phptemplate using Drupal see http://drupal.org/node/509 for documentation from the http://drupal.org/handbooks section. > 4. Migrate content. Hopefully to be done by the end of June. > 5. Tune Drupal even more, add a bits of design. > Continuously ongoing. Earnie |
From: Earnie B. <ea...@us...> - 2007-03-21 12:17:45
|
Quoting ja...@so...: > Do we simply need to update it? If you're willing to update the data then please post patches to the patch tracker. > Are there updates already in the pipeline that simply need to be posted? There are no patches in the patch tracker against the htdocs code. The only change that hasn't been made to production is the CSS. > Do we want it revamped? I've already stated that I hope to revamp by the end of June. > Sorry to bring up the topic again, but depending on what > exactly needs to be done I might be willing to lend my efforts to the > website. > The sorriness that needs to be had is in lack of interest; please don't apologize for being interested. You can start by submitting patches to the patch tracker. If you wish access to the htdocs area you will need to send me your public ssh key (privately, please). Earnie |
From: <ja...@so...> - 2007-03-21 14:54:05
|
Earnie Boyd writes: >> >> I've worked on one and built another Plone site > > I know this is a templating thing but the Plone.org site makes me run from it. Are you scared of what plone looks like? Can you guess that http://aquamira.com is a plone site? > >> >> With Plone, one consideration is that it doesn't play too nice on a virtual >> private server, a dedicated server is best. > > Well that leaves it pretty much out in the dark and not a serious > consideration. Sorry, let me explain better. It USUALLY doesn't play well on a virtual private server because most virtual private servers don't let you install it/use it. If you have root access along with control over port configuration, then you can use Plone. --Jason A. Craig |
From: Earnie B. <ea...@us...> - 2007-03-21 16:40:04
|
Quoting ja...@so...: > Earnie Boyd writes: >>> >>> I've worked on one and built another Plone site >> >> I know this is a templating thing but the Plone.org site makes me >> run from it. > > Are you scared of what plone looks like? Can you guess that > http://aquamira.com is a plone site? > Not too hard to figure out <meta name="generator" content="Plone - http://plone.org" /> As I said, ``I know this is a templating thing ...''. The main Plone.org template turns me off. The site could have used Drupal just as easily. >> >>> >>> With Plone, one consideration is that it doesn't play too nice on a virtual >>> private server, a dedicated server is best. >> >> Well that leaves it pretty much out in the dark and not a serious >> consideration. > > Sorry, let me explain better. It USUALLY doesn't play well on a virtual > private server because most virtual private servers don't let you install > it/use it. If you have root access along with control over port > configuration, then you can use Plone. > No we do not have control of the port nor do we have root access. I have installed Drupal on another SF project. Earnie |
From: <ja...@so...> - 2007-03-21 17:04:07
|
Earnie Boyd writes: > > As I said, ``I know this is a templating thing ...''. The main > Plone.org template turns me off. The site could have used Drupal just > as easily. > Well I guess the misunderstanding is that I am turned off by people simply putting up a CMS without changing it's appearance at all (except maybe the logo). Then you have 5000 clones of Plone or Drupal or WikiMedia, and thus your site it boring. Yes you can do it with a host of different CMS's, and yes, it is a template thing. However, there is no reason in the world to keep the default template/appearance/stylesheets that come with your CMS of choice. My offer was (is) "I am willing to administrate a Plone based overhaul of mingw.org. I am not willing to invest time in learning how to set up and customize a different CMS. I will however contribute to those efforts." Take it or leave it. --Jason A. Craig |
From: Julien L. <ju...@fa...> - 2007-03-21 18:21:15
|
Earnie Boyd wrote: > Quoting Julien Lecomte <ju...@fa...>: > Currently we have two pieces of content, the main site and the phpwiki > data. My main concern at the moment is the main site. I was thinking about merging both since what is on the main site can be in a wiki. > If I remember correctly what you had in your sand box included the wiki data. Not much of it actually. I took some pages verbatim or wikified them. >> I'll just point out that MediaWiki had it's pros/cons. (...) >> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist. > This might be troublesome. I've just solved the problem of auto-import of the latest releases/news from sourceforge.net A brief reminder of the problem: the blue 'news box' on the main page was edited by hand and would require an user to update the page when a new release is done. I've just solved this problem by hacking the mediawiki '<iframe>' extension to include via php's 'fopen' http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct latest news and releases. Maybe, after all, MediaWiki might be a good choice. Julien |
From: techtonik <tec...@us...> - 2007-03-24 12:55:21
|
On 3/21/07, Julien Lecomte <ju...@fa...> wrote: > >> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist. > > This might be troublesome. > > I've just solved the problem of auto-import of the latest releases/news > from sourceforge.net I should have read this mail before hacking into MediaWiki. =) > I've just solved this problem by hacking the mediawiki '<iframe>' > extension to include via php's 'fopen' > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 > > http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct > latest news and releases. > Does that mean every time you access the main page a request to SF is made? Do you cache it? This seems to be a better way to get the contents from SF in current form. My extension is more complex - it is a rip-off from another news aggregator of mine stripped down to handle only SF feeds. That's why extra database and synchronization layers. -- --anatoly t. |
From: techtonik <tec...@us...> - 2007-03-21 20:07:27
|
On 3/21/07, Earnie Boyd <ea...@us...> wrote: > > The main problem is that we need hosting. > > We already have one. > > > SF is insecure by design. > > Not a concern! Do you plan to put your secure information on the MinGW > website. There was a story with PHP XML-RPC library two years ago that affected all major open-source PHP products. There were even rumors about developer's accounts information stolen from Mozilla through this bug. The guys who maintained this library were warned like you, but there too stubborn to separate emotions from rationale. Do you want that story to be repeated? If you do not trust me then point any database driven project on SourceForge to see your name on its main page. > > I can offer my DreamHost plan, but it is unlikely that my offer will be > > accepted. There were also some talks about SourceWare hosting, so as a > > last resort we can use their facilities. > > > > Keith and I have both told you we were not using DreamHost. If we move > MinGW it will be somewhere more like GForge which is built on older > versions of SF code when SF code was Open. I know you've told me - that's why I am telling it to others. As for SF interface I do not think it rocks. In addition I always thought that GForge is slow. There are many superior project management interfaces like Trac. > A wiki is nothing more than a CMS with a specific purpose. Drupal > without any additional coding is enough of a wiki to use it for one. > The choice of CMS will be ease of aggregation with the SF feeds. Aggregation is the most easy part for any framework if information supplied in RSS or any other well-described format. Even for MediaWiki if you give me a skeleton plugin to do by example. But here is one limitation of SF I almost forgot about - SF doesn't allow outgoing connections. So there are good chances that you won't be able to import desired content at all. > > Exactly: > > 1. Decide hosting options. > > The choice is currently SF. > > > 2. Install Drupal. > > Hopefully to be done by the end of June. > > > 3. Tune Drupal. > > This includes a template design. Drupal works best with phptemplate > but can use smarty; I'm don't know what template engines Joomla > supports. If someone wants to design a template for MinGW based on > phptemplate using Drupal see http://drupal.org/node/509 for > documentation from the http://drupal.org/handbooks section. At least provide plain 800x600 image of design. As for Plone - I really like the idea of designing something over a top of application server - it can greatly reduce the amount of time wasted, but running appserver such as Zope indeed requires more resources than a typical shared hosting can provide for non-commercial project. -- --anatoly t. |
From: <ja...@so...> - 2007-03-21 21:12:27
|
Earnie Boyd writes: >> 3. Tune Drupal. > > This includes a template design. Drupal works best with phptemplate > but can use smarty; I'm don't know what template engines Joomla > supports. If someone wants to design a template for MinGW based on > phptemplate using Drupal see http://drupal.org/node/509 for > documentation from the http://drupal.org/handbooks section. Well since Drupal is the choice, perhaps I will get started on templates. Are there any requirements for the design? Is there a pre-existing comp for a design? Should the design be like the current site? --Jason A. Craig |
From: Earnie B. <ea...@us...> - 2007-03-22 11:22:00
|
Quoting ja...@so...: > Earnie Boyd writes: > >>> 3. Tune Drupal. >> >> This includes a template design. Drupal works best with phptemplate >> but can use smarty; I'm don't know what template engines Joomla >> supports. If someone wants to design a template for MinGW based on >> phptemplate using Drupal see http://drupal.org/node/509 for >> documentation from the http://drupal.org/handbooks section. > > Well since Drupal is the choice, perhaps I will get started on templates. > Are there any requirements for the design? Is there a pre-existing comp for > a design? Should the design be like the current site? > The design of the site we have now is simplistic because I DNKWIWD. I do not care if you apply some artistic ability to the template. The main goal is ease of navigation and interaction between SF and any other third party package we may interoperate with. There are modules that allow a different template for different pages and/or functions. In Drupal core with version 5.0 and above you can apply a separate template for administration UI than for the site UI. We could even enable more than one template and let the authenticated visitor choose which template she desires. Earnie |
From: Earnie B. <ea...@us...> - 2007-03-22 11:34:46
|
Quoting techtonik <tec...@us...>: > > If you do not trust me then point any database driven project on > SourceForge to see your name on its main page. > http://www.google.com/search?hl=en&q=techtonik&btnG=Google+Search You see, I am not concerned with my name being used by others because I used the SF site. I do not store personally liable information on a public interface. It has nothing to do with trusting you, it has to do with trusting that 100s of 1000s of projects are using SF for its infrastructure. It is therefore not a concern. Earnie |
From: Earnie B. <ea...@us...> - 2007-03-22 11:53:40
|
Quoting Julien Lecomte <ju...@fa...>: > Earnie Boyd wrote: >> Quoting Julien Lecomte <ju...@fa...>: >> Currently we have two pieces of content, the main site and the phpwiki >> data. My main concern at the moment is the main site. > > I was thinking about merging both since what is on the main site can be > in a wiki. > Eventually over a length of time, maybe. >> If I remember correctly what you had in your sand box included the >> wiki data. > Not much of it actually. I took some pages verbatim or wikified them. > >>> I'll just point out that MediaWiki had it's pros/cons. (...) >>> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist. >> This might be troublesome. > > I've just solved the problem of auto-import of the latest releases/news > from sourceforge.net > A brief reminder of the problem: the blue 'news box' on the main page > was edited by hand and would require an user to update the page when a > new release is done. > > I've just solved this problem by hacking the mediawiki '<iframe>' > extension to include via php's 'fopen' > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 > Is this screen scrape method so that if SF changes its HTML UI you would need to change the data pieces? Not interested in that. You could use the RSS feed and use the XML data. Yes I know SF can change the layout of the XML. > http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct > latest news and releases. > > Maybe, after all, MediaWiki might be a good choice. I will admit that your three column template looks good. It is too bad that there isn't more control on the template overall. We can offer the user a choice of template to view the data with Drupal. In my opinion a wiki look for the front landing page cheapens the impression of a project unless you're actually the one producing the wiki or your name is wikipedia. Earnie |
From: <ja...@so...> - 2007-03-22 16:36:20
|
Earnie Boyd writes: >> Earnie Boyd wrote: > > Is this screen scrape method so that if SF changes its HTML UI you > would need to change the data pieces? Not interested in that. You > could use the RSS feed and use the XML data. Yes I know SF can change > the layout of the XML. > Agreed. It would be fairly easy to create an XSLT stylesheet and simply transform the RSS data into inline HTML with PHP, so it shouldn't too hard to get a fairly maintainable method of displaying live sourceforge data. I've done this before in PHP. > In my > opinion a wiki look for the front landing page cheapens the impression > of a project unless you're actually the one producing the wiki or your > name is wikipedia. > Agree 100%. --Jason A. Craig |
From: Julien L. <ju...@fa...> - 2007-03-22 16:38:32
|
Earnie Boyd wrote: > Quoting Julien Lecomte <ju...@fa...>: >> Earnie Boyd wrote: >>> Quoting Julien Lecomte <ju...@fa...>: >>> Currently we have two pieces of content, the main site and the phpwiki >>> data. My main concern at the moment is the main site. >> I was thinking about merging both since what is on the main site can be >> in a wiki. > Eventually over a length of time, maybe. The data on the main site is the easiest to replicate, there's more work to be done when replicating the phpwiki. >>>> I'll just point out that MediaWiki had it's pros/cons. (...) >>>> AFAIK, I don't believe a MediaWiki plugin for auto-importing feeds exist. >>> This might be troublesome. >> I've just solved the problem of auto-import of the latest releases/news >> from sourceforge.net >> A brief reminder of the problem: the blue 'news box' on the main page >> was edited by hand and would require an user to update the page when a >> new release is done. >> >> I've just solved this problem by hacking the mediawiki '<iframe>' >> extension to include via php's 'fopen' >> http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 > > Is this screen scrape method so that if SF changes its HTML UI you > would need to change the data pieces? Not interested in that. You > could use the RSS feed and use the XML data. Yes I know SF can change > the layout of the XML. I just download the page and include it verbatim since my host allows cross-site http inclusion which is by default unsafe and probably disallowed on SF. On SF I was thinking we could fcron a wget on the url, and then include the local copy of it; much simpler than 'news-update.sh' on the shell server. We could parse a RSS or an XML feed and create a page for inclusion if we wish to. It would, in any case, work just like it currently works on mingw.org. In any case, if SF wishes to change something, they'll change it without telling us before hand, and change it to something that breaks the most things possible. >> http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct >> latest news and releases. >> >> Maybe, after all, MediaWiki might be a good choice. > > I will admit that your three column template looks good. The credit really goes out to gpwiki.org. > It is too bad > that there isn't more control on the template overall. We can offer > the user a choice of template to view the data with Drupal. In my > opinion a wiki look for the front landing page cheapens the impression > of a project unless you're actually the one producing the wiki or your > name is wikipedia. Some talented users have created skins for their own projects. Some of these projects don't look at all like a Wikipedia. Some examples are listed on this page: http://meta.wikimedia.org/wiki/Gallery_of_user_styles I've tried your DNKWIWD method to try to make a skin for the MinGWiki sandbox. It "kinda" looks like www.mingw.org now (but with some css bugs) Julien |
From: techtonik <tec...@us...> - 2007-03-24 13:06:58
|
On 3/22/07, Earnie Boyd <ea...@us...> wrote: > > If you do not trust me then point any database driven project on > > SourceForge to see your name on its main page. > > > I do not store personally liable information on a > public interface. It has nothing to do with trusting you, it has to do > with trusting that 100s of 1000s of projects are using SF for its > infrastructure. It is therefore not a concern. I see. You do not care if somebody stoles information about MinGW users including email addresses and passwords hashes. But how about changing their passwords and acting from your name, injecting malicious code into MinGW site content without any history traces? Do you care? -- --anatoly t. |
From: techtonik <tec...@us...> - 2007-03-24 16:47:05
|
> > > > I've just solved this problem by hacking the mediawiki '<iframe>' > > extension to include via php's 'fopen' > > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 > > > > Is this screen scrape method so that if SF changes its HTML UI you > would need to change the data pieces? Not interested in that. You > could use the RSS feed and use the XML data. Yes I know SF can change > the layout of the XML. If SF changes anything there will be a mess in either case. This is an official HTML export interface and SF is aware of the fact that it is should not be broken, because many rely on its current format. > > http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct > > latest news and releases. > > > > Maybe, after all, MediaWiki might be a good choice. > > I will admit that your three column template looks good. It is too bad > that there isn't more control on the template overall. We can offer > the user a choice of template to view the data with Drupal. In my > opinion a wiki look for the front landing page cheapens the impression > of a project unless you're actually the one producing the wiki or your > name is wikipedia. Any default template cheapens the impression of the project be it Drupal or MediaWiki. I am not afraid to repeat that so far (IMHO) even the default cheap look of WikiMedia is much more pleasant than current mingw.org "design". Tuned WikiMedia will be just great. -- --anatoly t. |
From: <ja...@so...> - 2007-03-25 00:15:46
|
techtonik writes: >> > >> > I've just solved this problem by hacking the mediawiki '<iframe>' >> > extension to include via php's 'fopen' >> > http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 >> > >> >> Is this screen scrape method so that if SF changes its HTML UI you >> would need to change the data pieces? Not interested in that. You >> could use the RSS feed and use the XML data. Yes I know SF can change >> the layout of the XML. > > If SF changes anything there will be a mess in either case. This is an > official HTML export interface and SF is aware of the fact that it is > should not be broken, because many rely on its current format. > I've created an XSL stylesheet that will transform the RSS data into the current format of title, date, and link. If (when) Drupal is implemented, the "news" or "releases" area can use PHP's XML and XSL functions to transform the feed and it will then be styled by the CSS stylesheets in place for the site. The only way that this can break is if Sourceforge changes the location of the RSS feed, or breaks from the RSS specification and publishes the feeds in a different format. I've also installed a copy of Drupal locally and I've begun to create a proposal for a PHPTemplate skin or theme for the MinGW site. I implemented a live feed of the project news in the template. --Jason A. Craig |
From: techtonik <tec...@us...> - 2007-03-25 07:05:05
|
On 3/25/07, ja...@so... <ja...@so...> wrote: > > > > If SF changes anything there will be a mess in either case. This is an > > official HTML export interface and SF is aware of the fact that it is > > should not be broken, because many rely on its current format. > > > > I've created an XSL stylesheet that will transform the RSS data into the > current format of title, date, and link. If (when) Drupal is implemented, > the "news" or "releases" area can use PHP's XML and XSL functions to > transform the feed and it will then be styled by the CSS stylesheets in > place for the site. The only way that this can break is if Sourceforge > changes the location of the RSS feed, or breaks from the RSS specification > and publishes the feeds in a different format. I do not think that happens. In any case it is not a problem to convert RSS to Atom and vice versa. > I've also installed a copy of Drupal locally and I've begun to create a > proposal for a PHPTemplate skin or theme for the MinGW site. I implemented > a live feed of the project news in the template. Good! I am still interested to see how it works. I still have no idea how to update Drupal or import information from wiki. -- --anatoly t. |
From: Julien L. <ju...@fa...> - 2007-03-25 11:42:37
|
On 24/03/2007 13:52, techtonik wrote: > On 3/21/07, Julien Lecomte <ju...@fa...> wrote: > >> I've just solved the problem of auto-import of the latest releases/news >> from sourceforge.net > >> I've just solved this problem by hacking the mediawiki '<iframe>' >> extension to include via php's 'fopen' >> http://sourceforge.net/export/projnews.php?group_id=2435&limit=10&flat=0 >> >> http://www.amanitamuscaria.org/MinGWiki/Main_Page now has the correct >> latest news and releases. > > Does that mean every time you access the main page a request to SF is > made? Yes > Do you cache it? No That page is sandbox, a test/sample website for my proposal. I don't care for performance since it's not meant for production. > This seems to be a better way to get the contents from SF in current > form. My extension is more complex - it is a rip-off from another news > aggregator of mine stripped down to handle only SF feeds. That's why > extra database and synchronization layers. I've looked at it, and it's overkill. My current plugin is less than 5 lines in php, doesn't require DB changes or connection, etc... You also gave just sourcecode, no example, no sample website to show that it works. My current sandbox method will not work as-is on SF because of SF limitation my current host does not enforce. This limitation will also block your script: On SF, we'll have to use the current cron/wget method which means that the page will only be downloaded every hour (cache problem solved.) Julien |