Support Chunked File Uploads

Continuing the discussion from Upload large files:

For browsers that support that?

The server side script should already support it - it might be as easy as enabling the client side option

If someone can test (with different browser), here is the patch:


put this in the settings.php:
define(‘CHUNKED_UPLOAD’, ‘4000 MB’);
define(‘CHUNKED_UPLOAD_SIZE’, ‘10000000’);

Maybe we could check the browser with the php function get_browser or if really needed

Looks like you have added this to your existing branch - which means your current pull request (which we are still processing) has been messed up with these additional changes.


Unfortunately we really need separate items to be developed in separate branches, otherwise we end up with a mess. :blush:

These would really need to be in the settings table, probably under the content tab - but other than that your changes look OK. I’ll be able to comment better once they are in a separate branch.


Ok, thank you and sorry! I am not used to github - and i don’t know if i will ever learn to work with github, i don’t use it every day…
I tried to fix it, there are now two separate branches on my github repo. Is that ok?

Concerning the define: I know, i am a minimalist :slight_smile: and i don’t know xibo source that good - that’s why i am using it. Unfortunately code isn’t modular and i first have to find the parts in all files that needs changing etc.
As soon as i have the time…

I am spending a lot of time with xibo (win8 client on z64 and the android client on minix x8h) testing. There are lot of things i have to fix first. As soon as i have a system “ready to go” i will contribute more or make the contributions better, write some documentation etc

The file up-loader is a core part of the system - why would that be modular? I suppose you might want to plug in a different one, but that is what the API is for.


1.8 Series will be fully PSR compliant and use a framework (Slim). This is a seriously “work in progress”, but the basics are here:

What i mean is for example drupal modules (hooks):!

Allow modules to interact with the Drupal core.

1.8 sounds good, i will have a look at that library, thank you.

I don’t really think that applies to anything beyond the “modules”, which are actually already very flexible…

If we had a method to:

Allow modules to interact with the Xibo core

what exactly would they do??

Don’t forget its a work in progress - at the moment it is quite broken!

Ok, thats ok.
Nevermind and forget what i said. But if you are interested and have never worked with drupal, here is a better explanation:

As an example!system!system.api.php/function/hook_menu/7
with hook_menu i can manipulate the menu from system.

The point why i said “Unfortunately code isn’t modular”:
In drupal nearly everything is possible with a module and i just go to the module directory on the server an don’t have to look into the code for finding a part of “functionality”.

I’ve used Drupal and Wordpress hooks before - the point I was trying to make was that I don’t see why we would be interested in allowing someone to hook into the menu, or the page footer, etc, etc.

I’m actually very open to adding hooks - they are trivial to implement - but before making that effort we’d need to understand what exactly they would be used for.

We’d also need to understand how to actually support that function.

The important part of Xibo - the actual modules that can be assigned to layouts - are modular and there is an example module file for implementation included in the folder.

I’ve been giving this some thought whilst munching on some dinner and in my mind the comparison of Xibo to Drupal actually brings around some very interesting questions.

It is my opinion that Xibo could be structured better so that it is more MVC, uses a framework and is PSR compliant-ish - hence the investment into this in 1.8. This will mean a model layer which we can actually unit test correctly, a controller layer which we can test through API runners and a view layer which is entirely abstracted into Twig templates (which facilitates the other two things).

The purpose of this activity for me is to improve the testability and maintainability of the code NOT to improve the ability for people to write hooks and extensions (which actually undo the benefits mentioned above, or at least make them harder to realise). The important destinction is that we are hoping to provide a complete system which doesn’t need plug-in extensions (beyond the ones that are displayed inside layouts).

I don’t say this as a criticism of your idea, but as an open dialogue to what we intend.

Ok, now i understand. That’s ok for me, 1.8 sounds great (api/twig is fantastic). Thank you very much for the detailed explanation!

1 Like