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