221
domineaux
Subscriber type register mod - is one available?
  • 2004/3/24 15:50

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


I need to have a subscriber type mod that will require the user to enter a lot more information and if possible do a paypal payment.

The site I'm working on could be a bandwidth nightmare. Down and uploads of some large graphic files. Not trying to get a big revenue thing here, just offset the bandwidth costs for using the down and uploads features.

I realize there are alot of payment options available along with scripts at Paypal. I'm thinking more in terms of a module that will assure the registrant has paid a subscriber fee before allowing entry into the controlled pages. This is important because this will be an international site, and the admin will not be available 24/7 to verify subscriptions,etc.

CLICK TO PAYPAL MERCHANT TOOLS




222
domineaux
Re: How to add to the existing menu?
  • 2004/3/23 22:10

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


I'm trying to access the 4images that I've installed separately from XOOPS via Main Menu /public_html/images/

When I go into system - blocks - Main Menu - edit - edit template the changes are not applied. I have a view button at lower left only. I click it and it would appear it's a done deal because I see the added "Gallery".

Regardless, it doesn't appear to work.

I've got Invision and 4images I'm installing on the same server within the same public_html, and I have separate MySql databases.

So all I want to do is link to them and link back...sounds simple enough, but my brains on overload already LOL

I'd appreciate a jumpstart on this, thanks




223
domineaux
Registration Hack with Graphic Number - to stop bots
  • 2004/3/23 18:56

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


Has anyone done a XOOPS registration hack that has a graphic ID like in Netsol.com for whois, Invision boards,etc.

When a new user registers there is a popup or box with a graphically displayed ID, usually alphanumeric, that the user views and types in to an entry box.

--------------



224
domineaux
Theme using this Xoops default for Invision Boards
  • 2004/3/23 17:58

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


Has anyone done a theme for Invision Boards (IPB) that is equal to this default XOOPS theme.

I'm interested because I want fast loading pages. This page loads fast and fast loading is a help on the boards for sure. Also there aren't a bunch of gifs and graphic files to load, which really speeds things up.

I'm building a site that will be accessed by a lot of dialup users. The users just won't stay with slow loading sites or forums.

I need a full featured boards like invision, phpbb, vbulletin or yabbse. I hadn't thought about using a board besides the invision, but if someone is using this XOOPS default theme on one of the other mentioned boards...I'll sure give it a try.

Any comments or suggestions will be appreciated





225
domineaux
A thread of mods and themes considered capable
  • 2004/3/22 19:15

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


This is a category we've needed for awhile.

It will be nice to compare notes with other users about specific modules, themes and hacks.

My experience has been trying and finally quitting in frustration on so many ancillary software items that were designed to work with Xoops.

Language has been a barrier in a lot of cases, but the biggest issue has always been the persistent beta releases.

I no longer install any beta release of anything, on working sites. I sometimes try them on my local server, but generally beta is what they are.

I'm not trying to rag on anyone here. This category will be good for comments on all of Xoops.










226
domineaux
Re: Which are competent - NON-Buggy add-ons for 2.0.5.2 ver?

Carnuke and others

I appreciate we can discuss this subject with some candor.

One important issue I didn't clarify about long standing betas. I've seen several examples lately where other developers have taken on projects, which have been in beta for long periods of time. In other words, the mod is needed by the community and someone starts the mod. The mod is put up beta, but the follow thru is in adequate.

As a matter of courtesy and respect for another developer's work most developers that could probably finish the mod...don't. The project drags on indefinitely the mod stays beta, and the community is not well served.

A time frame for betas might well serve the community better. I realize there may be some developers that just wouldn't put up their mods until they're darned close to finishing it. Some might argue that delays things, but others might say...betas are not intended as anything more than to make refinements in an already complete mod.

I'm not saying that "beta downloads & final downloads" is the only "good idea" for dealing with betas. Betas are important to development, but let's face it often the starting developer may not have skills to finish the mod without community assistance. My "thinking well" runs dry occassionally...and other's ideas can sure be the catalyst that gets me moving on.

My inclination is to do something about betas, that is quick and simple, which won't require a lot of effort on anyone's part.

I don't think I need to give examples of long standing betas that other Xoopers are clamouring for even now. Some developers have even taken initiative to produce these mods, via other descriptions and similar names.

If long standing betas are removed from the XOOPS sites as downloads it should open the avenue for other developers to taken on the unfinished modules possibly under different descriptions.

When a mod us put up for download on the XOOPS sites it is awarded a type of credential, even if it is beta. A module put up for download on an XOOPS site, whether beta or no is providing some protection for the original developer. Other developers will hesitatingly take on projects, which are already up for download, beta or not.

Again, I am not against betas, just long standing betas.



227
domineaux
Re: Which are competent - NON-Buggy add-ons for 2.0.5.2 ver?
  • 2004/2/1 20:44

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


Carnuke and others

I wasn't thinking as much in terms of categories as described in the link you provided.

My thinking is that new users of XOOPS need encouragement. Poorly working betas is not the way to provide encouragement. I remember how many times I've had to make postings on simple issues, and frequently just delete mods after days of working with them. There just were not viable solutions to the problems, and some of them are still beta after approximatley a year in the downloads section.

The number of modules and other add-ons is really not that large, and certainly not so large that users can't scroll and review the mods. Many mods are not very well described and if often takes several postings to forums to determine exactly what certain mods actually do provide in terms of what they provide.

Now! we need the beta mods separated from good viable working download mods.

I'd like to see more incentive to get mods out of beta or delete them from downloads if they aren't final within a reasonable time period.

I agree that mod builders should provide the majority of support for their respective software on their own sites, especially during beta. I still think betas are a good community service, so I wouldn't be inclinded to only allow final mods on downloads. I just think the two should be separated by final and beta in the downloads. In fact, it might be that betas have not category at all...just beta.

Separating mods by beta and final, would claify for users betas are incomplete and further support is needed and provided on the author's site.

---------------------



228
domineaux
Re: Which are competent - NON-Buggy add-ons for 2.0.5.2 ver?
  • 2004/2/1 15:41

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


Whoa again!

I take no issue against betas. I'm just fine with quick releases of betas.

I think betas should have a separate place in downloads, and they should have limited life spans as betas.

Betas are usually completed products with very minor issues. Issues, the developer hopes to resolve in a very short time frame.

There are many modules in XOOPS that have been beta indefinitely............. I expect them to continue as beta, if the past is any indicator of the future.

Obviously, beta has various meanings among XOOPS members.

If someone needs help with a module I think the spirit of these boards is to help. So...why not just ask for help, share some of the credit and develop a valuable community module. Let's face it all the modules eventually become community projects over time, with changes in the core and the other development tools available.









229
domineaux
Re: Which are competent - NON-Buggy add-ons for 2.0.5.2 ver?
  • 2004/1/31 23:09

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


I just came from the downloads, and a lot of what we need is already in place. The ratings is not an adquate way to rank the download, since it is just a 1-10 choice.

The biggest help to us all would be to have BETA CATEGORY of downloads, and only final well commented and regarded add-on mods would be in the FINAL CATEGORY of downloads. The removal of BETA CATEGORY downloads after XX days would also encourage the developer of the mod to work more diligently at putting the mod up for FINAL CATEGORY.

Just scroll through the downloads and look at all the betas, and at how long they've been beta. A BETA CATEGORY download section would have meaning to all of us.



230
domineaux
Re: Which are competent - NON-Buggy add-ons for 2.0.5.2 ver?
  • 2004/1/31 22:30

  • domineaux

  • Quite a regular

  • Posts: 389

  • Since: 2002/9/29


I think evaluating modules would be difficult without some type of restrictive or carefully worded criteria. I long ago quit reading the comments, because they just don't provide adquate information. I've found it is better to just post on the boards and ask for feedback.

Most of do appreciate the mod builder's efforts, and we're reluctant to challenge the developers. I think the developer is wrong to post fixes on these forums and not change the module properly. In fact, if the developer made tweak and fix notations in comments under the respective download it would be a lot more help to users. Searching the forums is difficult, because the way people word their questions or style their subject line may not indicate anything about the actual thread contents.

Regardless, betas are betas and we all understand that a beta is an incomplete work. The beta mods should be categorized as such in the downloads.

BETA DOWNLOADS SHOULD HAVE THEIR OWN CATEGORY UNDER DOWNLOADS

FINAL COMPLETE DOWNLOADS SHOULD HAVE THEIR OWN CATEGORY UNDER DOWNLOADS

If a beta is beta too long it should be deleted from the downloads. There are entirely TOO MANY BETAS in the downloads, and they stay beta for too long...or worse, continually. Again, betas should only be allowed a specific period of time as beta.

I think ratings on FINAL COMPLETE MODSwould be extremely helpful, and probably some type of well worded questionaire which could be the method for creating a ratings. Most of us are aware of ratings and review mods. Maybe we need an XOOPS 1)reviews module with 2)ratings and 3)comments included on this site.

The XOOPS Core should definitely include some type of reviews process for evaluating all mods, and clearly communicate issues to expect, or fixes and tweaks peculiar to specific usage of mods.

MODS IS WHAT XOOPS IS ABOUT Something clearly needs to be done


===================================




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



Login

Who's Online

187 user(s) are online (65 user(s) are browsing Support Forums)


Members: 0


Guests: 187


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