Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Advanced Search

daniel vimont

Member
  • Content Count

    15
  • Joined

  • Last visited

  • Days Won

    2
  1. ...But, my original question only focused on the development lifecycle for individual pages, and as far as I'm concerned, this issue has been successfully addressed (assuming the new "copy" function works without a hitch)!
  2. With that said, KevinOlsen brings up a good point that this does not address the need to allow for making changes to site-wide things like CSS without causing chaos during your development and testing of the altered CSS -- still a huge problem, and one that may not be solvable in this iteration of Squarespace (version 6), since they may well have painted themselves into too many corners to properly provide for this without a complete overhaul. continued in next comment...
  3. This is certainly a workable solution as far as I'm concerned. Thanks to the Squarespace developers who put the "copy" function in place (better late than never)! continued in next comment...
  4. As of now, here is my shortlist of functionality that MUST be added to Squarespace functionality, if the company is to survive:(1) copy (copy a webpage, especially)(2) undo(!!)(3) separate the saving of a page from the publishing of a page(4) option to deactivate autosave(5) option to deactivate autopublish If Squarespace doesn't add most of these soon (or due to unfortunate previous design decisions, isn't ABLE to add these), then as soon as a viable competitor comes up that DOES offer these, Squarespace becomes Myspace.
  5. Actually, your workaround would be THE workaround if only there were a COPY function available for webpages. (Now I'm hoping that someone steps in and says "Of COURSE there's a copy function for webpages, you idiot!" and shows us where it is.) But as far as I can see, Squarespace functionality seems to require rebuilding an entire page manually to make a "copy" of it, and then REtesting all of the links, scripts, etc. on the newly-minted page -- using just as rigorous a QA routine as the original page was put through. (We all test and QA our pages before publication, right?) continued...
  6. Funny, I described my suggested workaround above as "pretty atrocious" and you describe yours as "not ... ideal". I'm STILL hoping someone comes along to tell us that there is obvious available functionality built into this system that allows one to perform this basic task! continued in next comment...
  7. ... But I probably WON'T do that, because it's all too likely I would forget to change the message back after I was done with the maintenance.
  8. While you have a page disabled, a user trying to access it will see the default (404) message, "We couldn't find what you are looking for" unless you set an alternate "404 page" in your site's "General Settings". I'm planning on creating a new 404 page that says something like "The page you seek is unavailable. Either it does not exist, or it is undergoing maintenance." When I'm doing extended maintenance on a specific page, I might update my special 404 page to additionally say: "The following URL is undergoing maintenance - ________." (continued in next comment...)
  9. @ari - The workaround above (disabling a page to work on it) is pretty atrocious, but it's the only way I'm aware of for doing responsible maintenance on a live web page in Squarespace. I continue to hold out hope that someone will hop in here and tell us that there is a proper method, engineered into the SquareSpace infrastructure, to do proper webpage maintenance and testing! To DISABLE a page: Bring up the page in the Content Manager; click on "Page Settings" for the page; then click the "Disable" button at the bottom of the "Configure Page" window. (continued in next comment...)
  10. So far no replies on this one (and very few views, so I guess this is not a big deal to most folks). Given the lack of reply, is it safe to assume that substantial changes to any page of a Squarespace-hosted website (after the site has been launched) are simply not feasible if the site needs to be available 24x7? The only way I see to make any change (other than the tiniest of tweaks), without causing chaos for site visitors during the edit session, is to completely disable the page (make it temporarily inaccessible), make my changes, and then re-enable the page. Again, not an option if my site needs to be up all the time (and I would presume that all of the beta users of the new "Commerce" functionality need their sites up 24x7). Looking forward to hearing from anyone who can offer enlightenment on this!
  11. Pardon me if these very basic questions have been asked and answered many times, but several hours of searching turned up nothing pertinent. (1) After "going live" with a webpage, a Squarespace user wants to make some changes to a page, but does not want those changes to "go live" until she has completed a cycle of PROTOTYPING and TESTING the changes (you know, basic SDLC). How does she do this in the Squarespace 6 environment? (2) An even more basic rephrasing of the question: While I am spending, say, 30 minutes making updates to an existing, live webpage, it appears that any visitor to that webpage during that time will observe every incremental change (including inadvertent blunders, typos, etc.) that I am making IN REAL TIME. I must be missing something really obvious here, so forgive me! How do I make changes to a currently-live webpage without causing such chaos during my edit sessions? Thanks very much!
×
×
  • Create New...