211
Draven
Re: preliminary summary of roadmap discussion
  • 2003/11/3 14:23

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Oh, one thing I forgot to mention..

Error reporting for admin ONLY. Debugging info should not show to other users, only admin group. I hate having to shopw everyone my debugging info when I'm trying to look at one thing. You should be able to set group access for this feature as well.



212
Draven
Re: XOOPS 2.1 Core development Roadmap
  • 2003/10/31 21:08

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Ahhhh, modules are not the core. Are they needed to produce a certain type of site, yes? But all this can be discussed in the MODULES ROADMAP!!!! Additional blocks are a discussion for MODULES, and will be included by the MODULE DEVELOPERS. Not the core team. And not the end user.

No one said that quality modules aren't going to be provided for the community, that's the whole point of the module team. They will be given XOOPS seals of approval by the quality control team. Nothing is going to change other than the fact the core team is no longer developing modules but rather concentrating on the core itself and providing the tools the module developers need to create bigger and better modules, which is what we should be discussing here. It will be the responsibility of the product team to package the modules WITH the core for the desired site style.

This conversation shouldn't be degrading like this but you're upsetting me now because you continue to talk about MODULE problems and/or advancements and not core problems/advancements for the needs of the module developers.

Now please lets stop bickering and return to the topic at hand. All of your concerns for modules can be addressed in the Modules Roadmap.



213
Draven
Re: XOOPS 2.1 Core development Roadmap
  • 2003/10/31 20:38

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:
Yes, it's easy and possible to hack blocks, but the point of improving XOOPS is to make it so that the less things people have to hack the better, and these block/display issues, imo, are a major part of the core of any CMS, otherwise A CMS becomes "pointless" if you end up forcing people to hack blocks and news/article posting modules to get it to do certain basic things that all relate to handling "CONTENT."


I'm not talking about hacking blocks, I'm talking about creating additional blocks to cater to your needs. This in no way has anything to do with the core of Xoops. Everything you guys have mentioned concerning the news module can be done by creating, not hacking, additional blocks and altering templates. Trust me, I've done it. It requires no change at all to the core of Xoops.

Quote:
And the News Module is part of the "core." The core comprises several standard modules which the new module development team is working on and these include News, Sections, Blocks, Forums, Downloads, Headlines, etc. At the moment the first module getting the major overhall treatment is the Sections Mod. But all of these modules are part of the "Xoops" standard "Core," such as it is.


No, it isn't part of the "core". It was developed by the core team but is not required to run xoops. The core implies the required files for running Xoops. The brains of the system.

I'm well aware of what the modules team is working on, since I'm on it. All of the above mentioned modules have been handed over to the module team because they are no longer being developed by the core team. In fact, eventually there won't be any modules included WTIH the core (other than the system module), but rather you will choose between prepackaged Xoop products depending on your needs. Community portals will include the required modules to run such a site. Same for a magazine style site, etc.

Quote:
I don't think you can have any realistic discussion about the "core" without talking about improving these modules and what the end user and administrative processes are going to be. Sure you can talk about function classes until you are blue in the face, but without real world applications it's pointless, especially for all of us non-coders.


On the contrary, there are many things to discuss. The problem is the ones who require these changes are not the end user, it is the module developers. End users only see the end product, which is made up almost entirely of the modules used. SO I understand your confusion but your concerns don't concern the core, but the modules involved. We, the module developers, need these "silly" classes to build the modules you use. And that is what this discussion is about. As I stated earlier, there will be a discussion on modules at a later date and you can reveal your concerns about them then. For now lets stay focused on the topic at hand, the core.



214
Draven
Re: XOOPS 2.1 Core development Roadmap
  • 2003/10/31 19:17

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

malexandria wrote:
Well, is not the News Module and how content is displayed MAJOR part of the core?


As far as I know the news "module" is not part of the core. It's a module. And content display is done through templates and blocks within the modules, not the core. If you want to alter what the blocks display, alter the blocks code in /modulename/blocks/



215
Draven
Re: XOOPS 2.1 Core development Roadmap
  • 2003/10/31 18:39

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

Big_Bro wrote:
Malexandria hit the proverbial nail on the head. Without a doubt, more and more powerful content display blocks are the number one need in my book.

A content management system needs to have multitudes of methods for displaying the content that it manages, it can be perfect in managing content for a webmaster but if there are only basic ways to display that content, it fails to deliver it's promise. In my opinion slick management pages etc would be nice but I'd rather present the nice face to my users and have a crappy backend interface than vice versa.

A system of display that includes elements of the great work Draven has done with his gaining-mass site would be outstanding, such as the news topics category listings and side blocks that let you handpick news items for display. A block like I manually created in my newshax site would be great too, where we could list a certain number of stories of our choice by the headline and a fixed-size thumbnail image. I have a hand-coded version on my site at www.newshax.com, on top of the right column.

Anyway, my point is that admin interface improvements are certainly welcome but are a much lower priority than public interface improvements.


These are all things concerning modules, not the core which is what this discussion is suppose to be focusing on. That's why everyone is talking about the backend. The title is "Core development Roadmap", modules will come at a later date as Herko laid out in this post.

btw, thanks for the compliment.



216
Draven
Re: Job available - PHP MySQL XOOPS - in Shanghai China
  • 2003/10/31 17:20

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


PM me with details.

Some sites I've built with Xoops...

http://www.fantasyasylum.com
http://www.gaining-mass.com (Slow because of host, not site... moving soon)

None XOOPS sites

http://www.gobigmedia.com
http://rweb.gobigmedia.com/


More if needed.



217
Draven
Re: XOOPS 2.1 Core development Roadmap
  • 2003/10/31 15:29

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

skalpa wrote:
Quote:
A smarty based admin area

Well, I don't agree 100% with that one. However, being able to change its appearance is needed, so I choosed an intermediary option.
1) The admin is a sensitive part....

Gotcha. Well there should be a little more flexability then there is now is all. Whether it's smarty or some other route.

Quote:

Quote:
btw, I think skalpa already has an idea similar to this in the works

Actually, it's still in my mind. But the day I manage finding the way not sleeping anymore, you'll have it
Seriously, as 2.1 won't be here right now, consider it's planned for it.


Might have been Preditor then.

Quote:

Quote:
Having this allows you to theme differently for each module

It's already there !
Check <{$module.directory}> and <{$module.name}>
Also, theme writers may want to try "Smarty debug" mode in PHP or insert <{debug}> in their templates to see all the defined variables.


See!! I went and made my own hack cause I had no clue it was there. Are you sure it was there in 2.0.3? I swear I did a smarty debug on each module looking for any current variables I could use and saw none. Is it possible this was only added in 2.0.5 after sending my hacks to Catz?



218
Draven
Re: XOOPS 2.1 Core development Roadmap
  • 2003/10/31 14:29

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


I'll categorize mine based on what area it effects.

Administration

- A smarty based admin area (This would allow theme creators to also create backend themes). Not super important but the sooner we make the switch the better.

- When changing a block setting, return the user to the last group setting they were on. It's really frustrating changing something for a group who is last in the list, make one change to a block and your back viewing the first in the list. You then have to select the group again and again every time you make a change to a block.

- A better DHTML editor. I have to give a hats off to the boys at Invision, their posting editor allows you to actually highlight a word and press the button to bold, hyperlink etc. But it's not a big clunky WYSIWYS either. Which I think is perfect for things like forums, news and so on. However I do agree with the above that XOOPS should also have a WYSIWYG editor available for use also. Catz editor is pretty good but it'd by nice to have a universal editor like that in the core... but I guess this is more a module need then administration.

- An easy back-up system. Something that would back-up both DB and web files and package them in gzip file for DL.

Modules

- I'll just mention the WYSIWYG again incase no one read my above rambling.

- Documentation. I know this is in the works but it's really a must. Right now I tend to find functions by looking at others code but I'm sure there's some beautiful functions lying around no one uses cause they don't know they’re there.

- A url rewrite function. As someone mentioned above, a function which allowed for URL write and could be used both from PHP AND smarty. This way when you link something it can be rewritten in a universal way. Just something like:

$myts->urlrewrite("My word or image", "http://mysite.com/modules/wfsections/article.php?articleid=1", "target", "title", "option");

and the above would produce something like

http://mysite.com/articles/articleid/1/

Which mod rewrite could then revert back to the orig. URL. Perhaps there's a better way but you get the idea. THis is key item I think to both SEO and moving one step closer to separating us from the other CMS's out there.

btw, I think skalpa already has an idea similar to this in the works.

Themes

The biggest thing for me as a theme developer is being able to tell from within smarty what module the user is currently viewing. I hacked this for my site but to have it built in would be great (And not all that difficult). Having this allows you to theme differently for each module by using different CSS files based on the module name, and even use different images.

I have lots more but my fingers hurt from typing this much.



219
Draven
Re: PayPal module
  • 2003/10/30 16:03

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


I've been contracted by www.fantasyasylum.com to create a membership module for them. If I can get their permission to release the module to the XOOPS community I will do so. But can't guarantee anything since they're paying me to build this for them.



220
Draven
NewBB bug (Who thought of this?)
  • 2003/10/28 16:39

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


This is just a silly bug and is a design flaw. I just finished redoing a XOOPS site that has a very large user base and busy forums. In the viewforums.php file there's a section for "paginating" that adds "..." between every three pages. Well if a thread has 96 pages (as one of mine does) it adds 33 "..." and blows the page apart.

This:
if ( $totalpages ) {
        
$pagination .= '&nbsp;&nbsp;&nbsp;<img src="'.XOOPS_URL.'/images/icons/posticon.gif" /> ';
        for ( 
$i 1$i <= $totalpages$i++ ) {

            if ( 
$i && $i $totalpages ) {
                
$pagination .= "...";
            } else {
                
$addlink '&start='.(($i 1) * $forumdata['posts_per_page']);
                
$pagination .= '[<a href="'.$topiclink.$addlink.'">'.$i.'</a>]';
            }
        }
    }


Should be:

if ( $totalpages ) {
        
$pagination .= '&nbsp;&nbsp;&nbsp;<img src="'.XOOPS_URL.'/images/icons/posticon.gif" /> ';
        
$setdots 0;
        for ( 
$i 1$i <= $totalpages$i++ ) {


                        
// Hacked by Draven
            
if ( $i && $i $totalpages) {
                if(
$setdots == 0){
                    
$pagination .= "...";
                    
$setdots 1
                }
                        
// -- End Hack
                
            
} else {
                
$addlink '&start='.(($i 1) * $forumdata['posts_per_page']);
                
$pagination .= '[<a href="'.$topiclink.$addlink.'">'.$i.'</a>]';
            }
        }
    }


This isn't a beautiful fix, but it works.




TopTop
« 1 ... 19 20 21 (22) 23 24 25 26 »



Login

Who's Online

140 user(s) are online (108 user(s) are browsing Support Forums)


Members: 0


Guests: 140


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: May 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits