If you directly access a url to a page without already being in edit mode the On Page Edit boxes does not show up (i.e. /system/cms/#context=epi.cms.contentdata:///2121). It does seem to work if you have cleared your cache and/or have the developer toolbar open i Chrome, but not if you open a new window or another browser for example. It also seems to work if you have to login before you get to view the page (we use Windows authentication so the user gets access directly). If you go to advanced editing and back the boxes do show up. Or if you simply add an extra parameter to the url to trigger a hash change they also show up.
There seems to be a timing issue or something in widgets.js where some of the logic of attaching the edit boxes are controlled. I have debugged widgets.js and sometimes the iframe that is used (which contains the markup of the actual page you are about to view) to look for the edit markup is empty and therefore no overlay is added.
This is a showstopper for the customer I work for because we have quick menus that triggers creation of a new page programatically and then redirects the user to edit mode for that page. When this page is loaded the user has to click advanced editing and back to be able to edit the page which is unacceptable and is stopping us from launching the site.
Does anyone have a workaround for this or experience the same? I am running version 7.6.3 of the UI and had the same issue earlier with version 7.5. I have also validated this issue on another site so it seems to be a bug.
If you directly access a url to a page without already being in edit mode the On Page Edit boxes does not show up (i.e. /system/cms/#context=epi.cms.contentdata:///2121). It does seem to work if you have cleared your cache and/or have the developer toolbar open i Chrome, but not if you open a new window or another browser for example. It also seems to work if you have to login before you get to view the page (we use Windows authentication so the user gets access directly). If you go to advanced editing and back the boxes do show up. Or if you simply add an extra parameter to the url to trigger a hash change they also show up.
There seems to be a timing issue or something in widgets.js where some of the logic of attaching the edit boxes are controlled. I have debugged widgets.js and sometimes the iframe that is used (which contains the markup of the actual page you are about to view) to look for the edit markup is empty and therefore no overlay is added.
This is a showstopper for the customer I work for because we have quick menus that triggers creation of a new page programatically and then redirects the user to edit mode for that page. When this page is loaded the user has to click advanced editing and back to be able to edit the page which is unacceptable and is stopping us from launching the site.
Does anyone have a workaround for this or experience the same? I am running version 7.6.3 of the UI and had the same issue earlier with version 7.5. I have also validated this issue on another site so it seems to be a bug.