Hi, before anyone says anything, yes, I know we're off-topic but it seems daft to me to start a new thread at this stage.

Quote:
As far as I know, Safari is still the default Mac browser, coming with every Mac OS and as far as I know is used by well over more than half of all Mac owners. As it is now available for Windows and Linux, it will become even more important in the future.

Quote:
Somewhere in the Bible is a saying something like, "Pride cometh before a fall...."
The following example should go some way to explaining what I mean with this reference.

I have only Win2k and therefore no IE7 or Safari (you can't install either on Win2k). I have a web site that uses a lot of JavaScript to generate page templates and a tab menu system. I was also naive enough to not to test my web site in IE7 until a few weeks ago. After all, JavaScript only gets extended with each new browser version and I'd tested it with IE6, FF2 & Opera9 .....? Ha! Ha!

You can still take a look at the mess IE7 makes of my JavaScript in the next day or so, as I won't get access to a computer with IE7 to fix it until the weekend. Don't ask me how much that mess in the most widely used browser in use today has cost me when potential customers have taken a look at my site. However, I'll bet that I could probably have bought a gold plated IE7 with the money.

And what brought me to check my site with IE7 six months or so after I'd tested it and found it to be ok?

Quite simply, I installed Firefox 3. It made a similar mess of the menu tabs on the first page of my site to that which IE7 makes. This time it was because of a change in the way Firefox calculates offset attributes.
(Don't worry if you're a web developer and didn't know about this change - as far as I know, this is a bug and is only documented on my site (fame at last) and on a bug report I submitted to Mozilla.org (Which at least means more fame and improved ranking in Google!))

I've fixed the Firefox3 bug only a month after the new version was introduced but this experience started me off thinking that I might have other unseen pitfalls lurking, and with my IE7 bug, I was more than right!

OK I've fallen flat on my face twice with JavaScript and, Eireann, I presume you were talking about CSS but tell me, which gets changed the most with each new browser version? CSS or JavaScript?

As I said, pride (or lack of money or whatever), cometh before a fall.

Alan

Quote:
Not everything - Safari and IE7 should be a must for everyone making their own site.
Or does anyone have a workaround that I don't know about?

Quote:
I have always had problems trying to do this using the Windows Explorer search, which was not very reliable, at least on older Windows versions. However, most, if not all, code editors can search through files. Weaverslave is an example, and is free.

Vamptrix,

if I understand what you mean correctly, it would mean that before an update of the CMS was released, the module developers would get the chance to get their modules certified for the new version.
I don't think this could be expected to work.
After a typical Firefox update, I'd say that half of my plug-ins no longer work, and I can't see XOOPS being any different.

As we see from the Mozilla systen, compatibility (which I see as being equivalent to validated certification) needs to be version dependent.
As site administrator, I need to have control.

Having said that, an auto-update system could wait until certified versions of all modules installed on a site were available before going ahead with a CMS update. Which, then again might not be so good for an update in the event of a major security leak.

Alan

Automatic updates may be a good thing in event of, for example, security problems.

However, as an administrator and developer, I need to be able to determine who else (i.e. which user groups) get to see the information that an update is required (I want to approach my clients and not have them come running to me). I also need to have the ability of postponing an update as long as I want. (e.g. till I know it's reasonably bug free).

I do not think XOOPS could allow itself the mess that the Mozilla people have. If I have a crucial Moz. plugin (lets say the calender for Thunderbird), after an update to the main application (Thunderbird) my plug-in may be automatically disabled for days, or even weeks if the plug-in developer is busy, until a compatible update has been released. Whilst this may be acceptable for trivial plug-ins, it is a disaster for anyone wanting to install a 'mission-critical' plug-in such as a calender.

To translate this problem back to a CMS scenario, I could not accept the risk of an important module (say my forum) being automatically switched off because of a compatibility issue.

Before letting an automatic CMS update take place, I need to know reliably which modules are going to be incompatible with this update, so that I can decide whether I am prepared to do without these modules.

Alan

Hi,
you still need to take a look at it in FireFox - your horizontal menu near the page top doesn't work.
Alan

As someone considering starting a XOOPS site after a few Xoops-free years, I'd very much appreciate having a ONE-STOP source for modules where I can SEE-AT-A-GLANCE what likelihood there is that the module could be worthwhile trying out.

I think it is important that:
- it EASY for users to give feedback about the functionality of a module
- just because one user gets a module to generate a white screen of death should not mean that it lands in a module graveyard
- opinions from more qualified / experienced people are given more importance.

How about a simple five point rating scheme as a way of gathering initial feedback from users? I think this should reflect what the module should do, how well it actually does it and the security.
For example:
5 - works perfectly, great functionality.
4 - works with minor errors (php warnings?), good functionality.
3 - works but some functions give php errors and fail. Has possible security leaks.
2 - Only some functions functions work without generating errors Provides a confirmed security risk.
1 - does not work at all without generating php errors / causes XOOPS system to crash. Provides a major security risk.

A single parameter such as the average rating of a module multiplied by the number of users providing feedback or similar could then be used to determine how urgently a module was needing attention.
This could be done using a modified version of XOOPS Polls.

Alan

deka87,
do you know that there are link and (at least were) link exchange modules?
A.

This is a really useful thread.

I'm no expert but I think that legally one can take a wider point of view than has been discussed here.

Lets look at themes from another standpoint - a theme is a way of creating a GUI for a CMS using HTML, JS, etc. It is not just code plus images - it is also a designed "object" on its own providing information flow, visual structure, etc.. When I make a average theme then I can port it to Nuke and other Xoops-similar CMS without too much effort.

IMO, the interface a theme has to the CMS is (generally) a secondary component of the theme (OK we can discuss this, but I mean in general).

The principle of weight or importance - i.e. what is the predominant part of a design / idea / product is IMO what is behind the text which Will quoted: Quote:
This principle has been a part of patent and design registration law for a long time and must also play a role here.

(However this could also be turned on its head - where a theme is relatively simple from the design side but uses many unique features from the CMS, then maybe it could be argued that the theme came under the CMS license.)

However in end effect what is just as important in court as what is written in the law books is how other similar (precedent) cases have been judged. Does anyone have any information about such cases?

Alan

Hi,
someone with appropriate permissions must look out your old usernames. There was a time when, for example, you logged in under John something - unfortunately I don't remember your past profiles.
Alan