Add page: Clicking Page Type does nothing in QA
Permalink
Hi,
I have a C5 site, works fine locally.
On our QA server, however, it's suddenly unable to add pages.
I click Add Page, get the window, but when I click the Page Type icon I want, nothing happens (no response at all to the click). I also cannot scroll to the left or right to view all the page types.
Obviously, Javascript is enabled, to open/close the window and such, so that's not the issue. I can edit pages fine.
Any ideas why this would be happening? I could swear it was working yesterday, but am not 100% sure I've added a page in QA.
I've tested in Firefox and Chrome.
I have a C5 site, works fine locally.
On our QA server, however, it's suddenly unable to add pages.
I click Add Page, get the window, but when I click the Page Type icon I want, nothing happens (no response at all to the click). I also cannot scroll to the left or right to view all the page types.
Obviously, Javascript is enabled, to open/close the window and such, so that's not the issue. I can edit pages fine.
Any ideas why this would be happening? I could swear it was working yesterday, but am not 100% sure I've added a page in QA.
I've tested in Firefox and Chrome.
any js errors?
Nope, nothing. Just ran through with Firebug set to "Break on all errors", but nothing shows.
One piece of info, I did recently delete the unused Right Sidebar and Left Sidebar types from my theme in QA. They're still present locally.
I'm going to see if I can restore the entries, but let me know if you know how off the top of your head. :)
I'm going to see if I can restore the entries, but let me know if you know how off the top of your head. :)
Nope, nothing. I just copied the default and named it right_sidebar.php and left_sidebar.php.
Also added a new page type, to see if it would jar it awake... Can see it in list, but still can't select a page type or scroll the list.
Any ideas?
Also added a new page type, to see if it would jar it awake... Can see it in list, but still can't select a page type or scroll the list.
Any ideas?
Fixed!
Found the scroller code is generated inline with the collection by the /concrete/elements/collection_theme.php file.
Looked at the generated HTML for the dialog in Firebug, and lo and behold, a MySQL error:
Sure enough, that table didn't exist, so I just created it based on this file's schema (http://usagi-project.org/redmine/repositories/entry/concrete5/5.4.0/trunk/concrete/config/db.xml?rev=54).
BUT, when I went to add it to my local DB, it said the table already existed.
BUT, locally (Windows), the table is cased as "atTextAreaSettings", instead of "atTextareaSettings".
Arrgh. So it works on Windows, because of the case-insensitivity, but on Linux, blows up.
Is it a bug that the table is created with that case, or is that a Windows feature? I have implemented the MySQL setting that makes table names case-sensitive, so unless Windows camel-cases the table on its own accord, looks like there's a mismatch in code somewhere.
But, WinGrep'ing through, I can't find any mention of atTextAreaSettings (with wrong case).
ANYWAY, hurrah. All's well again.
Found the scroller code is generated inline with the collection by the /concrete/elements/collection_theme.php file.
Looked at the generated HTML for the dialog in Firebug, and lo and behold, a MySQL error:
<b>Fatal error</b>: Uncaught exception 'ADODB_Exception' with message 'mysql error: [1146: Table '(db).atTextareaSettings' doesn't exist] in EXECUTE("select akTextareaDisplayMode from atTextareaSettings where akID = '2'") ' in /home/.../concrete/libraries/3rdparty/adodb/adodb-exceptions.inc.php:78
Sure enough, that table didn't exist, so I just created it based on this file's schema (http://usagi-project.org/redmine/repositories/entry/concrete5/5.4.0/trunk/concrete/config/db.xml?rev=54).
BUT, when I went to add it to my local DB, it said the table already existed.
BUT, locally (Windows), the table is cased as "atTextAreaSettings", instead of "atTextareaSettings".
Arrgh. So it works on Windows, because of the case-insensitivity, but on Linux, blows up.
Is it a bug that the table is created with that case, or is that a Windows feature? I have implemented the MySQL setting that makes table names case-sensitive, so unless Windows camel-cases the table on its own accord, looks like there's a mismatch in code somewhere.
But, WinGrep'ing through, I can't find any mention of atTextAreaSettings (with wrong case).
ANYWAY, hurrah. All's well again.
Bless. You. Renaming table to atTextareaSettings worked.
