I noticie that there is some info on the Wiccle site that mentions "you can install and deploy Wiccle Web Builder on any standard and up-to-date PHP/MySQL server regardless of the hosting model."

I have access to both shared host services and a dedicated Linux server.
I reckon I will need FFMPEG to convert uploaded videos to .flv files on a dedicated server, but I'm curious about general file uploading.

If I run Wiccle on a shared host, I'm limited to 64mb memory for the web site, which is on the low side. I have had problems with other software (Elgg, Worpdpress photo plugins,etc) where I get PHP out of memory errors when uploading files more than 25 mb in Elgg and when Wordpress photo plugins create thumbnails of 1mb photo's.

Do you think Wiccle will encounter similar memory problems on a shared host ?
It's interesting to see the non shared video display option in WIccle (not FFMPEG), but I'd like to know if this would be fine running on a shared hosting service.

I can change various PHP max upload settings, but it tends to be out of memory errors that crop up on other CMS web systems. The only one that I've been able to upload larger files on is PHPBB3.

The only way I will know for sure is to try it, but I'd be interested to hear if I'm likely to hit problems on a shared host.

The memory requirement deal is something I've looked into before.The memory required for running the basic software itself is one thing, while the memory required for media resizing comes with a more standard and predictable formula that binds all platforms.

Here's an approximate chart of how much memory is required for scaling down different sizes of photos. Test images were scaled down at 1 Mpx intervals and saved with JPEG quality 90. What they are scaled down to is not that important, what counts is how big a source image is loaded into server memory.

Dimensions: 640 x 480 px (0.31 Mpx)
Image size @ q90 JPG: 193 KB
Memory needed: 1735 KB (1.69 MB)

Dimensions: 800 x 600 px (0.48 Mpx)
Image size @ q90 JPG: 291 KB
Memory needed: 2646 KB (2.58 MB)

Dimensions: 1024 x 768 px (0.79 Mpx)
Image size @ q90 JPG: 458 KB
Memory needed: 4262 KB (4.16 MB)

Dimensions: 1100 x 900 px (0.99 Mpx)
Image size @ q90 JPG: 611 KB
Memory needed: 5336 KB (5.21 MB)

Dimensions: 1560 x 1280 px (2 Mpx)
Image size @ q90 JPG: 1057 KB
Memory needed: 10645 KB (10.4 MB)

Dimensions: 1910 x 1570 px (3 Mpx)
Image size @ q90 JPG: 1608 KB
Memory needed: 15929 KB (15.56 MB)

Dimensions: 2210 x 1810 px (4 Mpx)
Image size @ q90 JPG: 1990 KB
Memory needed: 21209 KB (20.71 MB)

Dimensions: 2470 x 2024 px (5 Mpx)
Image size @ q90 JPG: 2277 KB
Memory needed: 26479 KB (25.86 MB)

Dimensions: 2700 x 2224 px (6 Mpx)
Image size @ q90 JPG: 2510 KB
Memory needed: 31781 KB (31.04 MB)

Dimensions: 2920 x 2400 px (7.01 Mpx)
Image size @ q90 JPG: 2654 KB
Memory needed: 37071 KB (36.2 MB)

Dimensions: 3130 x 2560 px (8.01 Mpx)
Image size @ q90 JPG: 2833 KB
Memory needed: 42370 KB (41.38 MB)

Dimensions: 3300 x 2730 px (9.01 Mpx)
Image size @ q90 JPG: 2959 KB
Memory needed: 47624 KB (46.51 MB)

Dimensions: 3500 x 2860 px (10.01 Mpx)
Image size @ q90 JPG: 3038 KB
Memory needed: 52902 KB (51.66 MB)

This was counted with a basic formula by simshaun from a DevShed thread — of course different platforms can add to the memory requirement by doing something complex with the images loaded into memory. However, with the figures on the table, it's easy enough to calculate a baseline for how much your server should be able to handle.

Of course if you have a bulk uploader, and if you're uploading bigger images in bulk, you will hit the ceiling much quicker, as it all counts into the memory allowed for a single script execution.

With the photo details out of the way, to the rest of your post. You shouldn't have problems uploading files that don't require loading into server memory for processsing, assuming your PHP is configured to accept large incoming data. These are the directives you will need to check:

memory_limit = 64M
post_max_size = 64M
upload_max_filesize = 64M

Yes, you will need FFMPEG for converting videos to .flv — but I don't think any shared host would permit running executables (or even CRON jobs). The other two modes for the video module are:

• File upload without conversion — this plays the videos using WMP or QuickTime browser plugin (as seen in Wiccle Screenshots). The plugins stream the file directly from the file system, so there's no conversion or subsequent memory issue either during upload or play.
• Embedded videos from Youtube etc.

These modes can also mix where admin allows --- though you would usually want to use either .flv or direct mode, combined with the embedding option.

As far as iWiccle / Wiccle memory usage beyond that, iWiccle 1.11 munches up around 1 to 1.5MB per load, and the current Wiccle.com page with everything on and from live data around 3 to 4MB per load. This will go lower when I get around to tidying up file dependency management and rolling in the cache, both of which will also lower the CPU load. Even these raw figures compare quite well to the competition, however.

Didn't I hear somewhere that the latest version of Wordpress needs 32mb of memory to run ?

Wiccle / iWiccle = Green Tech !

Lowest carbon foot-print of all CMS platforms (including those Community Builders / Web 1.0 Basic Website Builders)

Yet more great info from Markus, you really know your web onions !!

I'm keen to try out the WMP/QT player on server hosted files, as it would save waiting for FFMPEG to do it's thing.

Keith, I know the NextGen image gallery for Wordpress fails with any 1mb+ images that I upload on my shared host web sites, looking at the error logs, it's asking 37mb mem and not getting it.

I can almost smell the Wiccle binaries, just about in touching distance now :)

It's really a very simple setup with the video-with-browser-plugin, and one I'm sure you've seen on many sites — it just uses the embedded browser plugin to play the media, and it'll play anything that WMP/QuickTime could play.

Of course you then need to have the files uploaded in some recommended formats and sizes to keep them properly viewable online, while with a conversion in place you have complete control over the quality and size of the uploaded videos.

Wiccle 1.0 is indeed at a touching distance. I just finished a long brief with Keith on all things sundry, and we are evaluating Wiccle Web Builder status tomorrow afternoon. I need to go over everything, see how complete / developed / underdeveloped each module is, and then sketch a plan for a quick wrap-up of everything into version 1.0. As it stands, some areas have gotten a whole lot of attention and polish, while others are a little bit behind, even while everything's right there on the finishing pipeline.

All this techie talk is way above my pay grade but it sounds good! lol

Good work guys