Now that glFusion v1.0 has hit the streets, it is time to plan the next release. There are a few things we need to agree upon and then those that want to contribute need to get their plans finalized.

Tentative Schedule

Sept. 7, 2008 - Code Freeze
Sept 8 - 30, 2008 - Beta / Release Candidates / Testing
Oct 1, 2008 - Release

This gives us almost 3 months of development for the next set of features.

Proposed Features

Here is what I think I can commit to for the next release:

Site Tailor Enhancements
- Ability to create block menus
- Add more menu styles
- Make it theme aware
- Implementing whatever ideas Eric comes up with for me

Plugin Developer Tools / Documentation
- Develop a new universal plugin for glFusion to be used as a skeleton for future plugin development
- Start the developer's wiki - document APIs, etc.

Search Results Enhancements
This one may be a long shot....but I want to do a little proof of concept here.. I realize there is a GSoC project looking at completely reworking the search system. My goal is to simply present the current search results in a little better format.

There were some other good ideas discussed privately, now is the time to expose those to the world and let's get some discussions going.

Since this will be our first release where there is a clock ticking, try to keep in mind what time you will have to devote to development and plan accordingly. Remember, we don't have to do it all at once, the wonderful thing about a 3 to 4 month release cycle is we can make small incremental enhancements along the way...

For the whole glLabs community, what do you want to see? What features and functions would improve glFusion for the masses? Now is the time to float out some ideas....

Thanks!
mark

Quote by: Mark

Plugin Developer Tools / Documentation
- Develop a new universal plugin for glFusion to be used as a skeleton for future plugin development
- Start the developer's wiki - document APIs, etc.

This MUST wait until the gllabs plugin is integrated with fusion. There are already some best practices in the wiki for the gllabsplugin that would have to exist in the universal plugin and I have a few more that I've got in calendar already. (Not that calendar is a fusion plugin....)

Such a plugin should use the lib-install, lib-scrub and lib-htmlhead stuff by default for example.

In the next release, I would like to see Joe's Tags plugin integrated, the new Calendar plugin (Joe, what can we do here to help you clean it off your plate?), and the lib-content.php (homepage replacement) plugin (even in a rough form).

Site Tailor - I would like to see an expansion on the custom template idea, making it into an online editor, etc. (part of Site Tailor). Maybe a tree listing of available templates in the theme, and then another tree list of the custom templates in the custom folder.

Site Tailor - You'll notice that I consolidated all the colors down to about 20 for the entire Nouveau theme, and placed them in style-colors.css. The intent here is to integrate them into an online colorpicker (like the menu, which was our prototype for this expanded functionality). Then, we replace the colors with tags pulling values from the database. This way, if someone wanted to override it, it would be easy (just add !important to the declaration in the regular style.css file). Also, if they wanted to use the tags in their own theme and hook into Site Tailor's functionality, they could.

Site Tailor - Similar dynamic ability to online customize the fixed/fluid state of the layout, the width of the fixed layout, width of blocks, etc. All driven by adjustable database values.

Overall, I have some ideas for adding some business style themes, but I don't want to work on other themes without first having a solid foundation for customizations via tags with Site Tailor.

I still am interested in leveraging the power/flexibility of the CTL in having Nouveau act as a base theme, and then other themes build upon it, only having templates in their layout folder that differ from those in Nouveau's folder. My question though is how will this interact/conflict with the custom_templates sub-folder functionality in each theme's layout folder? I know we're slowing things down a bit by saying "whatever theme is active, look here for custom templates first (layout/mytheme/custom_templates/), then look in the normal directory (layout/mytheme/), then fall back and look in layout/nouveau/custom_templates/ and then finally look in layout/nouveau/.

It seems like we are trying to address 2 separate issues. The custom_templates sub-directory addresses changes made to the base shipping theme, so that upon upgrade those changes won't be overridden. Very valuable. Pulling base templates from a standard directory addresses the need of theme devs to modify less files, it also addresses redundant files/images on the webserver, and plays into the notion of files not touched don't need to be upgraded as well. Also valuable.

I envision ultimately wrapping some of the functionality of vThemes into Site Tailor, much like Chameleon is being integrated into Site Tailor. Mark and I have pretty much decided that Site Tailor will be a replacement for Chameleon, and we probably won't work on it much other than perhaps updating Chameleon for standalone v1.5 use. Personally, my interest lies in creating tools that can be leveraged across multiple themes (Site Tailor's goal) with just the inclusion of certain tags in the theme's .thtml files. This is why I want to get Site Tailor in shape before working on any new themes (which I totally want to do and include with glFusion, more business-like themes, etc.) Perhaps these custom_templates sub-folders could act as their own independent themes, and be listed as an option in what I'll describe below:

Anyway, back to the vThemes integration. I envision Site Tailor having a Themes tab that lists all the available themes and a thumbnail and meta info (ala the theme thumbnail/image/theme.ini files) for each one, and a checkbox to select the active site theme. (Should be easy since the theme variable is now stored in the db. Note that this doesn't need to be in lieu of the theme chooser in the Geeklog config screen, just write to the same db cell.)

From Joe in a post elsewhere:

I would love to themes get into the database like plugins. Get rid of all the code that does an opendir/readdir to get lists of themes and apply full GL permissions to themes. This would allow admins to test out themes without worrying if users will notice them. Themes could be tweaked without worrying about users seeing the incomplete theme. Then you change the perms to enable to theme for general use. Backward compatibility with GL could be maintained by putting the functions that manage this stuff into a version.php file instead of the standard functions.php.
...
When Fusion detects a new theme has been installed that does not have all the custom/ directories, should Fusion automatically generate those directories? The check custom first processing is not part of Nouveau (or doesn't have to be), it's part of glFusion so should glF support it in all themes?

I totally agree. Then we could also leverage an "install" and "uninstall" option, and force a check for the proper version of core that the theme is compatible with, etc. Ultimately, I would like to see the ability to upload mynewtheme.zip or mynewtheme.tar.gz, and have the server unzip it into the proper directory automatically.

I know all this is a lot to chew on, so I am probably going to focus on the site colorpicker functionality, and perhaps one additional theme, if we can get the stuff mentioned above going.

...and whatever ideas I come up with to make Mark's life miserable! :wink:


To the community at large, please sound off with what you feel to be important. We want to make sure you are driving this discussion!

Thx!

Eric

Just a few more thoughts on the lib-content plugin...

The value I see here (and I know I am short-sighted in this Joe :wink is the ability (if one wants) to move away from the blog format dominating the front page. I know Trinity has talked about moving the Stories into its own true plugin, and I think this compliments that.

This would open up the potential uses and install base of glFusion to a much wider audience.

As far as branding goes, we need to think of a catchier name than the lib-content plugin. Joe, perhaps you can re-cap for us your vision for this, and in doing so we can come up with some market-speak.

Thx!

Eric

Quote by: Geiss

As far as branding goes, we need to think of a catchier name than the lib-content plugin. Joe, perhaps you can re-cap for us your vision for this, and in doing so we can come up with some market-speak.

As it's own plugin, I would call it the layout plugin. The original goal was to replace public_html/index.php, blocks and staticpages with dynamic layouts. Layouts would have full permissions, user customization, and seemless integration with plugin pages (somehow). Now the idea remains full permissions and user customization but instead of replacing blocks and staticpages, it now leverages them to store the content. Originally, in my pre-CSS-savvy concept, layouts were just spans of divs. But now I'd like it to integrate with the YUI library and YUI layout builder.

Simple, right?

Calling it the Layout plugin makes sense, but gets confusing since we deal with a layout directory and the concept of themes...

Perhaps this could be rolled into Site Tailor as a Homepage Layout tab? Or since we have Menu Builder, we could also have Layout Builder? I know the functionality can extend beyond just the homepage, but this would be a great place to start. It seems to fall under the general category of customizations to a site. I think it would make a nice addition.

I totally am stoked about integrating it with the YUI grid stuff! I'm all over a nice GUI for the stuff that we did recently on the homepage.

All this won't be simple, but we'll make it look simple! :cool:

Now, what can I do to help get Calendar done? I've got some nice icons to liven things up! Anything else I can do? I admit my motives are selfish, as I want your talents put to use on this groovy stuff!

Thx!

Eric

Perhaps this could be rolled into Site Tailor as a Homepage Layout tab? Or since we have Menu Builder, we could also have Layout Builder? I know the functionality can extend beyond just the homepage, but this would be a great place to start. It seems to fall under the general category of customizations to a site. I think it would make a nice addition. Very Happy

I second this idea. it would sure simplify things.

-Trinity

As far as separating the story stuff into a plugin I can begin this rather soon, but I am not sure if I can get it done and perfect in under 3 months. We should schedule this one for the next quarterly release perhaps unless of course we get lucky and it all falls into place.

-Trinity

Is the plan to make a new content (or story) plugin while leaving the existing story code in Geeklog or is this code being pulled out?

Quote by: Laugh

Is the plan to make a new content (or story) plugin while leaving the existing story code in Geeklog or is this code being pulled out?

Well its sorta a catch 22. Ether way you have to hack core. Yes it would be a plugin. but it will be derived from core based code and require the old code to go bie bie .. I would rather do this change in Geeklog core its self. though I would have to convince dirk to add it. The main reason is it substantially changes a lot of code placement as well as the way some things work. I have a feeling this might need to wait on the back burner, but if we cant get dirk to go with it it might bring up a discussion on ( i am afraid to say it ) forking unless we are willing put up with some mad code syncing issues. This all depends a lot on how much we want this functionality. To be honest i really want it and i am sure there are others, but at the same time i don't want to abandon Geeklogs projects resources and source tree quite yet. I leave this decision to the group. Yes i can make a plugin that stand alone and doesn't remove cores code. but you would still see the old stuff in the admin sections and it would be confusing to end users as well as having duplicate code all over the place

- Trinity

I just spoke with Wayne (suprsidr) and he has graciously allowed us to include his http://flashyourweb.com theme with glFusion.

Two words: I'm stoked! :cool:

Thanks so much Wayne!

-Eric

There was talk of how to do this on the Geeklog mailing list and the advice there was sound. Write the plugin as a completely independent plugin (call it article or storie, not story). Then once you have the plugin working exactly the same way as the stories do now, empty the story table and there should be little different between a site using the built in stories and a site running the article plugin. At that point, you can start excising story from core. (You did write a conversion utility, right? Both directions?) And then at this point, you can start improving the article plugin.

Personally, I'd prefer a "content" plugin first. It's in my crazy ideas. Then the article plugin just uses the content plugin for storage. As you move plugins into the content plugin, the faster customized search becomes -- all the big data is in one place. But don't wait for my crazy idea to exist before attempting your own insanity.

Quote by: trinity

Quote by: Laugh

Is the plan to make a new content (or story) plugin while leaving the existing story code in Geeklog or is this code being pulled out?

Well its sorta a catch 22. Ether way you have to hack core. Yes it would be a plugin. but it will be derived from core based code and require the old code to go bie bie .. I would rather do this change in Geeklog core its self. though I would have to convince dirk to add it. The main reason is it substantially changes a lot of code placement as well as the way some things work. I have a feeling this might need to wait on the back burner, but if we cant get dirk to go with it it might bring up a discussion on ( i am afraid to say it ) forking unless we are willing put up with some mad code syncing issues. This all depends a lot on how much we want this functionality. To be honest i really want it and i am sure there are others, but at the same time i don't want to abandon Geeklogs projects resources and source tree quite yet. I leave this decision to the group. Yes i can make a plugin that stand alone and doesn't remove cores code. but you would still see the old stuff in the admin sections and it would be confusing to end users as well as having duplicate code all over the place

- Trinity

My concerns on the issue exactly. I like what Joe mentioned regarding having both options available.I would really hate to see gl Fusion abandon Geeklog.

For future ideas, I know this has been mentioned before but if the story or content plugin gets written I think a universal categories plugin should be written as well that stories could use (instead of topics) and any other plugin could draw on if needed (links, menus, polls, etc..).

Sounds like some good discussions on features. There is one more thing I would like to see:

Those of you who plan on doing the coding, let's start getting some details out and commitments made. If there is something you want to do that can't fit the next release, no problem, there will be many more, but now is the time to start making hard plans on what you want to do.

I'm writing up a proposal for some Site Tailor enhancements that I will publish in a different thread later this weekend.

Thanks!
Mark

Quote by: Laugh

For future ideas, I know this has been mentioned before but if the story or content plugin gets written I think a universal categories plugin should be written as well that stories could use (instead of topics) and any other plugin could draw on if needed (links, menus, polls, etc..).

I've never liked the idea of a universal categories plugin. Categorization doesn't usually apply across objects. The kinds of links isn't going to line up with the kinds of stories. More important is the stuff that piggybacks the category. Topics have icons but not all categorizations need icons. Calendar categories (what? where?) have a field for CSS_style. How would the plugin handle these extra fields?

The only thing a category plugin could do is provide a standard interface for creating hierarchies and an API for making queries against that hierarchy. But doing that in a robust way seems like a lot of work for little gain.