Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 8 9 [10]
 91 
 on: February 10, 2013, 06:42:48 PM 
Started by Fred K - Last post by nukpana
Not trying to argue, but....

Function archives? contact?

Did you look at the fix I posted?
http://snewscms.com/forum/index.php/topic,9272.0.html
 - other than the admin pages, which could be "hacked" into, I think this should work for you.

Did you miss the first screenshot I posted? in the previous post? Showing a contact me extra in the archive page?

The group could be a block of content or an area in the page. Name it what you want, it will still work the same.

Code: [Select]
<header id="masthead">
<?php echo extra('header-block'); ?>
</header>
<article>
<?php 
  
echo content(); 
  echo 
extra('post-content');
  echo 
comments();
?>

</article>
<aside>
<?php echo extra('aside-block'); ?>
</aside>
<footer>
<p>blah blah</p>
<?php echo extra('footer-block'); ?>
</footer>

I think we are describing the same thing.. a bit differently, but it is the same concept


re: Blizzard...
I am not bad, but people I know are still not plowed out. Thankfully everyone still has power..

 92 
 on: February 10, 2013, 06:31:40 PM 
Started by Fred K - Last post by Fred K
Yes I know extra contents have always been in the articles' table and originally multiple extras weren't available but with your contribution they now are, which is great.
What I am trying to accomplish though isn't something within the old but different from the old, in terms of how extra contents are handled.

1. Create extra content.
2. Where you want that extra to appear, call it with <?php extra('extra-content-seftitle'); ?>.
That's my scenario. Nothing else.

Now, yes, with the different layout of the extra table you propose (which is roughly the same as I had in mind) you could also create extra groups if you want (and that could be handled with a filter I suppose), but the main idea with "my scenario" is that extra content can be called in *anywhere*. Like functions archive(), or contact(), or menu_articles(), or new_comments(), to name a few. That's what I'm trying to do.
In essence, you *can* use extra groups if you like, but calling extra _content_ should not be limited by the extra content belonging to a group.

So it's not the same as the current extra function, given how it's used. It's the "same but different".
Also, I don't see current behaviour (or original behaviour for that matter) as a "bug", never have. I just want a different solution because I think it would improve certain aspects of it. If I can get it to behave as I want. ;)

so how's the blizzard going? Hope it's not too devastating.

 93 
 on: February 10, 2013, 05:13:37 PM 
Started by Fred K - Last post by nukpana
Right now, extras have always been part of the articles table.  The "extras" tables was trying to group the extras into logical blocks of content

Logically speaking, yes, each section should be modular to the whole.

Ideally, the tables should be:
Block                  - id, name (seftitle), content
Block Group        - id, name
BlockGroupAssoc - group_id,  block_id

Now in this scenario, one can do with or without the groups if so desired.

Quote
In my scenario, groups aren't needed at all.
Since I don't know your scenario, then in general I disagree -  I think the system is not configured properly to handle the extras anywhere, hence why I saw an immediate need to try and fix the issue - which no one claimed to be a bug.  There are endless amounts of possibilities if used correctly.

Now, I can use extras in the home/base pages (using my fix above), but it doesn't note the group name here, nor can I multi-select items within the extra content creation. And, for now, it can't be used with the admin pages....


Using 2 extra groups - one placed on the top and one normal one in the sidebar:


 94 
 on: February 10, 2013, 04:09:39 PM 
Started by Fred K - Last post by Fred K
Thanks! I looked at the 1.6 code and it seems promising.
What I'm having some problems understanding though is why it seems like although the db query is directed at articles, and what the function is looking for is 'seftitle', extra content is called in depending on *group seftitle*, which is set in the extra table and so shouldn't be part of the function at all.

What I mean is: query = SELECT blabla,seftitle,blabla FROM ._PRE.articles
result = group seftitle / extra content (regardless of seftitle).
= weird. (or maybe it's just me).

What I'd like is: query = SELECT blabla,seftitle,blabla FROM ._PRE.articles
result = extra content seftitle (LIMIT seftitle).

In my scenario, groups aren't needed at all.
Reworking my test in a more substantial way by removing the extra group parts from article contents form and processing. Thinking about putting extra content parts in "extras" db table, just to see what the fallout might be. Logistically speaking, extra content should be in extras table anyway, imo...

 95 
 on: February 10, 2013, 02:42:22 AM 
Started by Fred K - Last post by nukpana
My initial idea on this was here for 1.6: http://snewscms.com/forum/index.php/topic,5977.0.html

I chose the group route, which came into 1.7, as you well know.

For 1.7, my "fix" to allow Extras on base pages including Home is here:
http://snewscms.com/forum/index.php/topic,9272.0.html

In the refactoring thread, I simplified it even more - but probably needed more to it... (above fix perhaps?):
http://snewscms.com/forum/index.php/topic,8391.msg61617/topicseen.html#msg61617

To me, the extra grouping would be ideal in this fashion:
Code: [Select]
<aside>
<?php foreach( extra('asideGroup') as $k => $block ) { ?>
<div class="extra">
<?php echo $block['content']; ?>
<?php echo $block['admin_link']; ?>
</div>
<?php ?>
</aisde>
You then regulate the content to the group, then what page (not the sNews type). Now it doesn't matter what the extra is, it is called within the group that it is associated with.

Let me know if I am understanding or misunderstanding you - but you should have some filtering reference in the above links

 96 
 on: February 09, 2013, 07:31:42 PM 
Started by Fred K - Last post by Fred K
So I had this idea that the extra content/extra grouping thing could be simplified to basically allow us to print a specific extra content, controlled by its seftitle, where ever. The result would be that you could do something like this in index.php:

Code: [Select]
<div class="extra">
<?php echo extra('seftitle1'); ?>
</div>

and for example on a page you could do a sidebar with a couple of other extras:

Code: [Select]
<aside>
<div class="extra">
[func]extra:|:seftitle2[/func]
</div>
<div class="extra">
[func]extra:|:seftitle3[/func]
</div>
<div class="extra">
[func]extra:|:seftitle4[/func]
</div>

The aim with this simplification is to remove the need for groupings and still be able to print just the specified extra content in the desired place.

I started out with a simplified version of function extra(), but it is obviously not enough as it in the current form will print all existing extra content in the same slot, so some kind of filtering is required and that's where I'm stuck.

Here's what I have now, which works but not as desired:

Code: [Select]
<?php
// CONTENT BLOCK (e.g Simple Extra)
function block($getBlock='') {
if(!_ADMIN$qwr ' AND visible=\'YES\''; else $qwr '';
$getBlock retrieve('seftitle');
$sql 'SELECT id,title,seftitle,text,position,displaytitle,visible 
FROM '
._PRE.'articles'.' WHERE published = 1 AND position = 2 ';
$query $sql.(!empty($getBlock) ? ' AND seftitle = '.$getBlock '');
$query $query.$qwr.' ORDER BY artorder ASC';
$result mysql_query($query) or die(mysql_error());
while ($r mysql_fetch_array($result)) {
if ($r['displaytitle'] == 'YES') {
echo '<h3>'$r['title'] .'</h3>';
}
file_include($r['text'], 9999000);
$visiblity $r['visible'] == 'YES' '<a href="'._SITE.'?action=process&amp;task=hide&amp;item=cy_articles&amp;id='.$r['id'].'&amp;back='.$url.'">'.l('hide').'</a>' l('hidden').' <a href="'._SITE.'?action=process&amp;task=show&amp;item=cy_articles&amp;id='.$r['id'].'&amp;back='.$url.'">'.l('show').'</a>';
echo _ADMIN '<p><a href="'._SITE.'?action=admin_article&amp;id='.$r['id'].'" title="'.l('edit').' '.$r['seftitle'].'">'.l('edit').'</a>'.' '.l('divider').' '.$visiblity.'</p>' '';
}
}
?>

Usage: where a block should appear, do <?php echo block('seftitle'); ?>, where 'seftitle' of course is replaced by an existing content block's seftitle.

The main reason I'd like to do this simplified version, apart from eliminating the need for groupings, is that extras (content blocks) would then be infinitely usable anywhere, including on home page or other system pages, and (in my view) easier to use and explain.

So, how or what do I do to be able to print specified extras (content blocks), given the current construction? Obviously changes will need to be made to articles form and processing, and the db would be altered, but that's a smaller problem.

Most grateful for tips, pointers etc.

// EDIT
I added a limiter, similar to archive(), and although it works it isn't quite the solution I want.

 97 
 on: February 09, 2013, 05:47:42 PM 
Started by Fred K - Last post by Fred K
Yup, now even I get it... :D
Works just fine, thanks. And yes, there are a few really nice (albeit cosmetic) uses for it.

 98 
 on: February 09, 2013, 05:24:49 PM 
Started by Fred K - Last post by Keyrocks
Confirmed - works OK Jason. :)
I just put the last part in index.php where I wanted it displayed... could go anywhere within the template.

 99 
 on: February 09, 2013, 05:29:02 AM 
Started by Fred K - Last post by nukpana
Evil bunnies are falling in droves.....

This works....
Code: [Select]
<?php

if(isset($_POST['Loginform']) && !_ADMIN) {
$user checkUserPass($_POST['uname']);
$pass checkUserPass($_POST['pass']);
unset($_POST['uname'],$_POST['pass']);
// Patch #18 - 1.7.1 - revised string by KikkoMax
if (checkMathCaptcha() && md5($user) === s('username') && md5($pass) === s('password')) {
//if (md5($user) === s('username') && md5($pass) === s('password') && checkMathCaptcha()) {
$_SESSION[_SITE.'Logged_In'] = token();
// EQ
$_SESSION['user'] = $user;
notification(2,'','administration');
} else { die( notification(2,l('err_Login'),'login')); }
}
// EQ
function getUserName() {
return isset($_SESSION['user']) 
$_SESSION['user']
false;
}
if( 
getUserName() ) {
echo 'Welcome ' getUserName() .'! Evil Bunnies are falling!';
}

?>


... again, untested, unapproved, and those evil bunnies better not make me lose power...
http://usnews.nbcnews.com/_news/2013/02/08/16895255-this-is-it-mammoth-winter-storm-lashes-northeast?lite

 100 
 on: February 09, 2013, 12:33:13 AM 
Started by Fred K - Last post by Fred K
Well, it doesn't work in my setting and, as far as I can tell, it shouldn't work, because the first part ($_SESSION['user'] = $user;) is placed within the block that is conditioned by if(isset($_POST['Loginform']) && !_ADMIN)
and I'm trying to print the username when in _ADMIN...

And (@Doug and Jason), decrypting encrypted data is a can of worms. Which, as stated, is why I'm rethinking the whole thing. That said, if md5 isn't strong enough an encryption thingy then considering an alternative might be a good thing...y. :P

Pages: 1 ... 8 9 [10]