Pre 3.2 release bug testing files

Can you show a quick "best practice" chunk of code around [*content*]?

Quote from: rthrash at Aug 21, 2005, 08:24 PM

Raymond, wouldn’t it be easier to change one small file (or set thereof) than the entire rewrite of the manager throughout? Or am I confused?

The reason for this is that users might use such id in the future that might break the manager.

What Adam did was to add the prefix qe_ to his classes and ids so they don’t conflict with manager ids. I think we should do the same thing too to prevent future conflict.

Just my 2 cents

Quote from: xwisdom at Aug 21, 2005, 08:56 PM

The reason for this is that users might use such id in the future that might break the manager.

What Adam did was to add the prefix qe_ to his classes and ids so they don’t conflict with manager ids. I think we should do the same thing too to prevent future conflict.

Maybe I’m just dense (and, in fact, I am!), but I don’t get why the users are styling the manager? (Or how?)

Quote from: infoclipper at Aug 21, 2005, 09:04 PM

Maybe I’m just dense (and, in fact, I am!), but I don’t get why the users are styling the manager?  (Or how?)

No, they are not styling the manager they are just using CSS from within there modules or maybe backend snippet. I think that was what Adam was doing, correct?

If it’s going to take too much work to add a prefix to the manager classes and ids then I guess we would have to provide adequate documentation showing users what classes or ids they are not to use when creating modules/backend snippets.

There will be documentation on that, yes.

There is a standard set of CSS classes that we’ve reserved and there will be documention on those so anyone can create custom themes for the backend.

Realistically, though, I don’t see this being an issue once we get the new manager in everyone’s hands; it’s just that I haven’t finished yet, so it’s hard for anyone to know what their code looks like inside the new layout. Once its in use any issue like that will be instantly obvious.

Been chatting with Raymond and Travis and there’s real opportunity for CSS confilct aplenty. I think the best solution that leaves the most flexibility and makes the most sense to avoid confilcts (particularly with major modules) is to:

• allow the main manager to use semantic CSS and offer documentation of what it is using (well, actually just open the manager style CSS and don’t use those, silly!)
• have "internal" modules use like what Adam did in prefixing their CSS, in Front End / Quick Editor case: qe_, and
• offer a third super-lightweight 20-30px tall "return to Tattoo Manager" frame (Yes, frame!) at the top for major integrations, like running the SMF manager from within Tattoo/MODx.

Make sense?

I’ve updated the file in the top of this thread. TP 3.2 now includes latest FCK editor and latest Quick/Front End Editors.

Download Here

Does makes sense but let’s not make it a top priority just now. If we use the frame method we can code the page to behave as if everything is running as a single page by just adding a little Javascript magic. So in short the header remains, etc

Yeah, sounds like I don’t need to change anything, which is great. We can deal with the frame idea once the need arises...

exactly