Center block above message ... random Gallery images; editor

Posted: Wed Jun 16, 2010 2:59 pm

Came across:

http://www.ravenphpscripts.com/postt19056.html

before posting this and it's a good reference. But I'm going to make a new topic that extends.

My problem ... I have a large Gallery (Menalto) and I've always wanted to have random pictures from my Gallery displayed in the opening message. The Gallery integration package comes with it's own random image block which provides a way to show a single random image in a block -- usually in the left blocks area. There's no way to integrate it into your message however.

I started by trying to figure out a way to "inject" PHP code into the message. But, since the message is edited by fckeditor this proved self-defeating. You can Google around and find threads of discussion where people discuss changing allowablehtml to allow PHP code but it really doesn't work and actually constitutes a serious security hole even if you could hack it to do so.

At the same time I started hacking at the Gallery provided random image block. In the current Gallery2 software series this is known as block-G2_Imageblock.php. To get this working I created a derivative block to be shown only to administrators and located it center down. This way I could debug without disrupting the whole site. Here's the code I came up with:

Code:

<?php


global $admin, $user, $cookie, $db, $prefix;





$g2result = $db->sql_query("SELECT * FROM ".$prefix."_g2config");


list($embedUri, $g2Uri, $activeUserId, $cookiepath, $showSidebar, $g2configurationDone, $embedVersion) = $db->sql_fetchrow($g2result);





require_once('modules/gallery2/embed.php');


//$content = 'yyy';





$ret = GalleryEmbed::init(array(


   'embedUri' => $embedUri,


   'g2Uri' => $g2Uri,


   'activeUserId' => '',


   'fullInit' => true));





     list($ret,$html, $head) = GalleryEmbed::getImageBlock(array('blocks'=>'randomImage', 'show'=>'none','itemFrame'=>'solid','albumFrame'=>'solid'));





        list($ret,$html2, $head) = GalleryEmbed::getImageBlock(array('blocks'=>'randomImage', 'show'=>'none','itemFrame'=>'solid','albumFrame'=>'solid'));


              list($ret,$html3, $head) = GalleryEmbed::getImageBlock(array('blocks'=>'randomImage', 'show'=>'none','itemFrame'=>'solid','albumFrame'=>'solid'));


$ret = GalleryEmbed::done();





if(!empty($ret)) {


   $content = "The G2 Imageblock request failed. Here's the error:<br>".$ret->getAsHtml();


}





//$content = $block_css."\n".$block_script."\n<center>".$html."</center>";


$content = '<table><tr><td>'.$html.'</td><td>'.$html2 . '</td><td>'. $html3 . '</td></tr></table>';





?>

Note that I stripped a lot of error checking out ... this assumes that you have Gallery 2 installed and operational.

After getting the block working for myself as admin, I turned my attention to integrating it with my message. Since fckeditor is a real convenience for laying out a message what I decided to do was just deactivate the message (or show it only to admins should work too) and go into source view after I had my lay out working and copy all the codes over into my new block. I named the new block 'block-Messages.php' and prepared it using my PHP editor (PHPED). Then I uploaded it and activated it center down visible only to admins until I had it just the way I wanted. Then I deactivated the original message and moved the message block center up (as suggested as one option in the previous referenced thread).

So what I have now in my block-messages (I'll leave out the site specific stuff):

[code]<?php
global $admin, $user, $cookie, $db, $prefix;
$content = '
// all the copied in stuff from source view of my original message, this can be replaced whenever the message needs to be changed;'
$g2result = $db->sql_query("SELECT * FROM ".$prefix."_g2config");
list($embedUri, $g2Uri, $activeUserId, $cookiepath, $showSidebar, $g2configurationDone, $embedVersion) = $db->sql_fetchrow($g2result);

require_once('modules/gallery2/embed.php');
//$content = 'yyy';

$ret = GalleryEmbed::init(array(
'embedUri' => $embedUri,
'g2Uri' => $g2Uri,
'activeUserId' => '',
'fullInit' => true));

list($ret,$html, $head) = GalleryEmbed::getImageBlock(array('blocks'=>'randomImage', 'show'=>'none','itemFrame'=>'solid','albumFrame'=>'solid'));

list($ret,$html2, $head) = GalleryEmbed::getImageBlock(array('blocks'=>'randomImage', 'show'=>'none','itemFrame'=>'solid','albumFrame'=>'solid'));
list($ret,$html3, $head) = GalleryEmbed::getImageBlock(array('blocks'=>'randomImage', 'show'=>'none','itemFrame'=>'solid','albumFrame'=>'solid'));
$ret = GalleryEmbed::done();

if(!empty($ret)) {
$content .= "The G2 Imageblock request failed. Here's the error:<br>".$ret->getAsHtml();
}

//$content = $block_css."\n".$block_script."\n<center>".$html."</center>";
$content .= '<div align="center">';
$content .= '<table><tr><td>'.$html.'</td><td>'.$html2 . '</td><td>'. $html3 . '</td></tr></table>';
$content .= 'Random photos from our Photo Gallery; click on one to go to the original photo</div>';
?>[code]

You'll note I centered the Gallery images in a div and put a label below them. One of the cool things the Gallery software does is make the images clickable back to the Gallery itself.

The only downside I can see it that I make my own life editing the message a bit more complicated. I need to open up PHPED and my FTP client whenever I want to modify the opening message ... which is quite often these days. At some point I may think of taking Nuken's suggestion in the other thread of rearranging the order of the blocks and messages and make the random image block separate again.
[/code]

Posted: Thu Jun 17, 2010 7:30 am

Ok if I understand the object is to use the random block code in the admin messages. If that is all you want to do and you don't need extra control over the images-viewers ect... Why not write your php scripting into an include file and include into the message views you desire? If I remember its a little hacked up as if it was a total after thought in the first place. Not themed ect... but its there in mainfile.php function message_box

Posted: Thu Jun 17, 2010 8:39 am

I spent some time looking at the message_box function in mainfile as part of looking at this. Problem is that message_box just echoes out the contents of a variable named $content I thought maybe I could hack message_box by including some arbitrary string in the text of content, then doing some kind of eregi split and replace the arbitrary string by the code I wanted (say to do the Gallery images) then put the variable back together with the included code and echo that. It would probably work but (a) I hate hacking mainfile because then I always have to remember to integrate my changes with the next version we issue and (b) it seemed more complicated than the approach I took.

*Actually that's an oversimplification ... the function also has logic to handle multiple languages and allowing different messages to be seen by different groups as well as to handle expiration of message. I don't use any of that on my site but it's there.

Posted: Fri Jun 18, 2010 7:40 am

I agree with you regarding edits to mainfile.php might be worth the hassle to rewrite the thing as a admin module and get it out of there completely. Kind of been on the back burner in my mind to do that.

As far as "oversimplification" I know its a complicated function. But it is misplaced, therefore I maintain it was just a hack to begin with and was tossed in there (mainfile.php).

But anyway thats a couple other topics to start.

Posted: Sat Jun 19, 2010 8:06 am

This is going to sound crazy (because it is), but I just thought of an additional use for ShortLinks. One could - theoretically - put a new "tap" into ShortLinks/GTZ-PageTap.php where you do something like this:

$urlin:

'{MY_RANDOM_IMAGE}',

$urlout:

'<img src="/includes/gallery2_random_image.php" alt="some name" />',

And then your gallery2 random image script takes care of selecting a random image and passing a valid header and image file back...

Gets the idea across... you could place that {MY_RANDOM_IMAGE} tag ANYWHERE on your site, even embedded in text/html that is stored in the db and even multiple tags should (if you code it right) show different images (unless the !@#$%^ FireFox caching issue rears its head... but that could be solved as well by using a simple .htaccess rule and put a timestamp on your random image file link to make it look like a different "image" each time).

Posted: Sat Jun 19, 2010 12:36 pm

Crazy Genius hard to see the difference sometimes.

Posted: Sat Jun 19, 2010 6:35 pm

I have some studying to do M. I've never used shortlinks but the concept looks appealing and would resolve my dilemma between using blocks versus a message.

Posted: Wed Jun 23, 2010 7:54 am

Humm ... very strange. Found a problem with my initial post where I had an extra code block close. Went to edit it (I have admin privileges) but get no ability to save (submit the changes). I can edit other posts, so I suspect that someone with PHYmyadmin privileges would have to edit the actual post in the database. Not that this is critical.

Now ... I've been using the process I mentioned earlier in this thread. Basically, create a new block named messages.php and make it center up. Deactivate all messages from the site and so the block messages shows at the top. As I feared, while this works, in practice it is cumbersome. For one thing I have another admin on the site and he might occasionally need to change the message when I'm not available. So, we'd have to be coordinating maintenance of a messages.php file in our separate blocks directory in our separate PHP editors. Also, the fckeditor is really convenient for formatting (quickly) html and we lose that.

I started looking at Nuken's solution posted in the other thread in this topic. This was basically to reverse the order of calling messages() and blocks() in header.php to look like:

Code:

if (defined('HOME_FILE')) {


   blocks('Center');


        message_box();


}

This, of course, puts blocks that have been defined in the center position, above the message block. Just as a reminder there are four possible block positions (center, down, right and left) and center is really "center up" where down is really "center down". And what I mean is that when you call blocks() with the parameter set to center ALL center (up) blocks will be displayed in the order that they are set in the blocks table. So, for example, if you had 3 center (up) blocks and 6 center (down) blocks you get:

[list=]the three center up blocks
any messages that are active
the home module
finally the 6 center down blocks[/list]

But what I want on my site is:

The blocks will be relatively permanent and editable in a PHP type editor. The messages will be ephemeral (possibly changing more than once a day) and I really need them to be editable through fckeditor so that any admin can change them.

And RN really does not accommodate this at present.

So here's a proposal:

Suppose we create a new block position. Let's call it "t" for top. We'll need to fix up /admin/blocks.php to support this. "t" will have the same "weighting" (order) scheme as the other block positions ... l, r, c, and d. (Incidentally mainfile does this

Code:

   if (strtolower($side[0]) == 'l') {


      $pos = 'l';

on the block positions. I'd propose that we simply call blocks() with a single letter and maybe stick a die in mainfile if $pos is not one of the legitimate single character parameters -- l, r, c, d and now r.

Anyway, if you want your block to appear before the messages, then we do a variant of what Nuken suggested, namely change header.php to do this:

Code:




if (defined('HOME_FILE')) {


        blocks('t');


        message_box();


        blocks('c');

Now the blocks function in mainfile will find all the top blocks, present them, then present the message blocks, then the center up blocks, then the home module and finally the center down blocks.

Sound reasonable?

Posted: Wed Jun 23, 2010 8:08 pm

Thinking further about this ... first discussing it requires some familiarity with the blocks table layout as well as the mainfile function blocks() and the admin program blocks.php.

Basically all the mainfile function does is display all blocks that occupy a given block bposition (the database field in the table blocks). They are ordered by the weight (another field) within that bposition. As stated in my previous post, the standard bpositions have been c, d, l, and r. I was proposing adding t (for top) but thinking more about it, we really could have an almost limitless number of bpositions (although bposition is defined currently as char(1) so that imposes some limits) -- let's say we limit ourselves to 26 characters to start with.

Now if we call blocks() with a given character in the parameter, all the function does is look up all blocks in that position, ordered by weight and display them. So, let's say we wanted a top block (center) then the message(s), then 2 more "special" blocks, then the home module, then the rest of the center blocks. We could do this by having a bposition of t for the top block and maybe a 'u' for the two that come after the message and before the home module. We could modify the admin program to let the site admin define any block positions they want.

Aside from the uses in the previous paragraph, we could set up blocks to be used in various modules. Let's say we wanted to run a feeds module and we had set up a few blocks to run inside that. The module could run and the first thing it could do would be to call blocks('f'). The system would find all blocks with that bposition and present them "inside" the module.

The admin program could be set up to do a select distinct on bposition with the option to add other bpositions. Or, we could have some other kind of registry of bpositions and perhaps expand the field size to allow for more "descriptive" entries.

I'm willing to do the work on this but would like reaction before spending a lot of time on it. I need some variant of it for my own site.

Posted: Thu Jun 24, 2010 4:49 pm

not sure how this would coordinate with some of the other proposed changes, but sounds good... I'm all for more functionality within the blocks system.

Posted: Thu Jun 24, 2010 5:05 pm

I'm not sure which other proposed changes you refer to. If someone is going to write a drag and drop blocks management using jquery or some other tool like that then yes, my changes would get lost in that. If they are going to do away with the way bposition and bweight fields work and how the mainfile blocks function works then again my changes would be at odds.

I did the most recent set of changes a couple of RN releases back ... to allow you to rearrange blocks with a single set of actions using numeric values for the weights. All this assumes is that people can count. I've never understood how dragging blocks around is any easier and it sure is a lot harder to program. Maybe that's why we keep seeing proposals to do it but nothing tangible showing up.

Posted: Thu Jun 24, 2010 8:49 pm

I haven't really followed this topic, but I will offer a quick opinion Smile

I think adding positions is fine, but if are going to blocks per module I think you need to create a separate table in the db and not sue "position" to do it.

Posted: Fri Jun 25, 2010 4:55 am

Not to beat a dead horse but simply including the free GPL AutoTheme lite package allows unlimited block positions and also block positions by module as well.

Posted: Fri Jun 25, 2010 5:48 am

The autotheme lite inclusion is beyond my pay grade here. Perhaps you could write an explanation of technically how it achieves the capabilities you reference.

Re. blocks per module ... let's just wait and see. I intend to get the changes I've mentioned done sometime in the next few weeks. Then we can see. If I have modulex and I set up a block position for it (bposition = x) and I call the mainfile function with "blocks('x')", the block(s) for that module should be echoed out right at that point -- if I am not mistaken. But the poof will be in the prudding.

Posted: Tue Jun 29, 2010 3:50 pm

I have split and moved the last part of this topic to our private forums.

P.S. I accidentally moved Montego's last post

montego wrote:

Regarding AutoTheme, we tried to integrate it a year or so back, but it needed too much work to get it to be XHTML compliant (there may have been another issue, too, but cannot recall now). However, that was a long time ago and may be worth looking at again.