[NanoCaiordo]

Be warned, it will break all themes and very few modules.

Below there are infos and all instructions about upgrading your themes and modules, very small changes but required.

PHP:

# CVS is now at the revision number 9.1.2.8

P3P editor wrote:

• will be found in admin -> main settings
  

Classes wrote:

blocks.php

• A new Block class have been written to replace many functions found in includes/functions/display.php.
• It fixes few minor bug always present since 9.0.6.1.
• It is suppose to speed up the blocks display process.

menu.php

• A new Menu static class have been created to reduce I/O disk access by saving images paths in the visitor Session and it does reduce, site-wide, generation page time. A cached version will probably come later on.
  

rss.php

• Have a new public function format()
  

Deprecated functions wrote:

• MEMBER_BLOCK, themesidebox(), themecenterbox(), blocks(), rss_content(), blocks_visible(), render_blocks(), blockfileinc(), headlines(), userblock() and hideblock() are now deprecated.
• By activating CPG_DEBUG (a must in this case) will link old functions to the new class and appropriate warnings will shows up in the footer.

Themes changes wrote:

PHP:

<?php
# add to themeheader() and themefooter() globals
$Blocks

# replace
blocks_visible('l/r');
# with
$Blocks->l;
$Blocks->r;

# replace
hideblock('N');
# with
$Blocks->hideblock('N');

# replace
blocks('left/right/center/down')
# with
$Blocks->display('l');
$Blocks->display('r');
$Blocks->display('c');
$Blocks->display('d');

/*
Make sure your theme/templates/block.html works properly since it will be now finally used by $Block->preview() in admin -> blocks and wherever a developer wants to display a preview of a block.
*/

# header.html, footer.html and blocks.html add minus/plus image file extension like
src="{leftblock.S_IMAGE}.gif"

Modules changes wrote:

PHP:

/*
Only if your module use MEMBER_BLOCK or you as developer want to add a user custom "tools" block like Your_Account and Coppermine does. 
*/
$block = array(
  'bid' = 10000,
  'view' = 1, # 0 all, 1 user, 2 admin, 3 admins, >3 bbgroups
  'side' => 'l', # l, r, c, d
  'title' => _MULTILANG_ALLOWED,
  'content' => 'a string or a callback function()'
);
$Blocks->custom($block);
# just free up some memory
$block = NULL;

Templates files wrote:

• themes/default/admin/settings.html

I'll invite all module developers to use install/sql/tables/ and install/sql/data/ standards for future developments.
9.1.2.8 core support already this and will be soon the new install way. An example is found in cvs/modules/Blogs/

Why?
In case that users wants to upgrade DragonflyCMS and any 3rd party modules on the same time it will be then possible.
Also the module installer will be able to 'clearly' use all db_check functions/converters ... eg if you add a new fields you only need to add the field to the table structure, change version number to your module and db_check will do the rest.

Another example is if you want to convert a varchar field that contains IPs to a varbinary field type. Just change the field type in the module table structure and db_check will think to make the conversion possible in all DragonflyCMS supported databases.

In other words will make your module install/upgrade compatible with all supported databases.

[BrokenCrust]

Quote:

I'll invite all module developers to use install/sql/tables/ and install/sql/data/ standards for future developments.
9.1.2.8 core support already this and will be soon the new install way. An example is found in cvs/modules/Blogs/

Can you expand on this with a bit more detail? The blogs example isn't totally clear.

[NanoCaiordo]

I do always promise my self to update our SDR ...

For example the cvs Blogs path includes an sql directory.
The sql directory includes cpg_inst.php and Blogs.inc.

cpg_inst.php works almost like the current way.
Use ModuleName class, use ModuleName constructor and updated all $var(iables) with your infos.

install() can be left empty (as it is in Blogs): when installing a module the core will look for Blogs.inc, read $tables data, tables $indexes and tables $records and any SQL query will be MySQL4 / 5 (even if running in strict mode), PostgreSQL 7 / 8 compatible.

unistall() just copy and past.

upgrade(), thats the nice part: still works as the old way by using $this->version to compare. But if you only want to add new fields or change field type, then you only need to update Blogs.inc and $version in your cpg_inst.php. The installer will convert the data, if needed, taking care of database compatibility or add the new fields.

Hypothetically if a new DragonflyCMS version will break some module compatibility the user then will need to 'disable' every module, upgrade DragoflyMCS, upgrade every module and then 'activate' them.

In future Users might activate the Maintenance mode, upload new core and new modules, upgrade the core and the core it self will automatically upgrade, if needed, any modules using the new tables data structure and 'disable?' it.

However every DragonflyCMS upgrade, even if the module doesn't need to be upgraded, the installer will still "check" the module table structure for integrity.

[scetter]

So what you are saying is we need to include an sql directory with Modname.inc and cpg_inst.php so whenever DF is upgraded it can also check the modules table structures? Or is this just for module upgrading?

Is there going to be more details on this put in the Docs?

[NanoCaiordo]

Tables structure will be checked in both cases. This is why if you alter Modname.inc table structure you do not need to specify any query at all. The installer will performs all query by comparing whats on the database and what is specified in Module.inc.

Yes more details will be avail in our SDR including all "compare" options.

[NanoCaiordo]

However i need to add that modules install/uninstall/upgrade is still backward compatible.

[Phoenix]

Confirmed - existing modules/blocks work just fine.

Theme modifications are trivial.

Congratz

[Beldak]

How do you pull in the blockid (bid) with this new method?

Before, in a block, $bid would be passed into each block and you could run db queries off of the $bid variable.

[darkgrue]

Quote:

Fatal error: Call to undefined function blocks_visible() in /usr/local/apache2/htdocs.tcf/themes/PH2_Blue/theme.php on line 57

The change is blocks as implemented doesn't appear to be theme backward-compatible?

[Dizfunkshunal]

change

Code:

 if (blocks_visible('l')) {

to

Code:

 if ($Blocks->l) {

[darkgrue]

Dizfunkshunal wrote:

change

Code:

 if (blocks_visible('l')) {

to

Code:

 if ($Blocks->l) {

No, I understood that, and I got the theme in question fixed for those changes. But this change means that all themes would have to be updated for 9.1.2.8?

darkgrue wrote:

I also note that there's a lot of "standard" stuff that's not working now...

Quote:

Fatal error: Call to undefined function themesidebox() in /usr/local/apache2/htdocs.tcf/modules/Your_Account/functions.php on line 139

Looks like themesidebox() was removed too early before all the changes were propagated into affected core modules?

EDIT: My mistake, I apparently somehow missed updating those files.

Quote:

CMS Warning line 171: block-Today_in_History.php
There appears to be a problem with this block

I'm guessing that the new block class doesn't yet handle blocks that are intended to return no content and "self-hide" like Today in History does in the same way the old system did?

Doesn't really feel like a minor point release, there's a lot that changing in terms of fundamental assumptions about the operation of the system. Breaking theme compatibility isn't a minor point release, I'd think?

[Dizfunkshunal]

out of my league lol sorry

[Phoenix]

darkgrue wrote:

Quote:

CMS Warning line 171: block-Today_in_History.php
There appears to be a problem with this block

I'm guessing that the new block class doesn't yet handle blocks that are intended to return no content and "self-hide" like Today in History does in the same way the old system did?

Confirmed - it still provides the no entries message but the extra error needs fixing.

Quote:

blocks/block-Today_in_History.php

* CMS Notice line 35: There are no entries for today

@darkgrue - it's only a 1 point version change in cvs - public release version will be different.

[darkgrue]

Phoenix wrote:

darkgrue - it's only a 1 point version change in cvs - public release version will be different.

Ah, no sweat. Just didn't anticipate the changes would be so sweeping this time around. Was a little traumatic.

[Phoenix]

can't make gourmet omelettes without breaking eggs.

The themes Mountain Rush and Fiblack3d are now updated for release v9.1.2.1 and CVS v9.1.2.8+ in the Themes cvs area and are also available in the Downloads system.