5.3.1 upgrade - edit bar disappeared

Permalink
Like title suggests, the upgrade seemed to go well until I tried to edit a page. I was in dashboard and I have to double click on a file to see the menu, then select visit page and then the page appears without the edit bar at the top! Any ideas?

 
ringo replied on at Permalink Reply
when i go from dashboard to 'visit page' then i see the page but with no edit/design/permissions buttons. There is absolutely no code in the source files for this! The first tag after the body tag is my first container div! Where is this code meant to come from? Why is it missing?
simpled replied on at Permalink Reply
Clean install with 5.3.1
On site page, I have Object id #158 Object id #151 Object id #183 Object id #185 Object id #187 Object id #188 Object id #189 Object id #190 Object id #186 Object id #192 Object id #193 Object id #194 Object id #195 Object id #196 Object id #197 Object id #198 Object id #199 Object id #200 Object id #201 Object id #202 Object id #203 Object id #204 Object id #205 in the top of the page.
When trying to log in, full blank page.

not good
ringo replied on at Permalink Reply
until i can be sure the builds are stable.. the last 2 updates have broken my site. I think i will have to stay on this version until i can be confident that a new roll out will be stable enough to release.
Maynar replied on at Permalink Reply
Maynar
Backups?
Don't you make backups before you upgrade? I mean it's the most obvious solution to "awry" upgrades.

To upgrade your Concrete5 installation from a previous version, do the following (note, this will only work when upgrading from versions LATER than Concrete 5.0.0a4).
    * Archive your database and your web root...just in case something should go awry.
    * When ready, replace your "concrete" directory with the "concrete" directory contained in the latest version downloaded from SourceForge.
    * Go to http://www.yoursite.com/index.php/tools/required/upgrade (Note: if this does not work, tryhttp://www.yoursite.com/index.php/tools/required/upgrade.php)...
    * Make sure to follow any pre-upgrade instructions (for example, Concrete5.0.0a4 requires a jobs/ directory be created in your webroot.)
    * Finally, when ready, click the Upgrade button.


I mean the builds are as stable as they can be I guess. I mean the developers (should) test it in anyway they can and everybody can miss a bug. There are so many possible way things can break down on different servers.

So backup! and if it goes wrong restore the backup...
simpled replied on at Permalink Reply
I think this upgrade system needs to be improved as it does create problems in each release.
I tend to do clean install with each new release, and even with 3.1, on a clean install there is a problem.

I will suggest to keep release number as
5.3 STABLE
5.4 STABLE
5.5 STABLE

Any 3.1, 3.2 etc should contains minor bug fix and not affect the overall system.

Having to overwrite the full set of folder is not user friendly.

just my 2p...
ringo replied on at Permalink Reply
but that isn't my point really. But it is more annoying to have to roll back things. It wastes time that i could be developing new things. I am just curious to know if anyone else is getting the same problems.
Maynar replied on at Permalink Reply
Maynar
Well I am quite new to Concrete5, but so far I recon they have used that upgrade system?
For example: New file manager in 5.3 and improvements on it in 5.3.

Nothing is perfect and humans make mistakes. Bugs are easily missed. That pretty much all I can say. And if you don't want to go through the hassle of upgrading yourself with the possibility it goes wrong. Let them host your website. Ta-da... all done. Just costs some money.
ringo replied on at Permalink Reply
I run a test site aswell as the main one i am developing and have all the same errors on that build also.

I noticed another issue. In my sitemap page if i click on a file and select design/permissions etc the css all seems to be broken on the page. There must be a problem with the header_required files.
ringo replied on at Permalink Reply
so please don't get me wrong here im not bashing the whole thing, i just find it frustrating that it always seems to break for me on upgrades. I still love the system and the guys do a great job so obviously this isn't a personal attack here!
simpled replied on at Permalink Reply
and we all appreciate the work by the developers....

Feedback is always good, only way to improve
Maynar replied on at Permalink Reply
Maynar
CSS (lay-out & visible) issues? A picture say more than a thousand words. Attach a screen shot as I am sure this can help developers. Go to the bug tracker and report a new bug.

About the edit bar. If I create an account that can manage pages, but not all, and I visit a page I can't edit the edit bar is not there. Maybe this is the case with yours as well or are you Super User? As far as I know there are no limits to the Super Users "powers".
frz replied on at Permalink Reply
frz
Hey guys,

5.3.1 works just fine for me, and everyone who looked at it in beta.

If you'd like to join beta, we're more than happy to have you. Maynar is right tho, there are countless permutations of system configurations out there and its really impossible for us to ever promise a perfect upgrade path for everyone. As with commercial software as well, the benefit of upgrades is new/fixed features, the downer - you're changing a system you've configured to work, so risk is involved.

I would love to actually solve your problems with it, have you already cleared your site cache directory and your browser cache?
ringo replied on at Permalink Reply
hi frz, thanks for getting back to me on this.

system specs as follows:

PHP version 5.2.9
MySQL version 5.0.67

This is running on a live hosting server at the moment. Everything was fine up until the upgrade.

I have tried the same thing on two sites and it is the same issues. I run a test site just to make sure things are ok.

thanks
frz replied on at Permalink Reply
frz
operating system?
ringo replied on at Permalink Reply
running on a linux server. all caches cleared also.

It appears that the javascript/css is not displaying the edit bar. All i have is a section of empty space.

Does the javascript dynamically add the code after the body tag for the edit bars?
andrew replied on at Permalink Reply
andrew
When using the css() and javascript() functions that are contained in the Html Helper, we had been passing simple strings back to the addHeaderItems() call. Now we're passing objects that, when printed, get printed as javascript or css tags, using PHP5's __toString method.

Of course, if html() or css() has been overridden locally those overridden methods may not work.

If you wouldn't mind giving me edit access to one of your tests site's I'd appreciate it - since there are a few others having this issue.
mikeb replied on at Permalink Reply 1 Attachment
mikeb
Hi,

I loaded up a clean install of 5.3.1 on my server just now and got the following error (see attached screenie) where the edit bar should be. This was not an upgrade but an install from scratch.

I have a previous version C5 install on the same server from a couple of days ago and this works fine. I can give you access to the VPS if you need it.

CentOS Server

cheers,

Mike
mikeb replied on at Permalink Reply
mikeb
That bunch of objects across the top of the screen appeared on the very first screen after successful install of the CMS,

cheers,

Mike
ringo replied on at Permalink Reply
The first thing I did was go into my header page which is basically one modified from the original theme. It calls the header_required elenent.

Please note:

The call to the header_required code was near the top but i moved it to the very last thing before the </head> tag.

This fixed the problem on some pages!

Another observation is that the only other pages where this is broken are pages containing the slideshow block.

I think there is a conflict somewhere in the javascripts for all this.

Hope this helps.
andrew replied on at Permalink Reply
andrew
Could I get that access to the test server?
andrew replied on at Permalink Reply
andrew
Which doesn't apparently (or always?! sometimes?) honor __toString called automatically on objects - even though this has been around since the introduction of PHP 5 (or so I thought).

Sigh.

Here is a fix. Open concrete/helpers/html.php

Where you see "return $css" and "return $js"

replace those with

"return $css->__toString();"

and return $js->__toString();

Meanwhile we will replace the version of concrete5 that is on SourceForge for others running 5.1.x.

This is going to cause problems for us down the line given some of the JavaScript and CSS caching that we want to do (which is why we're using these objects in the first place) but in the meantime it should fix the problem. Let me know regardless.
ringo replied on at Permalink Reply
so this shouldnt be an issue?
andrew replied on at Permalink Reply
andrew
I think the patch above should fix the issue - hopefully. Why it's happening, I'm not sure. PHP should output a string instead of the Object #whatever
ringo replied on at Permalink Reply
i think it was another user who was getting the objects being printed. I am missing the edit bars!
andrew replied on at Permalink Reply
andrew
Heh, tough to keep track ;)

So the issue isn't resolved when you clear your web browser's cache and refresh?
ringo replied on at Permalink Reply
Some of the issues were resolved when i moved the call to the header_required file to the bottom, just before the </head> tag.

This fix now works on all pages except for the pages containing the slideshow block!

It HAS to be javascript related for sure.
elyon replied on at Permalink Reply
elyon
Thanks Andrew, that fix solved my problem.

Here was the original error I was experiencing that was freezing up the Javascript on the page:

Error:
name: TypeError
message: Statement on line 371: Cannot convert undefined or null to Object
stacktrace: Line 371 of linked scripthttp://localhost/pbc/concrete/js/ccm.dialog.js...
imgLoader.src = jQuery.fn.dialog.loaderImage;
... Line 19 of linked scripthttp://localhost/pbc/concrete/js/jquery.js...
function(){this.call(document,o)}
... Line 12 of linked scripthttp://localhost/pbc/concrete/js/jquery.js...
function(G,K,F){var E,H=0,I=G.length;if(F){if(I===g){for(E in G){if(K.apply(G[E],F)===false){break}}}else{for(;H<I;){if(K.apply(G[H++],F)===false){break}}}}else{if(I===g){for(E in G){if(K.call(G[E],E,G[E])===false){break}}}else{for(var J=G[0];H<I&&K.call(J,H,J)!==false;J=G[++H]){}}}return G}
Line 19 of linked scripthttp://localhost/pbc/concrete/js/jquery.js...
function(){if(!o.isReady){o.isReady=true;if(o.readyList){o.each(o.readyList,function(){this.call(document,o)});o.readyList=null}o(document).triggerHandler("ready")}}
Line 19 of linked scripthttp://localhost/pbc/concrete/js/jquery.js...
function(){document.removeEventListener("DOMContentLoaded",arguments.callee,false);o.ready()}
...

Adding ->__toString() in the HTML helper solved this problem on my local server.
andrew replied on at Permalink Reply
andrew
Do you mind giving out access to the VPS?
arcanepain replied on at Permalink Reply
arcanepain
Hi Andrew,

Just to let you know that js/css -- 'toString' fix worked for me! Edit bar now appearing on pages (even those with the Slideshow block) and File Manager working as expected again (before, Edit did nothing, needed to double-click for the context menu, 'Properties' returned unstyled/static pages, etc...).

Cheers
ringo replied on at Permalink Reply
I tried this fix even thought it was meant to be for a different PHP version but it fixed the problem.

Thanks so much!
andrew replied on at Permalink Reply
andrew
We just released a new version of c5 to SourceForge. The only changes are the __toString() stuff mentioned in this thread, and a fix for the "replace file" bug found elsewhere.

if you've applied these patches directly you don't need to upgrade, but I thought I'd mention it, since it seems like this stuff is affecting a number of people.
mikeb replied on at Permalink Reply
mikeb
"Do you mind giving out access to the VPS? "

Sorry Andrew, was that for me?

Also - applied the fix and I'm now getting the following error on a blank page when I try to run the app:

Fatal error: Function name must be a string in /var/www/vhosts/ckghosting.com/httpdocs/clients/writersjournal/cc51WritersJournal/concrete/helpers/html.php on line 59

hope that helps,

cheers,

Mike
frz replied on at Permalink Reply
frz
can you download and try the newer release we launched around lunch? 5.3.1.1
mikeb replied on at Permalink Reply
mikeb
...my mistake. I went back and did a sanity check and noticed that I had managed to get the syntax wrong. Tired programmer - sorry if I caused a panic! Everything is working fine now,

cheers,

Mike
Brent replied on at Permalink Reply
... but this was an easy fix. The problem was that there was a JavaScript error that was being caused by a missing variable related to breadcrumb navigation. I enabled breadcrumb navigation in the sitewide settings, then disabled it. This apparently created the variable so that the error no longer occurs. Works perfectly now.

If anyone is having this problem still, give this a shot.
0NFT0 replied on at Permalink Reply
I have the same problem, the edit bar is blank on a clean install. After reading ringo's fix (moving the call to the header_required element) I decided to give it a shot.

My header.php looked like this:

<?php  Loader::element('header_required'); ?>
<script type="text/javascript" src="LINK"></script>
<script type="text/javascript" src="LINK"></script>
</head>



I changed it to:

<script type="text/javascript" src="LINK"></script>
<script type="text/javascript" src="LINK"></script>
<?php  Loader::element('header_required'); ?>
</head>


And the edit bar works! But my scripts don't anymore... (the ones in the code above)

Putting the call to header_required back up above the scripts makes the edit bar go away, but my scripts work again.

No idea on this one. I have version 5.3.1.1
0NFT0 replied on at Permalink Reply
Anyone? The above problem isn't fixed.
ScottC replied on at Permalink Reply
ScottC
<?$cp = new Permissions($c);
?>
<?php // Loader::element('header_required'); ?>
<?if ($c->isEditMode() ||$cp->canWrite() || $cp->canAddSubContent() || $cp->canAdminPage()){      
?>
<?=('<script type="text/javascript" src="LINK"></script>');?>
<?=('<script type="text/javascript" src="LINK"></script>');?>
<?php  Loader::element('header_required'); ?>
<?}else{?> 
<?php  Loader::element('header_required'); ?>
<?=('<script type="text/javascript" src="LINK"></script>');?>
<?=('<script type="text/javascript" src="LINK"></script>');?>
<?}?>

What this is doing is checking as well as I know to see if someone that is viewing the page has the edit bar up.

It spits the stuff out in the correct order for you. There you go.
graffi replied on at Permalink Reply
the above code doesn't help my problem. I'm using 5.3.2

I'm adding a simple lightbox script. When placed above
<?php  Loader::element('header_required'); ?>

the lighbox doesn't work (images open in their own window).

When I place the code beneath, as below
<?php  Loader::element('header_required'); ?>
<!--  lightbox scripts start here //-->
<script type="text/javascript" src="http://www.graficalicus.com/testCMS/themes/keepitsimple/lightbox/js/prototype.js"></script>
<script type="text/javascript" src="http://www.graficalicus.com/testCMS/themes/keepitsimple/lightbox/js/scriptaculous.js?load=effects,builder"></script>
<script type="text/javascript" src="http://www.graficalicus.com/testCMS/themes/keepitsimple/lightbox/js/lightbox.js"></script>
<!-- end lightbox //-->
</head>


the lightbox works, but the edit bar across the top is gone (there's a space for it, but it's empty). Refresh, reload, dumped the cache, IE & FF: no go.

Definitely a js conflict (in IE, I get the error
'&.browser.msie' is null or not an object


Any and all help is appreciated - -
graffi replied on at Permalink Reply
Turns out the problem is a conflict between jQuery.js & prototype.js: they both use '$', so short of rewriting one or the other (and all the dependant scripts to change the variable) I've decided to use a jQuery-based lightbox and am having no more problems.
karenalenore replied on at Permalink Reply
karenalenore
which one did you decide on instead?
nbruley replied on at Permalink Reply
I also loose the header when I add
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>


error: Uncaught TypeError: Cannot read property 'loaderImage' of undefined

I'm still unclear on how to fix this... any suggestions? I suppose I could use the default Concrete5 jquery (?) but that takes longer to load I understand.

I'm running 5.4.2.1

Thanks.

EDIT : If I add the jquery in header.php instead of in the add to header property of the page it resolves the issue.