[layingback]

Neither. I was only using phpMyAdmin to browse the format of cms_blocks for info in order to rectify some issues in Pro_News which broke the block handling under the latest changes in 9.2

But while I had phpMyAdmin open on cms_block I could not avoid a bold yellow banner stating that there appeared to be duplicate indexes and recommending that 1 of them be removed. Indeed Primary is declared as bid and bid is also declared as a unique key, so they might have a point. (I checked and this problem is new in 9.2, relative to 9.1.)

I'll try and post an image later (I installed 9.2.0.RC2 on my other - Linux - side of my desktop's dual boot so can't right now!)

[NanoCaiordo]

bid,mid,weight are all together one unique key called "bid", there are not primary keys at all, i knew that phpMyAdmin had issues with keys but not up to this point.

[layingback]

Nano, Here's the screenshot from phpMyAdmin v. 2.11.3 on MySQL v. 5.0.51. Showing cms_blocks.

[layingback]

Nano, Here's the screenshot from phpMyAdmin v. 2.11.3 on MySQL v. 5.0.51.

Hmmm. No attachments in this forum... Will post to Problems AFTER Install/Upgrade forum.

Image compression makes last word of warning message harder to read, but it is 'bid'. And display above shows 2 keys called bid.

Note that this is from a new install of 9.2.0.RC2 - not an upgrade.

Hope it helps.

Edit by Phoenix: attachment merged - I'll fix the attach permissions.

[BrokenCrust]

phpMyAdmin has always had this problem. If you define a key one a column and then another compound key that also uses that column then it bleats about a duplicate key even though it isn't.

eg

primary key (id)
key (id, user_id)

then it will moan about a double key on id, even though it isn't.

[layingback]

Good info, thanks!

[tilantha]

Does LEO work on 9.2 RC2?

[rlgura]

Not sure if this is an oversight, or just something that isn't done yet.
There is a new stylesheet: adminblocks.css that has styles for the new blocks administration, however, it doesn't seem to be linked anywhere...

For my theme, I just added a line to template\admin\blocks.html to link the style sheet - seems to work ok.

Realized this because New Block and block listing was white on white for my theme. Changing settings for default theme also had no visible effect

[NanoCaiordo]

admin/modules/blocks.php 86-92 clearly looks if all files are there, otherwise select all needed files from the default theme.

PHP:

<?php
	$blocks_theme = 'default';
	# will be removed the next release
	if ($ThemeSel != ' default'
		&& file_exists('themes/'.$ThemeSel.'/style/adminblocks.css')
		&& file_exists('themes/'.$ThemeSel.'/javascript/adminblocks.js')
		&& file_exists('themes/'.$ThemeSel.'/images/drag.png'))
	{
			$blocks_theme = $ThemeSel;
	}

Make sure to upload at least the default theme which is always use to search for files missing from new theme.

Next releases will have more and more files moved, including images, css, js, in the themes, this is part of the template process that every ask for ... but I'm not sure how long the fallback for missing files will last for.

[rlgura]

Ahh - I didn't notice the new '/javascript/adminblocks.js' file - I didn't have that in my theme, so it was still looking to default's adminblocks.css.

I'll add these files to my list of required changes to upgrade a theme to 9.2

[NanoCaiordo]

If your theme is missing one of those files, the core will immediately fall back to "default".

A theme will only need both css and js file if the default provided files doesn't work properly on your theme.

In that case you have to add and modify them to suit the theme, otherwise just make sure to upload the entire default theme.

[layingback]

Nano, I may have found a problem in the new Blocks admin...

If 2 blocks exist with the same identical block Title ( ie. $row['title'] ), one with, say, a block id of 17 and 18 for the other, the bid=18 block will effectively overwrite (hide) the bid=17 entry in the right-hand block list display.

This results in 2 potential problems: user can't get to deactivate or delete the earlier one at all; and the display may appear inconsistent, e.g. if say bid=17 is already activated and bid=18 is not, the display will show the block unactivated (from bid 18) but at the same time the actual block will still be displayed (from bid=17).

It is true that if both are displayed in Blocks admin, they will appear identical, but the display will reflect the reality of 2 blocks of the same name, and by rolling a mouse over each title the bid can be seen in the browser status line.

Displaying both, even with duplicate titles would also be consistent with how it was previously handled in earlier releases.

I believe the code in question is on line 157 of blocks.php:

Code:

if (defined($row['title'])) $row['title'] = constant($row['title']);

I think it is all too easy to get into the situation where 2 different versions of the same block are present at the same time, to not provide a simpler method of resolution than having to delete the newer one, then deleting the older one, then re-creating the newer one.

[layingback]

*** bump ***

I think this is/will be a serious support problem ...

Code either needs to test all fields (to ensure that blocks are indeed truly identical) or allow both versions to display separately. Else we will keep seeing a configuration which conflicts with the user's actual block set up. A support nightmare. I'm worried about it just for Pro_News; it would be a far bigger concern for DF as a whole, IMHO.

[Dizfunkshunal]

I agree on the duplicate name check for the field, to make sure no 2 blocks can have the same name.

Support with out a fix is easy

Step 1: delete the block 2 times
Step 2 create blocks with different names

Personally, I dont understand why someone would put 2 of the same block on 1 website.

[layingback]

But *if* someone does it, it will be very hard for us to help them, when everything looks correct, because we are looking at a new version, but site is running on an old version which can only be seen in phpMyAdmin or similar.

If the blocks are identical then fine, but if they have small differences - access or module visibility or left/right assignment - then they should display separately. Display is now alphabetical, so admin can't miss that they have duplicates. Remember that no 2 blocks are ever truly the same - each will have a unique bid and be stored in separate records in cms_blocks...