Javascript is not interpreted until full page load, so you may include it at the top and it still won't count until the page is fully loaded.

Therefore the best place is at the bottom, where it will also not slow down the page content loading, thus servicing your users.

Quote:
Sorry, I misread your initial statement:
Quote:
But anyway, if you want to help, then I fully support that (should anybody care). My main point was and still is that coming up with ideas is the easy part - bringing them to life is what is difficult. As Mboyden states, "Focus on issues, not on people". Focus on what really really needs to be done, do that, THEN take the next move. The big all-encompassing plans tend to fail on the small parts.

@Tjenemez
Quote:
None of what I have said about Catz is rumor or misinformation. It is a very long time since Catz followed a project to the finish and released anything. Therefore, I disagree with him leading XOOPS (but since that is not an issue, let's let it go).

Quote:
I assume that you mean me and not Catz here? Could you define "missing"?
In the past year, I have worked on WF-Downloads v3, SmartMail, SmartProfile, SmartBlocks, trying to give XOOPS users something of value without resorting to hacking the core and releasing my own XOOPS versions. This option has for the most part been available to everybody else - still, some people think that if their suggestions (often vague descriptions of a solution rather than a specific need) are not accepted right away, this is the only way to contribute.

Maybe if more people made modules to do what they wanted - even if it simulated core behaviour or "should be intthe core" - it would be easier for core developers to pick the interesting bits and include them in the core than now, where core devs have to get an overview of all changes in a full core.

Similarly, when it comes to the content on xoops.org - stating what someone wants or desires or imagines could be done is all very well, but how about some visual images of what it could be? Find out what is needed, specifically (Modules repository needs a "compatible with XOOPS versions x & y but not z", that will require this and that change to a downloads module). Come up with a suggestion theme.

Even if the suggestion is not implemented right away - or not at all - you will have contributed to the process and maybe someone gets the ultimately brilliant idea that everyone loves based on your first suggestion.

I don't see the controversy in that.

Take care. I'm off to a vacation. I may be back.

Quote:
Certainly not. I'm supporting the current leadership and its progress - I shouldn't hope that was controversial
Quote:
Of course you cannot. You have done that.
You have tried going to another project.
You have tried coming back only to leave right away.
You have tried forking XOOPS.
So when the chance comes to grip "the power" you go for it - that's only natural.

All I want to say to that is that your track record is poor and therefore handing over project leadership to you would be an unsafe bet to take.

If you came with more tangible things than "If I was at the helm, things would be different because I have the best ideas and this is the direction I think is the best" I would probably see things differently.

Everybody seems to want to say how things should be, but not one comes with tangible things like... oh I don't know... Perhaps a new theme? A logo idea? A real-life suggestion on how the front pages of the various XOOPS sites should be with the information that should be there? A really good module documentation template?

But no - it's all "I want to lead and tell people what to do - of course, it will be oh-so democratic and everybody will be heard and we will all be happy and live happily ever after" (I am - whatever you may think - NOT just aiming this at you, you are just one of several).

Phppp has been involved with this project for years now. Continously. He deserves more than powermongers buzzing around him like scavengers. He deserves people around him, who will not only discuss but also DO!

I'd like to see you (all) do something.

@Damaster: Possibly it was a mistake of me to reply in this thread and I sure have made a lot of mistakes in my life - but I really don't consider ignoring you as one of them. So I'll continue doing that.

*pop*

LOL - seems there were several people just waiting for the chance to get a slice of the management cake.

Anyways, I wish you (all) the best of luck with the power struggles and character assassinations that I am sure will come

Lots of good ideas surface, I'll be following with interest, which results come of it as it is always easier to say than do. Something that Catz - since this is the thread about Catz, I'll mention it - is familiar with through his former abandoned projects.

Anyways, I hope you can get out of the circle of negativity that has been a part of XOOPS for so very long. A circle in which the people involved were criticised when they did something for not involving the community and if they involved the community, nothing happened and the community criticised them for not doing anything.

My advise to the current contributors is, if in doubt, do something. Even if people criticise you for it, it is better than not doing anything. And whatever you do, stand by it if you really believe that it is the right thing to do. Don't let the highest screamers get to make you change your mind, if it is based on (to you) good arguments.

/me goes back to the sideline and fetches some more popcorns and 3D-glasses

I agree that the conf_title and conf_desc fields should be longer - I have reached the limit a couple of times, too.

The conf_name, however, should not, as it is used in the code and I believe that $xoopsModuleConfig['prefix_context_name_and_usage_and_more'] can ALWAYS be shortened to something that still is of use to the code-reader.

Especially the practice of prefixing module config names is unnecessary in my opinion. Database tables and Smarty templates can conflict with other modules, if not prefixed, but configuration items cannot (they are bound by module) so "max_items" is just as useful as "mymodule_frontpage_max_items" - if not even better, since it is shorter and easier to remember.

Regarding the field type, I find that there is a reason why varchar's exist and if text was better, it would be used and encouraged more. Searching and indexing text fields is NOT better than varchar's (in my perception) when we talk KEY indexes. Of course, text in MyISAM can be fulltext indexed, but that only makes sense with large amounts of content in many words. Conf_title and conf_desc fields are names of constants and thus always in one word and should not be too long for the same reasons as the above (however, it should be prefixed to avoid conflicts with other modules - however unlikely it is that it should happen)

"too long" has moved since the config table schema was created and it could be a good move to enlarge the fields' lengths, agreed (and it was actually done in 2.2.x as one of the smaller changes).

That is correct. There is a bug in the code that has been of low priority because (I reckon):
1) Users are not often created through the administration area
2) It works, when editing

I think there is a bug issue at sf.net about this, but I think the core devs should focus on the larger works than this small bug (not insinuating that you have done anything wrong by pointing this out, just giving my opinion that it is too minor to do anything about - unless the core devs find that it is a bad signal to send and that they have time to fix it)

I'll be taking a look at this, soon.

Please add future enquiries to the bug trackers onhttp://dev.xoops.org/modules/xfmod/project/?smartprofile

module name: acc
class file name: memberstype.php
class name: MembersType
class handler name: AccMembersTypeHandler

Then you can get the instance of the AccMembersTypeHandler just by calling xoops_getmodulehandler('memberstype');

or - if you are in a block - xoops_getmodulehandler('memberstype', 'acc');

Yeah, block cache is set individually on each block.

The following blocks seem like ripe candidates for a 30 minute/maybe longer caching:



Depending on the speed of replies in the topics, the "Recent Topics" and "Recent Comments" may only be useful with 1 or 5 minute caching.

Quote:
The first is the module's actual loading time
The second "XOOPS output" is initiating the output layer (Smarty) AND the blocks.

It seems you have a great amount of blocks that take quite some time to load. Find out which and see if you can cache them.