RCBullar
My feedback
2 results found
-
12 votesRCBullar
supported this idea
·
An error occurred while saving the comment -
0 votes
An error occurred while saving the comment RCBullar
commented
Well ... Sparnfarkel.
Okay, you've caught me on a deadline for the "real" job so I'm going to be real brief and let you know how I would chase it.
* Go and grab our .js files and compare them with yours to see if something jumps out at you. No need to compare slideshow.js -- it's verbatim from the BarelyFitz site. But take a look at either:
* http://denverhighland.org/resources/scripts/header_sm_1.js scripts/header_sm_1.js
* http://denverhighland.org/resources/scripts/business_1.js scripts/business_1.js http://denverhighland.org/resources/scripts/business_1.js
* http://denverhighland.org/resources/scripts/business_2.js scripts/business_2.js http://denverhighland.org/resources/scripts/business_2.js
(We actually have three slideshows running on every page, but don't look at the code that places the "business" shows -- it is complex given we dynamically alter the page layout with javascript to place these shows under the menu,)
* Go grab our Global javascript file from its backup at http://denverhighland.org/resources/Archive/Global Javascript/20120510.txt . Inspect the section beginning with the comment <!-- Scripts for the rotating images -->. Compare it to your code in the raw headers of your page.
* Go grab the HTML source for our homepage at http://denverhighland.org , and search for the code that places our slideshow in the header by searching on SLIDES1. (That's the name of the show we place in our header. SLIDES2 and SLIDES3 are the shows in our left margin.) >> I also removed the <!-- and //--> to make the bottom portion of that code active. Should I have done that? <<Regarding the above, take a look at http://w3schools.com/js/js_howto.asp , and search on the header "Some Browsers do Not Support JavaScript." (The w3schools website, by the way, is my goto reference for all things web. I also use http://htmldog.com a lot.)
One other hint: create a totally blank page on your site to play with getting the show working. I got everything working on a page that had absolutely nothing else on it, and then I transferred what I had learned to the header and footer, which was a bit more -- challenging.
Finally, send me your site's URL. If I get a moment I'll take a look, but I can't make any promises given my weekend looks to be dominated by the great outdoors. (In other words, yardwork.)
Rob
An error occurred while saving the comment RCBullar
commented
Larry,
The bulk of the javascripts actually need to be in places other than the page body itself. Here's how we have it broken down: I created a folder in File management called "scripts." In that folder I placed: slideshow.js (contains the "slide" and "slideshow" objects used by all other scripts to create the show.) <slideshow_name>.js, in our case header_sm_1.js. This is the script that creates the slideshow.
In Global Javascript (under Site settings) I place the following code to load the scripts:<!-- Scripts for the rotating images -->
<script type="text/javascript" src="/resources/scripts/slideshow.js" mce_src="/resources/scripts/slideshow.js"></script>
<script type="text/javascript" src="/resources/scripts/header_sm_1.js" mce_src="/resources/scripts/header_sm_1.js"></script><script type="text/javascript">
<!--
if (document.images) {
SLIDES1.image = document.images.SLIDES1IMG;
SLIDES1.textid = "SLIDES1TEXT";
SLIDES1.update();
SLIDES1.play();
}
//-->
</script>I choose to place this code in Global Javascript because my slideshow is in my header, and displays on every page. If your slideshow. If your show is only on one page you can place this code in the raw headers for the page via the Meta-Tags dialog for the page under Page Management.
You can also choose to place the if (document.images) block in the page body (described below). I put it in the HTML head out of habit.
Finally, in the page itself (or in my case, in the Page header under Site look and feel) I place the HTML to actually locate the slideshow on the page:<DIV style="DISPLAY: none" id=SLIDES1TEXT></DIV><A href="javascript:SLIDES1.hotlink()" mce_href="javascript:SLIDES1.hotlink()"><IMG style="POSITION: absolute; FILTER: progid:DXImageTransform.Microsoft.Fade(); TOP: 17px; LEFT: 482px" id=SLIDES1IMG border=0 name=SLIDES1IMG alt="" src="http://denverhighland.org/Resources/Pictures/HUNI-WEB-TOP_Right.png " width=300 height=178></A>
Note that I use the HTML edit icon rather than the "HTML snippet." I've never had much luck with the snippet.
It's worth observing that I played around with this a LOT before I got it all working. One must be ... playful ... when customizing WA.
Hope this helps.
Rob
An error occurred while saving the comment RCBullar
commented
We use the BarelyFitz JavaScript slideshow, available at http://www.barelyfitz.com/projects/slideshow .
Example can be seen at http://www.denverhighland.org .
Adding my voice to the calls for an ability to delete trial data, hopefully in a constructive way.
I think you may need a two-pronged solution.
First, for those accounts with sites in production, a "trial data delete" feature is probably not going to be feasible since delineating trial data from production data will be a very manual process. For this, I believe the ability to delete contacts, and separately the ability to delete financial transactions promised in 3.5, will likely provide the best chance for cleanup. (My site will fall into this category -- I likely will be live before 3.5, so will have to return to manually cleanup trial transactions.)
However, as you consider new features, I believe the ability to separate "setup" data from "operational data" will be pivotal, and I suspect you already have such a distinction "behind the scenes." Basically, anything that is specfied on a "Settings" page, such as your list of "exceptions" in your post to which this is in reply needs to be preserved in a "trial data delete." However, I don't see the need for a selective delete. I struggle to imagine a transition from "setup/testing/conversion" to "production" where it would be desireable to preserve any contacts (save administrators), events, registrations, donations, or transactions, The sole exception may be emails, since calling up and editing an old email to create a new one is likely commonplace. However, I would prioritize such a capability very, very low.
An interesting off-shoot drawing a strict delineation between "setup/configuration" data and "operational/transactional" data may provide would be the ability to download said configuration, perhaps as some kind of XML export, etc. If that same file could subsequently be re-imported it could serve two purposes: Provide a configuration "backup" or "versioning" capability. I could easily imagine exporting my configuration and archiving it before any major changes. Provide configuration portability. As a secondary market of expert WA consultants and configuration specialist grows, the ability to transport a configuration between accounts will be desirable. Starting my next client with the configuration from a prior client could be a real time-saver. (Especially if the two are highly related, like two chapters of a national organization.)
If you think about it, if you prioritize such an export/import feature, it's existence could simplify the trial data delete. Imagine a process consisting of the following steps: Export configuration Delete ALL account data (no need to develop delete routines that are "smart") Import configuration Load production memberships
I hope this helps.
Kind regards,
Rob Bullard