Quote from: JeremyL at Oct 13, 2006, 02:41 PM
Bug or just missing feature?
When I create a page and select meta tags / keywords they get inserted into the page. But if I go back to edit the page, I cannot tell what meta tags or keywords where selected in the manager. When I go back later they are no longer highlighted. Is that how it’s supposed to be?
It’d be nice to get those into checkboxes.
It is:
font-family: "Lucida Grande", Helvetica, Arial, sans-serif !important;
font-family:"lucida sans unicode", "lucida grande", lucida, sans-serif;
/manager/media/MODxLight/style.css Line 217:
input, select, textarea, td {
font: inherit;
}td {
font: inherit;
}
input, select, textarea {
font:normal 100%/1.2 monospace;
}In /manager/actions/dynamic/mutate_content.dynamic.action.php 492: <div class="subTitle"> change to: 492: <div class="subTitle" style="position:fixed;top:0;left:0;z-index:30;"> 506: <div class="stay"> change to: 506: <div class="stay" style="background-image:url(media/images/bg/treeback.jpg);"> 518: <div class="sectionHeader"><img src='media/images/misc/dot.gif' alt="." /> <?php echo $_lang['document_setting']; ?></div><div class="sectionBody"> change to: 518: <div class="sectionHeader" style="margin-top:4em;"><img src='media/images/misc/dot.gif' alt="." /> <?php echo $_lang['document_setting']; ?></div><div class="sectionBody">
I used manager in Opera 7.23 and some later - yes, there are some bugs, but interface in overall is accessible. I like Opera (especially 9.x) and think it will be great if MODx 0.9.5 will provide Opera compatibility. Opera is popular enough in the world (espesially on different portable devices) to be worse to get sufficient attention of MODx developers. I understand that browser compatibility must be handled after the phase of intensive developing, but MODx 0.9.5 is close to Release Candidate (or at least at the senior beta).
the manager has been unusable so far with Opera up to 0.9.2.1
I also have this bug in all MODx versions and all Opera versions I have tried. I suppose it is caused not by CSS, but by some javascript properties setting. Now I do not have time to digg into this bug, but at the end of week I’ll try to find and post a fix.
Menu tabs in manager fall behind the previous item when mouse is hovered over a subitem in Opera 9.01.

The ’collapsible top bar layout’ is gone from the manager. There is not any option to change the layout. I prefer that over the current one as it takes less space on screen and does not have display bugs in Opera (at least in 0.9.2.1) - see first bug above.
- The installation package includes ’bottom button bar’ module. IMO it would be more useful to make the button bar ’position:fixed’ and let the content scroll beneath it. I made a small modification in my 0.9.2.1 however it seems that this bar sits in different places for diffrent content (documents, snippets etc.).
- I would suggest to remove styling of form elements other than textfields. This topic has been discussed many times (eg. http://www.456bereastreet.com/) in context of accessibility. To get it short - it seems best practice to leave those elements (checkboxes, radios, buttons) to be styled by the browser - it is the most intuitive to the user. Also, those elements are not styled consistently by different browsers and results might be ugly sometimes.
I am very keen on the idea, and would like to involve MODxers when the time comes to help define the best possible GUI for the next-gen manager...- Is it planned to keep frames in the manager? It would be more elegant to drop them and aim at compliance to strict doctypes IMO. The scrollable areas can still be achieved with ’overflow:auto’ and a fixed width/height if that is the reason for it.
I don’t think anyone is still keen on frames nowadays. The idea would rather be introduce some ajax to avoid those refreshing frames

- Would it be possible to implement ’translation’ of non-ASCII document titles to automatic ASCII aliases? I mean something that is done in eg. Textpattern, where a i18n table is used to convert non-ASCII strings to ASCII ones. At the moment non-ASCII characters are stripped from aliases. See the attached image for an example.
Few more fixes to get the next one out. Whether it’s a beta or an RC, who knows?
This discussion is closed to further replies. Keep calm and carry on.