function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
dhardingdharding 

Need help with site.com deficiencies.

[UPDATE 6/6/12: I am editing this post as I get responses from support, as to whether the functions in question truly do not exist, or solutions if they do exist, but in a convoluted or hidden manner.]

 

[UPDATE 6/7/12: I had a GoToMeeting session with the VP of Site.Com Development and 3 support team members to go through my list. I have updated the list below with the results of that meeting. I have another meeting with them on 6/8/12 to replicate some of the bugs I discovered.]

 

I am frustrated beyond belief in that none of my support tickets are being replied to, even after 2 business days, there is virtually no documentation for this site.com beta product, and I am hitting serious brick walls with respect to functionality.

 

If any of you have discovered workarounds to any of these problems, I would greatly appreciate any sage words of wisdom. I can be contacted directly at dharding@illinois.edu

 

Some of the following are merely annoyances, but some are absolute showstoppers. I’ve bolded items that are critical, i.e., in order to fully port our existing site into site.com, we need to find a workaround.

 

  1. (CONFIRMED IN GOTOMEETING ON 6/7/12: FUNCTIONALITY DOES NOT EXIST BUT IS BEING CONSIDERED FOR FUTURE RELEASE) No versioning, rollback, or undo. Once something is deleted it is gone forever.

  2. (CONFIRMED IN GOTOMEETING ON 6/7/12: FUNCTIONALITY DOES NOT EXIST BUT IS BEING CONSIDERED FOR FUTURE RELEASE) No way to limit people's access to specific pages, let alone certain content blocks on those pages. All contributors and publishers have access to all pages. So if you have contributor access, you can edit all the content blocks on all pages in the site.

  3. (CONFIRMED IN GOTOMEETING ON 6/7/12: FUNCTIONALITY DOES NOT EXIST AND THIS IS BY DESIGN; IS NOT CONSIDERED A PROBLEM) Site.com does not have any check-in/check-out mechanism for content that is being edited. It does not check to see whether another user has a page or content block open for editing. It blithely allows multiple people to have the same content open simultaneously and the last one closed overwrites the others. This is going to make distributing the site content editorial responsibilities more dangerous than if this were a real CMS.

  4. (CONFIRMED BY SUPPORT ON 6/5/12: FUNCTIONALITY DOES NOT EXIST) There does not appear to be any way to copy a page or template from one “site” to another. So if I clone the site in order to do major overhauls or unpublished development (because I don’t want to screw up the existing site) and I get a page or pages the way I want them, there is no way to port those pages back into the original site.

  5. (CONFIRMED BY SUPPORT ON 6/5/12: FUNCTIONALITY DOES NOT EXIST) There does not appear to be a way to archive, save, or export a single page or resource. You can only export an entire site en masse. This, combined with #4, means that it is impossible to pull content from an older page or from a different site.

  6. (CONFIRMED IN GOTOMEETING ON 6/7/12: FUNCTIONALITY DOES NOT EXIST BUT IS DEFINITELY BEING DEVELOPED. FOR NOW I WILL HAVE TO HARDCODE ALL OF THE MENUS AND WILL NOT BE ABLE TO USE THE SITE MAP TO REARRANGE PAGES WITHIN THE MENU) The navigation menu object appears to only support physical pages. There is no  provision to allow for menu items that are any of the following:
    1. A link to an external site
    2. An anchor link on a page, e.g., the submenu items being links to sections within the same physical page
    3. A menu item that is not a link, but rather an organizing “container” for more elements.
    This means either changing our entire menu structure to remove any elements that are not pages, or forgoing the built-in menu object and hardcoding the menus, which completely defeats the point of having a CMS and being able to move pages around on the fly.

  7. (CONFIRMED IN GOTOMEETING ON 6/7/12: DEFINITELY A SITE.COM BUG, BUT COULD OBTAIN NO INFORMATION ON WHAT "USE OTHER MAP" MEANS) The default Menu Source for the menu object is “Use Site Map”. There is another option called “Use Other Map”, but there is nothing in any documentation that explains what that option means. Moreover, selecting that option immediately generates a system error telling you to file a support ticket. (unimplemented feature perhaps?)

  8. (CONFIRMED IN GOTOMEETING ON 6/7/12: SITE.COM BUG. NEEDS FURTHER DEBUGGING) Many objects display correctly in Site.com ONLY if they are created natively within the WYSIWYG environment. If you import them as HTML code, depending on the complexity of the object, all you get is a block of whitespace with a border. If you preview the page, it looks correct to the end user, but you have no way of using WYSIWYG tools to tweak it. You have to manually edit the HTML and CSS code.

  9. (CONFIRMED IN GOTOMEETING ON 6/7/12: SITE.COM BUG. NEEDS FURTHER DEBUGGING) Positioning and sizing within the WYSIWYG editor is seriously off at times. What you ultimately see published is not what you see within the CMS.

  10. (CONFIRMED IN GOTOMEETING ON 6/7/12: SITE.COM BUG. NEEDS FURTHER DEBUGGING; I WAS TOLD THAT SITE.COM SHOULD NEVER BE ALTERING CUSTOMER-SUPPLIED CSS; I TOLD THEM IT ISN'T EVEN CLOSE) Stylesheet importing: sometimes, if Site.Com encounters a tag that it does not understand, e.g., the “filter” CSS tag, it omits it along with any CSS after it for that element, even if the subsequent CSS is valid. This means manually checking CSS to make sure things are not dropped. This also precludes importing a fresh version of the stylesheet.

  11. (SEE #10) Site.com re-renders CSS when you save, changing the syntax of some markup, regardless of how you have the markup specified. Site.com has taken the Microsoft “we’ll redo it for you” approach.

  12. (CONFIRMED IN GOTOMEETING ON 6/7/12: SITE.COM BUG. NEEDS FURTHER DEBUGGING) When you duplicate a template that has child templates, it ONLY duplicates the parent, not the children. And since templates cannot be copied from one parent template into another, you are forced to manually recreate those child templates by hand.

To be blunt: for 5 figures a year, the current incarnation of site.com is is woefully and pitifully inadequate.

dhardingdharding

Updated based on my meeting yesterday.
bryan.andersonbryan.anderson

Bugs 10 and 11 have existed more several months if not since the beginning of Site.com. It makes it very difficult to make use of some CSS frameworks since they tend to contain more complex CSS that Site.com's CSS parser seems unable to handle properly.

 

Best workaround for now is to upload the stylesheet with the complex CSS as a file and add a reference to it in the Template or page Header. The major drawback is that the CSS will not load in the editor and you cannot adequately see how the page may look until previewing the page. Maintenance can be painful as well since you cannot edit the CSS directly in the Site.com editor.
dhardingdharding
What I don't get is why Site.com is parsing and rewriting user CSS to begin with. That's been an industry standard practice to avoid for well over a decade, since the earliest versions of Microsoft Frontpage. There are entirely too many areas where Site.com doesn't know to get out of the user's way, and the end result is aproduct that currently cannot handle complex or sophisticated websites. We thought that by buying a CMS we would be able to distribute site maintenance across more people, but the result is exactly the opposite. With all the bugs currently in the product, we dare not open it up until the product is out of beta and stable. It shows some long-term promise, but is nowhere near ready as a commercial product. That's just my personal opinion based on firsthand experience.
bryan.andersonbryan.anderson

I would guess that it needs to parse the CSS to allow it to be edited via the Styles editor in Site.com Studio.

 

An interesting quirk I cam across when first working with Site.com back when it was Siteforce was attempting to create a class with name "description" but it kept getting truncated. I eventually realized that it was behaving this way because the word "script" was in "description". I would guess it is to prevent injection attacks, but was annoying. Also, with URL redirects I found there are some reserved words that cannot be used, but they are not documented, which became a problem for one of the clients I was working with.

 

I agree that Site.com has a lot of potential to be a great product, but it has a long way to go. I only hope that much needed functionality becomes added in the near future.
dhardingdharding

Parsing on input I get, in order to make things fit the fields in the GUI, but rewriting universally on output I don't, especially in light of some of the absolutely unneccessary changes that the rewrite does:

 

Moving the !important CSS parameter from one line to another (which can really hose things)

 

Changing color definitions from lowercase to uppercase.

 

Changing color definitions from 3-digit to 6-digit format.

 

The more you try and rewrite on export, the more things that can potentially go wrong. If the concern is "making things fit" into the site.com GUI, rather than rewriting end user's code universally, make the input filter more robust and then only overwrite elements that have been changed within the GUI.

 

Sure it's easier to just rewrite EVERYTHING on save/close, but that approach is what has gotten us into the current predicament, where CSS treatment is bug-ridden.

 

PS: one thing I discovered, that is similar to your quirk, but again, not documented anywhere:

 

If you have any CSS element named .clear, this is a BAD thing, as that is apparently a reserved word by Site.com. Any code that has that within it will not render in the WYSIWYG editor. You can still edit the raw code and it previews fine in the browser, but you just get a small empty box with a border in the editor itself. Edit the CSS definition to make it .clearboth instead of .clear, and voila! it renders fine in the editor.

 

It's not a bug, it's a "feature." ;)