feministgeek
offlineMember
Al or Gerry,
I'm setting up a Mirage-based site for a non-profit to edit in-house using Contribute CS5 software. All the pages were created with a Dreamweaver CS5 template.
As soon as Contribute creates a draft of a page for editing, the corners of the column heading move down - and stay there, like the image on this page:
http://dsf.edu/mirage-contribute.html
It's on the non-profit site.
Can you suggest a way to fix this? Thank you!
Sinclair
offlineMember
Could you put the page online and post the url - it would be easier to troubleshoot.
susank
offlineMember
Thanks for replying Sinclair.
http://dsf.edu is online - and works fine on the web.
The problem is for folks at DSF to use Adobe Contribute CS5 software (http://www.adobe.com/ap/products/contribute.html) to edit their site in-house. I took a screen shot to show what happens when I open a page to edit it in Contribute.
http://dsf.edu/mirage-contribute.html
I've used Contribute (with Dreamweaver-built sites) & PVII css templates for years, and never had a problem like this.
-Susan (aka feministgeek)
Sinclair
offlineMember
I'm afraid I don't know Susan - all seems to be ok as far as code and css goes - hopefully Al or Gerry will be able to help!
susank
offlineMember
Thanks for checking the code & css, Sinclair. I'm not sure how many other people who use PVII products also use Adobe Contribute software for their end-users for in-house editing, but this is a serious issue for those of us that do.... I hope Al or Gerry will be able to help too!
Al Sparber
offlinePVII Team
Hi Susan,
Not sure there is a problem. If the actual page renders fine on the Web, then all it means is that Contribute is just as poorly programmed as Dreamweaver in terms of how it supports CSS in its design view. Am I clear on this in that the only problem is how the page looks inside Contribute?
susank
offlineMember
Am I clear on this in that the only problem is how the page looks inside Contribute
Al, the pages look fine when Contribute displays them by browsing to them. The problem is how the pages render when Contribute creates a draft copy of a page for editing by any level of Contribute user.
Al Sparber
offlinePVII Team
Al, the pages look fine when Contribute displays them by browsing to them. The problem is how the pages render when Contribute creates a draft copy of a page for editing by any level of Contribute user.
Hi Susan,
If the problem is only in Contribute, then it's not a problem. We have no control over flaws in Dreamweaver or Contribute Design View. What am I missing?
susank
offlineMember
I hear what your saying, Al....
The header jpgs pop down in place in Contribute edit mode.
http://dsf.edu/mirage-contribute.html
My knowledge of css is functional, beginning. Is there any way to modify the code so this won't happen? (I need to use Dreamweaver/Contribute for another site & I'm thinking WordPress may be the way to go.) Thanks.
susank
offlineMember
Here is a page from the site edited in Contribute:
http://dsf.edu/students/fubar.html
This is the original page copied to create it:
http://dsf.edu/students/cmsprogram.html
Thanks very much, Al!
Al Sparber
offlinePVII Team
Here is the column header wrapper DIV in the fubar page (touched by Contribute):
<div class="column-heading-wrapper">
<p style="margin-top: 0; margin-bottom: 0;"> </p>
<div class="column-heading">
<h1 style="margin-bottom: 0"> </h1>
</div>
</div>
And here is the same DIV in the default, untouched page:
<div class="column-heading-wrapper">
<div class="column-heading">
<h1> </h1>
</div>
</div>
And here is the same DIV, as we deliver it in a Mirage page:
<div class="column-heading-wrapper">
<div class="column-heading">
<h1>Column Heading</h1>
</div>
</div>
The column-header-wrapper DIVs are at the top of each of the 3 columns and each one contains bad code. I imagine that you would need to make those headers editable, but the editable regions would need to wrap the text, so that a user is not able to add tags. Either that or you need to educate the client that they cannot press "Enter" and must only change the text in the header. The only element allowed inside that container is a level 1 heading. Your working page has one, but it's empty. If you want them to be empty then that's fine, but you must not enable them as editable.
The same mistake (and probably worse) would happen in any content management system.
susank
offlineMember
I think it's Contribute.... I cleaned up the column headers with a 1-letter (black) level 1 heading, non-editable regions. That cleaned up the issue with the first fubar page.... http://dsf.edu/students/fubar.html
However http://dsf.edu/students/fubar2.html , touched by Contribute, has bad code for all the columns, like
<div id="column-1">
<div class="column-heading-wrapper">
<p style="margin-top: 0; margin-bottom: 0;"> </p>
<div class="column-heading">
<h1>d</h1>
</div>
Thanks for your troubleshooting help, Al.
Al Sparber
offlinePVII Team
That does not make sense Susan. What you are implying is that on its own, Contribute adds:
<p style="margin-top: 0; margin-bottom: 0;"> </p>
<div class="column-heading">
<h1>d</h1>
That's not possible. It cannot add a paragraph - and even if it could it could not possibly add an inline style attribute. That would be absolutely impossible for Adobe to engineer.
That code is getting put in there by the user. Can you give me the exact steps to reproduce?
Sinclair
offlineMember
It seems others are experiencing the same thing - I googled and found what may be a fix.....
http://forums.adobe.com/message/184006#184006
HTH
Al Sparber
offlinePVII Team
That solves one mystery - but it doesn't address where the paragraph came from in the fisrt place. I'm gathering that Susan does not want to use the headings, so making them empty H1 tags with an "nbsp;" and then making sure it is in a non-editable region would prevent any problems.
Sinclair
offlineMember
The fubar2 page is littered with them - the menu ,the content - I wonder if Susan and contributers had this all working prior to CS5 and if so could they revert back? It might be worth looking at the likes of Perch, http://grabaperch.com/ if your contributers need to add pages, or Pulse, http://pulsecms.com/ or similar if a lesser degree of editing is all that's required!
susank
offlineMember
It seems others are experiencing the same thing - I googled and found what may be a fix.....
http://forums.adobe.com/message/184006#184006
HTH
Thanks, Sinclair. I missed this one (there are a lot for Contribute that are unanswered.) I'll give it a try.
susank
offlineMember
That solves one mystery - but it doesn't address where the paragraph came from in the fisrt place. I'm gathering that Susan does not want to use the headings, so making them empty H1 tags with an "nbsp;" and then making sure it is in a non-editable region would prevent any problems.
Initially, I put the "nbsp;" in the left and right H1 tags for a non-editable region. The center column was supposed to be editable, but that seems to be more trouble than it's worth for the in-house editors.
susank
offlineMember
Unfortunately the site was created in Dreamweaver CS5....
Thanks, I will check the other options you suggest!
susank
offlineMember
Thanks HTH
Setting was already for using standard <p> tags.
Contribute editing works if end-user editing is restricted to text editing & formatting -i.e., no image (or table) insertion. - not too helpful
http://dsf.edu/students/fubar3.html
Al Sparber
offlinePVII Team
So, Contribute alters code in non-editable regions?
susank
offlineMember
So, Contribute alters code in non-editable regions?
Not exactly, Al. There were lots of actions to fix this problem, so it's not totally clear.
CSS files were inadvertently "checked in" at one point, meaning more than just end-users with admin status could modify them, i.e., publishers & writers who had permission to add images as well as edit text and format based on the site's style sheets. Then Contribute altered code related to columns in non-edited regions.
When we "checked out" those files to correct this, admin users actions no longer modified code in non-editable regions (using Contribute). But actions by users with a "publisher" role still modified code in non-editable regions. Unfortunately, changing Contribute's login key for an end-user publisher with only one email address did not correct this. As a tentative solution, the end-user has an admin role and can edit with Contribute. Clearly, a few more adjustments need to be made.
Thanks to you & HTH for your help!
I struggled with this issue as well and finally found a solution that fixed the problem very easily! Contribute 5 edits by my client were editing my locked code - very frustrating. These are the steps to fix:
I'm using Contribute 3, so it may be a little different in 5
* Log in to Contribute
* Top menu bar: Edit > Administer web sites > (Web site name)
* Users and roles option > Click the "Edit role settings" button
* A dialogue box pops up > click the "Editing" option
* Now look where it says "paragraph spacing"
* Does it say One Line? If so, change this to Two lines
* Click "OK" and "Close"
Once my client made this change, the problem was solved. Hope it helps you!
Kristi
Al Sparber
offlinePVII Team
Excellent Kristi! Thanks for sharing.
You must log in to post.
©2013 Project Seven Development
Create Responsive Mobile-Ready Layouts Instantly
Includes Drop Menu Magic: the first fully-automated responsive menu tool for Dreamweaver.
Boardroom Home | Boardroom Examples | Affinity Home
Your images deserve the very best...
