Yes this will happen if you click on the button — it currently closes it for good. This is a default behavior derived from our ajax popup windowing; I should add in a reactivation setup there, as this is indeed a bit confusing. In the meantime, just minimize instead. (You can also do it by double clicking on the top bar of the builder box.)

On a fast learning curve with creating a site with Wiccle, I went in to deactivate a number of modules for my site with in the admin panel and deactivated the admin module as one of those.  I was not aware that I was actually deactivating "The Admin" area - I just figured that was some module for members to admin stuff - it did not occur to me that I could actually deactivate the very crucual admin area I was in and was surprised when it no longer worked and once I dropped out to the site that I could not return to modify the site.  I just thought of "Modules" as functional sections of the website that one would customize for use by site users, and figured the admin area of the site would not be deactivatable (I think I made up a word there).

Anyway - I thought to share that with you.  Maybe you would want to not have that "module" on the list to be deactivated or at least put up a warning on it somehow?

I went into phpMyAdmin and tuned it back on that way, but that will likely be beyond other people's comfort level.

Actually a false alert with the magic_quotes_gpc issue. This was a bit more mind-boggling, got to the bottom of it after debugging this from several vectors of trial and error.

Here's what happens:

When you "Add video", the regular embed tag from Youtube is validated, and the height, width and URL fields are parsed into separate values into the database. Then, these values are placed into the standard Youtube embed tag listed in skin_video_ow.php. The difference between the two is the wmode=transparent parameter you remember from the "Flash overlays everything" problem.

Now, why does one work, and the other not? After all, the video embed tag parser doesn't check for wmode field or any of that, and as I was also unable to replicate this issue locally no matter what I did. Here's the answer (tested several times):

Your server truncates GET requests with a single variable value longer than 512 characters. (While generally the lenght is limited by browser capacity alone.) Therefore, whenever the embed tag total length exceeds 512 characters, the whole "tag" variable is stripped out from the request before it ever reaches PHP. I have never come across this behavior before.

I have prepared a demo case of this for your web host to look at (as it's some sort of a server hiccup or limitation), and will PM you the details momentarily.

To fix this, I will change the query type from GET to POST and see if that works around this on your server. In the meantime, you can avoid this simply by not for example using colored frames for videos (as all that adds to the length of the URL, and thereby the tag).

Wiccle is quite resource-friendly as it is; 1.2 MB to 3.5 MB memory usage per pageload depending on page configuration, page processing time between 0.05 seconds and 0.35 seconds on a low-end VPS with a dozen other sites on.

Here are two FAQ threads you'll want to read:

• What are the Server Requirements for iWiccle/Wiccle?
• iWiccle/Wiccle Resource Tracking

You can also track the resource usage of each one of your pages. You can even track your pages' resource usage and browse them in the database, spotting bottlenecks in your site performance! (See the second thread above.)

To get a real time view of resources used by any given page, log in as administrator and type &debug=on to the end of any URL on your site. A debug terminal will then be included at the bottom of the page:

In the above, you can see all SQL queries used on the page, along with memory usage details and CPU processing time. The above screenshot (memory 2MB / CPU time 0.14 sec) is taken from the WWB Demo eCommerce Portal page, with five content units and two dynamic modules' content enveloped in.

(And incidentally, in the above I notice a duplicate query which I am now yanking out to cut down further on CPU usage. Everything is well-tracked and structured, and therefore easy to keep trimmed down to the necessary minimum. Bug report tagged; stuff like this needs to go out to keep the system free of clutter.)

When testing your pages' performance, bear in mind that it's good to view it a couple of times, as a busy server may take a moment to respond, and the response time may not reflect the actual server load of that particular page. You'll get a reliable reading by refreshing a couple of times, and looking at the most common CPU time that's displayed — that's the time when the CPU was free to crunch the page up.

Also bear in mind that these already fair/good performance levels are with cache off. The dynamic intelligent cache we are working on (not rolled out yet) will dramatically cut this further, making it what I believe is the most resource-friendly CMS with dynamic content on the market.  It uses a smart combination of database and filesystem to bring loading and processing to an absolute minimum. =)

On your wickle site, under Members-Everyone there is no indication of what page one is on.  And I am pointing this out mostly because I figure your site is a running example of your product and so I suspect your product might be missing the same. 

In the top right corner there is a list of pages by number, but no indication as to what number page one is on, so scrolling through, one can easily become lost with regard to what page one is on. 

Solution recommendation, have the current page number simply stand out with a different color.  And personally, using this type of function to search through results on other websites (I often find myslef scrolling through pages of images on stock resource sites), I use and like having a "Next" and "Previous" button, or forward backword arrows if it works better in the design.

For what it's worth - my initial opinion on WWB1.0 -

• It's a very stable product - I haven't been able to 'break' it (...yet! doesn't mean I'll stop trying ).
• It's big - very big - with endless possibilities -
  • even as a seasoned iWiccle user I'm finding it all a little overwhelming (familiar, but still much to absorb).
• Simple, non-technical (admin as well as user) documentation is urgently needed - if I was new to the product I'd be very impressed but overwhelmed by the task I'd be potentially undertaking.

A couple of things I found 'strange' about my default install -

• In 'Auctions', when adding a new item, the default expiry time displays server time (rather than offset time) - confusing to the user adding an auction item.
• Same situation in 'Chat' - displays server time rather than offset time - again confusing to a user.
  • I haven't tried all modules yet, so I don't know where else the server time is displayed.
• As a default, all 'Root Administrators' permission masks should be set to 'Yes'. I was surprised when I tried to ste up a Chatroom parent and got a 'Your Usergroup doesn't have permission...' etc.
  • It's easy enough to rectify this... when you know what to do. As a new user logging-in (as the administrator) though, you'd be a little put-out having to rectify your own permissions.

Overall (and coming from the user side) - a big, bold, solid and excellent product - kudos to all involved (and please don't stop this great work) .

Well, it took me more than 9 minutes but I had to CHMOD twice. I tried 774 but I was told I needed to change them to 774... weird, huh? So I changed them to 777 and it's all good. Not sure what the boggle there is about. Is 777 ok?

Also, I've noticed a small issue when I hover over the modules tab. The list tucks under the footer instead of on top. Easy work around by just clicking the modules tab and selecting the module from the list that appears on the left, but still thought you'd want to see this.

1. The 'Yesterday" and "Today" timestamps appear to be working on the server date/time rather than the site-adjusted offset date/time. When I commented-out the 'Make relative date' calculations in class_global and reverted back to normal, the 'normal' timestamp correctly adjusts for the offset.
2. The above is not the case with messages between members, which are timestamped with the server time and not the offset time.