0.9.5 Public Beta 3 support

180 Posts

Pont Reply #141, 20 years ago

I’ve started work on moving an existing site to MODx. Everything is moving along nicely, but QuickEdit has started to misbehave. It either disintegrates or the text disappears. See the enclosed pictures. I can’t find any predictability to this behaviour. It seems random.

The browser in question is Firefox 1.5.0.7
MODx rev 1631

100 Posts

JeremyL Reply #142, 20 years ago

OK when I create a page and select meta tags they get inserted into the page. But if I go back to edit the page, I cannot tell what mate tags or kws where selected in the manager. When I go back later they are no longer highlighted. Is that how it’s supposed to be?

Xuru Internet Marketing

7,075 Posts

davidm Reply #143, 20 years ago

Quote from: Pont at Oct 07, 2006, 04:09 PM

I’ve started work on moving an existing site to MODx. Everything is moving along nicely, but QuickEdit has started to misbehave. It either disintegrates or the text disappears. See the enclosed pictures. I can’t find any predictability to this behaviour. It seems random. The browser in question is Firefox 1.5.0.7 MODx rev 1631

Pont, this is something that I have also experienced with all 0.9.2.1 upgrades, but not with clean installs. I mean, text disappearing entirely from the quickedit toolbar (your second capture). From what I can tell, it’s not browser dependent, it happens with FF, Opera and Safari on Mac, and FF, IE and Opera on PC.

The "line return" is another matter (your first capture), it happens when translated strings for "setting", "content" and "go" are longer than english. I temporarily modified width for #QE_Toolbar and #QE_Toolbar ul ul in assets/modules/quick_edit/styles/toolbar.css, but we are going to modify the QE toolbar CSS so that it’s not breaking with translated strings).

Now back to the real issue, as far as I am concerned, the problem occurs on some document but not all of them. I can pinpoint any similarities between documents which have a working QE toolbar and those who don’t (cache, template, or whatever). Is it the same for you ?

Also, did you upgrade from 0.9.2.1 ?

As you can see I have the exact same problem :

I have been working a couple of hours on resolving this but no luck so far... huh

I re-uploaded every file of the assets/modules/quick_edit one by one to see if it did the trick, but nothing. I checked everything bit by bit, recopied pasted the module and plugin code, also check every parameter for the module. Nothing ! I don’t understand what did not get upgraded that could cause this... Since it’s not files (at least not QuickEdit files, if you think of other files I should check, please tell me) is there anything in the DB that should have been upgraded : I have checked one of the upgraded website’s DB with a clean install of beta5 and once again nothing in modx_system_settings, modx_site_modules, modx_site_module_access, modx_site_module_depobj, modx_site_plugins, modx_site_plugin_events that could explain this.

Anyone has an idea ?

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id

180 Posts

Pont Reply #144, 20 years ago

Yes, I’m experiencing this on an upgraded 0.9.2.1 installation.

I tried reproducing this today and suddenly had no problem with disappearing QE menu items. I then cleared the cache and that caused the menu text to disappear. But on next pageview it was alright again. Puzzling indeed. Even more strange is that this behaviour isn’t consistent for all documents. One difference between documents affected and those not, is that the affected documents all used Ditto. Could this be the cause?

7,075 Posts

davidm Reply #145, 20 years ago

Well done Pont !!!

I just checked and you are RIGHT, this only happens with pages where Ditto is included.
Would you happen to also run Ditto 1.1 Beta ?

Edit : Garry has come up with a fix for this (which you’ll be able to get from SVN in the near future I guess, or in next release), it was a problem of conflicting language strings between QE and Ditto.

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id

180 Posts

Pont Reply #146, 20 years ago

No, I’m using Ditto v. 1.0.2

Great that a solution is in the works!

7,075 Posts

davidm Reply #147, 20 years ago

Better than that, it works

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id

1,010 Posts

TobyL Reply #148, 20 years ago

I hadn;t given 0.9.5 a really good look yet but tonight (at least here it is tonight) I wanted to test my snippets in the latest and greatest so I downloaded it form svn.

I have a few small remarks / requests...

MODx Light: Can you please change the font-family order or get rid off the "Lucida Grande" ? it’s not pretty and almost unreadable (see image attached) and that is in Firefox! (ok, I admit it is on XP but evenso)

Now that we have categories for just about everything, which I really like (and did I hear rumours about sub-categories?) I would really like to see the permission system applied to it (the categories that is) . I couldn’t think of a better way to restrict access to chunks/snippets/tvs to certain managers/users. No more managers messing with things best left alone and no more need for access checking in snippet code itself (in some cases at least), just aplying a category that’s in the right permission group... (that’d be my dream anyway)

eForm | eForm support | eForm @ wiki

MODX Staff
10,725 Posts

opengeek Reply #149, 20 years ago

Quote from: TobyL at Oct 08, 2006, 08:07 AM

Now that we have categories for just about everything, which I really like (and did I hear rumours about sub-categories?) I would really like to see the permission system applied to it (the categories that is) . I couldn’t think of a better way to restrict access to chunks/snippets/tvs to certain managers/users. No more managers messing with things best left alone and no more need for access checking in snippet code itself (in some cases at least), just aplying a category that’s in the right permission group... (that’d be my dream anyway)

TobyL, both subcategories, and permissions on categories will be available in future versions, but as the permissions system is going to be changing quite significantly moving forward, now IMO, is not the best time to implement this in the core. However, rest assured that being able to add access control features to just about any object in the MODx world, including user-defined objects you may come up with for a specific site or add-on project, is part of the plan.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

7,075 Posts

davidm Reply #150, 20 years ago

About Lucida Grande, it’s meant for Mac users... most PC users don’t have it installed, usually then only see verdana or tahoma or even arial... Lots of websites use this (especially since lots of designers are working on Macs wink

)

I am not sure why Lucida Grande renders ugly on PC while looking great on Macs... maybe you have a font of the same family (Lucida) and the browser switches to it instead of falling back on other fonts specified in the CSS, not sure there...

@Jason : nice info there about permission on categories grin

.: COO - Commerce Guys - Community Driven Innovation :.

MODx est l'outil id