Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editing contexts #4434

Closed
modxbot opened this issue Apr 17, 2011 · 4 comments
Closed

Editing contexts #4434

modxbot opened this issue Apr 17, 2011 · 4 comments
Labels
area-core bug The issue in the code or project, which should be addressed.

Comments

@modxbot
Copy link
Contributor

modxbot commented Apr 17, 2011

romain created Redmine issue ID 4434

On a fresh install i created a context and tried to edit its settings (see attachment).
No errors in Revo's logs

@modxbot
Copy link
Contributor Author

modxbot commented Apr 17, 2011

romain submitted:

Forgot to mention MySQL client & server 5.1.49-3

@opengeek
Copy link
Member

opengeek submitted:

I am not able to reproduce this—can someone provide detailed steps to take in the UI to do so?

@netProphET
Copy link
Member

netprophet submitted:

I can reproduce about 75% of the time with the following steps:

  • click on a Resource to get to an Edit Resource (or weblink or symlink) page - it seems to be necessary to start this way
  • click on the web context to go to Edit Context page
  • just before the loading mask goes away, the string 'web' also goes away from the Key field, and the heading of the page becomes "Context: undefined"

I can reproduce this behavior in FF4 and Chrome, Apache on Windows, in both MySQL and SqlSrv installs.

Watching modx.panel.context.js reveals that when this bug occurs, the panel's 'setup' handler (line 91) initiates an ajax request whose success handler is an anonymous function (line 103) expecting it's one parameter, r, to be a response object containing the context's properties, yet it is receiving a representation of the resource tree menu bar instead. Oddly, the request that spawns this success handler checks out as ok.

Further investigation is needed to determine how the success handler could be receiving a response from a seemingly unassociated request.

@splittingred
Copy link

splittingred submitted:

Fixed: fa35fa3

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core bug The issue in the code or project, which should be addressed.
Projects
None yet
Development

No branches or pull requests

4 participants