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:
and
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 https://github.com/browscap/browscap-php 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.
See:
Unfortunately we really need separate items to be developed in separate branches, otherwise we end up with a mess. 
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.
Cheers!
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 
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.
PSR
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:
https://github.com/dasgarner/xibo-cms/tree/feature/playlists
What i mean is for example drupal modules (hooks):
https://api.drupal.org/api/drupal/includes!module.inc/group/hooks/7
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 https://api.drupal.org/api/drupal/modules!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ā.
(https://www.drupal.org/project/project_module)
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