Talk Page for Our Blog
This page is a TalkPage so please feel free to edit/comment. For an explanation of the TalkPage concept please see TalkPageConcept
- We are planning to use WordPress for the blog (see below).
- We want to generate the Newsletter automatically from the Weblog and send it out whenever we have 5 new blog entries or once a month - depending on the volume/frequency of blog entries.
- We need to get people who keep a blog to blog about Foswiki
- Make a list of people who have already blogged about/wrote about Foswiki to write more blogs/articles
- We will need help with the WordPress-Templates from a programmer and a designer.
Why will we use WordPress as a solution?
- Better usability. It provides a lot of useful features for authors; faster results.
- Best of breed solution: WordPress is the one established solution for Weblogs.
- It has a huge amount of plugins for weblogs available already (see http://wordpress.org/extend/plugins/ - 3,249 plugins, 14,534,353 downloads, and counting). We do not need any developer program for new features. It is all there already.
- Best possible SEO optimization
- Automatic trackbacks
- Seemless Feedburner Integration
- Easy possibility to send out automatic newsletters also
- Support for Gravatars and higher likeliness of commenting
- Integration in technorati
- Full feed RSS subscriptions
- Existing knowledge for authors (like MartinSeibert) (cf. below; no advantage?)
- We can learn from WordPress for Foswiki also. (interested parties can use it in their own sandbox, then?)
- Insert your points here ...
Benefits of a pure Foswiki-Blogging solution
- Automatic sync of login credentials
- All-in-one-solution. Excellent way of demonstrating just how flexible Foswiki is.
- Don't need to waste time creating/editing a theme for Wordpress each time we want to update our site/logo
- Any features we really need could be done with a Foswiki plugin (i.e. Gravatars, if we want them, although Trackbacks and SEO optimization is not so easy)
- Using a competitor's product for a feature also provided by our product shows a bad practice, even if our feature will always be somewhat inferior (our focus is not providing the best blogging engine in the world). Further comments below
- Using an internal blog solution will encourage development of new internal features to make a better blog. Conversely, using an external solution will discourage internal development
- Existing knowledge for authors (we should all know how to use Foswiki...) (cf. above; no advantage?)
- Insert your points here ...
I would strongly urge to reconsider: eat our own dogfood and all. Also, the number of plugins for wordpress is inflated. As someone who has been maintaining wordpress sites for years, i can tell you that 99.999999% of the plugins are gaping security holes, performance killers and useless crap.
We should consider MichaelDaums
Foswiki blog contrib, it supports things like trackbacks and pingbacks iirc.
- 04 Nov 2008 - 15:49
Given the lofty claim in Foswiki's product announcement
of being the "next generation of enterprise collaboration suites", I believe using TWiki:Plugins/BlogPlugin
would be a good demonstration of using Foswiki for collaboration.
- 22 Nov 2008 - 17:02
I just want a quick, stable and reliable solution. If you guys want to provide one based on fOSWIKI. No problem. If I organize it, I would rely on the market leader. It is not the task of %WIKITOOLNAME% to compete with WordPress. Sure we offer internal blogging. But that is a different story.
- 04 Nov 2008 - 19:01
I second Martin on this. Though it'd also be cool to have some sort of an integration between Foswiki and Wordpress, just as how Sven did for Foswiki and Trac. Just an idea.
- 05 Nov 2008
I have added some more points to the benefits of using a Foswiki based solution after my comments on Tasks.Item1290
. Thought about removing some of the more "fuzzy" pro-Wordpress points so we can accurately compare the solutions but have left them for now (might be better done in another topic). I still think it would be better to use a Foswiki solution then to spend any time making a Wordpress theme or working out how to sync user names and passwords. The time would be better spent making the Foswiki solution better. I can volunteer some of my spare time for this.
However, for now it is good to see we have a blog, even if it is Wordpress based. I will try and generate some content in the next few weeks. Hopefully once we have more content we can advertise it more and generate more interest in Foswiki
- 31 Mar 2009
I'd be all over using Foswiki internal blogging, but I'm not part of marketing and as such will not complain too loudly. I added two internal Pros above. On the competitor setup, from the mailing list, I learned that Atlassian also has an internal blog offering, but does not use it in favor of Wordpress. That to me makes me think less of their product. Just because they're a substantial company and use an external solution doesn't mean that's the best option. It also could be a bit of an apples-to-oranges comparison as I'm not sure how "mature" their internal blogging really is, compared to our options. They have however tried to organize about catching up, and so could we by adding Task items for missing features. Related link: http://confluence.atlassian.com/display/DISC/How+can+I+create+a+blog+using+Confluence
I'd agree that a seamless integration might be the best option, and would indeed doubly prove the flexibility of Foswiki. Blog either internally or externally and both will sync up. That probably would take a good chunk of effort though, if even 100% possible.
On one puzzling note, what's up with the following two lines, one from above the Pros, and one itself a Pro?
- "We will need help with the Wordpress-Templates from a programmer and a designer."
- "We do not need any developer program for new features. It is all there already."
We need additional resources to use Wordpress, but we don't need additional resources for Wordpress?
- 27 Apr 2009
Different skills are required for the two options. No code development is required to make use of the features that WordPress already supports; for a Foswiki-based solution, new development may be required for blogging features that are desired but are not currently available. Web design skills may be required to improve the appearance of a WordPress-based blog (when Martin wrote that initially, there was just a plain default template; not sure if more design changes are planned). If it were desirable, for example, to make the blog look like a part of the Foswiki web site, then more work would be required to create an appropriate appearance.
- 29 Apr 2009
I agree that a specialized blog platform is normally the better way to do it. However, for a public wiki site I think an interesting alternative is to use an external comment platfform like http://disqus.com disqus
(the pionner), http://js-kit.com/ echo
(ex js-kit, innovative but now commercial - but cheap, $12/year), http://www.intensedebate.com/ intense debate
Interestingly these services were originally designed for ... Wordpress, as people were not satisfied with Wordpress handling of spam in comments.
- 21 Sep 2009
I took the liberty of enumerating and regrouping both list items which IMHO are connected/sort of redundant.
Personally, I'm also a huge fan of Michael's Blog-plugin and would like to see it (or an alternative solution which exists) expanded and put to the test here of all sites
("eat your own dogfood" argument). Given the number of voices in favour of a native Foswiki solution, maybe we should start forming a "native Blog-plugin" working group?
I'd like to shorten the above lists in order to see "genuine"/concrete benefits (cf. item "W-3": it's nice to have a bazillion of plugins, but which of them do we really use for our purposes that are not mentioned on the first list yet? Can we identify "must-haves" and "would-like-to-haves"?)
Could someone (Martin?) elaborate a bit on item "W-1" ("faster results")--what does this mean in practice?
- 21 Sep 2009
Its also worth pointing out that in HomepageRedesignTalks
is looking at changing the look of foswiki.org around the release of 1.1. That means that we will have to update the Wordpress theme as well, unless we move to a Foswiki-based solution.
So now would be a good time to revisit this argument, as some effort will be required what ever we decide to do.
- 21 Sep 2009
To me this is so no-brainer a decision. Foswiki can - and has already - been used for blogging. It is simple story telling and follow-up comments. Naturally we should use Foswiki to show the world how versatile Foswiki is. And any arguments for Wordpress are pointless. Naturally a tool made for blogging will always win over a general purpose tool like Foswiki.
There are several people that have made fantastic blog implementations that more than accomodate the needs we have.
My personal decision stands. I do not blog on Wordpress. I will not support the use of that tool. If the community decides this is what you do I cannot prevent it. But I will not use it myself. I will not post. I will not comment. And I will not accept anyone posting in my name either which happened once and creates a storm of emails of people that wanted me to change some language mistakes. Something I had not done myself and something they could have fixed themselves on a wiki.
- 21 Sep 2009
I don't get it. Why do we need to use Wordpress to set up a place for
comments?? Is the CommentPlugin
so bad that we can't even use foswiki for
comments and discussion? I say the developers of foswiki should be required
to use foswiki as the "official foswiki" blog, and not Wordpress. Why? I
want to see the comment facility IMPROVED and FIXED. Do I use it? No. I
can't use it on a public site, as it is designed only for private intranet
use. From my experience, people will not spend the time to register on the
site just to add a comment, there is no captcha to stop google spam robots
from registering, and thus, I have to approve each and every registered
user before they can continue and the process takes too long to complete.
But, I want to have a comment facility that works with foswiki on a public
site. This is a critical issue that should not be avoided.
'> Just a silly question: what is stopping you from implementing the
'> suggestions you make above??
'> FWIW, i agree with you that we should blog on our own platform, but
'> since no-one has time/motivation to set that up Martin went with
'> wordpress instead. Can you blame him for that?
'> Another thing, the crippled blog-like thing we had on twiki is something
'> we should avoid on foswiki. Most importantly, it does not have
I would move the "blog" off of Wordpress immediately, but I am attempting to be courteous to the group and get these discussed prior to taking the initiative to undo something that is already done. I would rather see the discussion on foswiki, I don't care how crippled it seems to be. I have suggested using the PublishPlugin
, which I have recently bug fixed (sorry, not quite submitted yet) to handle static landing pages if foswiki efficiency is too poor. But that is not the issue here.
It is not necessary to have everything fixed to meet the competition of Wordpress. A wiki is a differently animal, a better one, in my opinion, because the discussion can be refactored to get to the gist of the solution. Wordpress can't do that, so we don't have to do everything it does. Can I fix everything in one fell swoop? Sorry, I don't have the bandwidth to dedicate to foswiki, and if I did, I would not need the community at all and go off on my merry way. I will continue to assert that it is preferable to use foswiki, even without bouncebacks, etc. because 1) it keeps the data on our own platform, 2) encourages improvement to allow us to place it on a public website situation and ask for comments, and 3) any deficiencies can be fixed, to the benefit of any foswiki installation.
This action was taken of using Wordpress without a vote of the community and I would like to see it discussed and put to a vote. There is no technology roadblock to getting started, even though I know there are things to be fixed to improve foswiki for this application.
> THEREFORE, I move to use foswiki for the info placed in the "official foswiki blog", even if it is somewhat weak right now.
(Eventually, I want to migrate toward the capability that this foswiki-discuss email discussion rolled into foswiki too, with responses to the list placed into foswiki. Comments made to this list are being lost because there is no automatic mechanism to allow email content to be appended to a topic. )
- 21 Sep 2009
For discussion, the Wiki is definitely the best place to do it.
The blog is supposed to be our face to the world, where we can let people know whats going on in Foswiki. We should draw up a list of requirements and see what Foswiki can already handle. Anything it cannot, we should try and improve. I will volunteer some of my time for this.
So to start the requirements list, I would suggest the following are essential:
- RSS notifications (& email?)
At the moment I can only think of them three that are essential to a blog, but im sure there are others. There are other things such as SEO, pingbacks, etc, but they are not so important IMO.
Also, if we do move to a Foswiki based solution we should try and keep the URL for the RSS feed the same (probably by using Apache rewrite rules), so people do have to to update their feed readers.
- 21 Sep 2009
What if we hybridized our approach with something like http://wordpress.org/extend/plugins/sourcedfrom
We could setup an internal blog web for authors that would provide a source of content for the public facing blog. Thus our public face has the SEO and pingbacks and comment management facilities that WP brings to the table while our primary content can be generated and refined right here in Foswiki. If we really wanted to, we could also turn off comments and link back to the blog web for discussion as well.
- 21 Sep 2009
Or the other way round... I wrote WordPressPlugin
just to show its pretty trivial to publish to Wordpress.
- 21 Sep 2009
I've done a blog app on the wiki at work for several webs, using BlogAddOn
as a starting point.
- Convert to search type=query
- Comments in subweb so commenter group is different to author group
- Productised so I only maintain a central set of topics for all blogs
- Can include summary of N most recent posts from any other web
- Feature post toggle that includes the most recent "feature" post in full on the blog home
- Slightly improved filtering/sorting UI
- Basic support for TagMePlugin
- Slightly improved RSS feeds on topics/comments
- Switch edit/post elements on just for posters, smart redirects to make editing of comments and posts directly from summary view less painful
Despite all this, the no. 1 complaint from real users is the weakness in commenting. All other issues seem to be secondary to this.
So we've now got wordpress blogs for a couple of projects that wanted a nicer, more dynamic public face.
So I can't enable proper anon. comments until FW has a robust way of doing this securely. I'd be happy to continue chipping away at improving SafeWikiPlugin
to do this (filtering saves, adding a new security context that would allow WikiGuest
to create topics), but it's probably not something we can achieve rapidly.
After that, pingback and richer summaries that don't flatten hyperlinks are really needed.
- 22 Sep 2009
- 22 Sep 2009
These are the requirements for a blog solution that I mentioned in the mailing list :
- Automatic Chronological Ordering
- Automatic Chronological summarization (articles by day, each month)
- Automatic generation of a home page with a summary of the las N articles (if the article is too long).
- Searchs with readeable results
- Comments (anonymous and authenticated)
- Spam control for the comments (so people don't need to register to comment)
- optional Tagging, and search for tags.
- 23 Sep 2009
Just to put things in perspective: a quick glance through the blog articles of the past half year shows only 1 relevant pingback link. For our
blog I would rate this as a nice to have.
- 23 Sep 2009