Re: folder plugin JS error after 2.4.0 to 3.1.0 upgrade
Seeing it on many backend pages, for example EditResource. Simply when loading the page. Using Chrome.
Where does the cw object originate?
Perhaps it is relying on a JS file in the theme? Files in /local/interface/{theme}/include? Those files obviously would not have been updated with the CWIS version upgrade.
Re: folder plugin JS error after 2.4.0 to 3.1.0 upgrade
In 2.4.0, line 292 of StdPageStart.html was: <script type="text/javascript" src="<?PHP $AF->PUIFile("CW-Base.js"); ?>"></script> So, either your custom interface was based on something older than 2.4.0, or the above line was deleted in the customization process.
From the error above, it looks like maybe jQuery isn't being pulled in. Do you have <?PHP $AF->PUIFile("jQuery.js"); ?> near the top of your StdPageStart?
Alternately, do you have <script type="text/javascript" src="include/SPT--jQuery.js"></script> ? CWIS 2.0.0 through 2.0.4 used that location.
Could you post the first 30 lines or so of your StdPageStart ? Unless the customization has been very extensive, that should help me track down which version of CWIS it was based on, which should in turn help me to replicate (at least some of) the issues you're seeing.
Incidentally, these kinds of difficulties with editing StdPageStart in custom interface were what motivated us to revise our CSS system to support *-Override.css and *-Override.js files in local interfaces, and also motivated the creation of the NavEditor plugin. Using those mechanisms, it should no longer be necessary for the majority of sites to customize StdPageStart, thus avoiding these kinds of issues on future upgrades.
Re: folder plugin JS error after 2.4.0 to 3.1.0 upgrade
Ah. Per Ed's comment on Another upgrade issue - metadata field editor Access tab, the local/interface tree should only contain code that has been specifically customized for your site. The various *.js files in interface/*/include definitely qualify as "backend pages" in this regard.
I would recommend pruning files that were not modified out of your local/interface/{theme} in the 2.4.0 site prior to upgrading it to 3.1.0 to minimize these issues.
Could you provide a bit more information on where you're seeing this issue, what actions preceeded it, and which browser you're using?
I was unable to replicate this error when I use Firefox or Chrome to:
Seeing it on many backend pages, for example EditResource. Simply when loading the page. Using Chrome.
Where does the cw object originate?
Perhaps it is relying on a JS file in the theme? Files in /local/interface/{theme}/include? Those files obviously would not have been updated with the CWIS version upgrade.
It's coming from interface/default/include/CW-Base.js . Since CWIS 2.3.0, this file has been included as part of StdPageStart.html.
Do you happen to know what version of CWIS your custom theme was based on? Is it older than 2.3.0 ?
It predates me, but I believe it is all based on 2.4.0.
Updating CW-Base.js got me further; now I get:
Uncaught TypeError: undefined is not a function index.php?P=Advanced&Editing=1:433
$(".Limits .Header .Main").toggleHtml(
In 2.4.0, line 292 of StdPageStart.html was:
<script type="text/javascript" src="<?PHP $AF->PUIFile("CW-Base.js"); ?>"></script>
So, either your custom interface was based on something older than 2.4.0, or the above line was deleted in the customization process.From the error above, it looks like maybe jQuery isn't being pulled in. Do you have
<?PHP $AF->PUIFile("jQuery.js"); ?>
near the top of your StdPageStart?Alternately, do you have
<script type="text/javascript" src="include/SPT--jQuery.js"></script>
? CWIS 2.0.0 through 2.0.4 used that location.Could you post the first 30 lines or so of your StdPageStart ? Unless the customization has been very extensive, that should help me track down which version of CWIS it was based on, which should in turn help me to replicate (at least some of) the issues you're seeing.
Incidentally, these kinds of difficulties with editing StdPageStart in custom interface were what motivated us to revise our CSS system to support *-Override.css and *-Override.js files in local interfaces, and also motivated the creation of the NavEditor plugin. Using those mechanisms, it should no longer be necessary for the majority of sites to customize StdPageStart, thus avoiding these kinds of issues on future upgrades.
Sorry; CW-Base.js was there and was being referenced; what I did was to replace that file with the newer file under the default theme.
Ah. Per Ed's comment on Another upgrade issue - metadata field editor Access tab, the
local/interface
tree should only contain code that has been specifically customized for your site. The various *.js files in interface/*/include definitely qualify as "backend pages" in this regard.I would recommend pruning files that were not modified out of your local/interface/{theme} in the 2.4.0 site prior to upgrading it to 3.1.0 to minimize these issues.