191
Draven
Re: Cutting out the Geeky stuff!
  • 2003/11/17 23:09

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


[EDIT: this was posted at the same time as mvandam, sorry]

I'd just like to note that everything people have mentioned so far, aside form the smilie problem in forms, can be easily dealt with in the templates. All the reads/views etc. are just variables being displayed in side loops. Remove the <{$read}> and <{$views}> (these are just examples, not actual varible names) and you solve the problem. Now I understand for the "non designer" type, it'd be easier to just have a switch in the module admin to choose whether or not to show them (which I assureyou we'll do our best to accomdaite in the future), but it's not hard to remove them now if you really need to.



192
Draven
Re: Cutting out the Geeky stuff!
  • 2003/11/16 18:45

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

regen_r8 wrote:
When the decision was made to separate the templates from the themes back in January, there should have been some thought to having the modules ship with some alternate templates.


This is precisely what I will be doing with most of the XOOPS Certified Modules (Think old "core" modules). It will also be the resposibility of the new Package team to assemble XOOPS site packages (incl. templates , modules, functions) to suit different needs. Basically we'll be starting with something like News site, Magazine site, community site, etc. The beauty of this is the modules, well the templates mostly, can be designed to suit the sites needs (eg, turning of read counts).

but it would be nice to have the ability to switch such options off within the module administration.


Duly noted. Thanks.

At the moment I'm having to heavily customise my XOOPS installation to be suitable for the use I have in mind... although this does hold one major advantage - it won't look like "yet another XOOPS site" when it goes live!


My personal goal for XOOPS has always been to try as best as possible to seperate us from other "Nuke" looking sites. I've made a few minor suggestions to the core team that will greatly help the "skining" ability for XOOPS in the future. Skalpa was so kind as to put those in the next version and made a few improvements of his own, so stay tuned.



193
Draven
Re: I need a webhosting with unlimited transfer
  • 2003/11/15 20:30

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Just so you know, there is no such thing as unlimited transfer. Companies may advertise it, but as soon as you start to abuse it, they'll shut you down. Trust me. I am the Web Director for a domain registration and hosting company and I hear it from people everyday. They come to us after their old host shut them down, even though they say "unlimited Bandwidth". All they do is say you're using too much of the servers other resources and you need to go dedicated (Or whatever their higher packages are).

So be carefull. And remeber nothing is ever free, or in this case unlimited.



194
Draven
Re: Jobs?
  • 2003/11/14 23:59

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

MithyT2 wrote:
it's unpaid, though

What!!! We don't get paid? I quite!



195
Draven
Re: Apache mod_rewrite RewriteRule Success
  • 2003/11/13 16:12

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Keep me posted. I'm very intersted in this (incase you didn't already know )



196
Draven
Re: Smarty or XOOPS variable indicating location of block?
  • 2003/11/8 21:41

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


What exactly are you trying to do? I don't think there is anything from within the block you can use. If you just trying to have 2 different layouts for the same block, why not just make a block option that allows you to assign the position for the function?



197
Draven
Re: Apache mod_rewrite RewriteRule Success
  • 2003/11/8 21:34

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Just had an idea. What if we just matched everything up to the page name, then returned everything else after that as one var?

So if we had:

http://mysite.com/library/articles/artilceid/3/page/4/var/value

and matched it so the server just turned it to:

http://mysite.com/modules/wfsections/article.php?var_val=artilceid/3/page/4/var/value

Then let a small php function break up the var/val from $var_val pairs after the server returns it? Something like

Quote:

$vararray = explode("/",$var_val);

// Our array would look like array("artilceid","3","page","4","var","value");

//then a for loop like this would release everything to the name sapce

for($i=0, $i != count($vararray);$i++){
$$vararray[$i] = $vararray[$i++];
}



even if $page had no value it would still assign $page as "". I think. My heads kind of spinning at the moment.



198
Draven
Re: Apache mod_rewrite RewriteRule Success
  • 2003/11/8 21:16

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


What if you just ran a buch of different scenarios, with a max of say 5 (I don't think any modules pass more than 5 var/values pairs.)

So wether your URL was:
/modules/wfsection/articles.php?articleid=31&page=2&var=value&var=value&var=value
/modules/wfsection/articles.php?articleid=31&page=2&var=value&var=value
/modules/wfsection/articles.php?articleid=31&page=2&var=value
/modules/wfsection/articles.php?articleid=31&page=2
/modules/wfsection/articles.php?articleid=31

You'd have:
RewriteRule ^library/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+) /modules/wfsection/$1.php?$2=$3&$4=$5&$6=$7&$8=$9&$10=$11 [L]
RewriteRule ^library/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+) /modules/wfsection/$1.php?$2=$3&$4=$5&$6=$7&$8=$[L]
RewriteRule ^library/([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+) /modules/wfsection/$1.php?$2=$3&$4=$5&$6=$[L]
RewriteRule ^library/([^/]+)/([^/]+)/([^/]+)/([^/]+) /modules/wfsection/$1.php?$2=$3&$4=$[L]
RewriteRule ^library/([^/]+)/([^/]+) /modules/wfsection/$1.php?$2=$[L]
RewriteRule ^library(.*)$ $[L]


Now this could get quite confusing for a user to try and manage, so what if the core was to be resposible for writing, and rewriting, the htaccess file everytime a module is installed or uninstalled? Then you could allow the module developers to write the rewrite functions needed ONLY for their modules? The would know exactly how many var/value pairs are used in their modules. If only 2 then they only need two.

Hmmm, this is getting very interesting. In fact the core could then take the default module rewrites (Provide in some module config file) and then alter them on the fly to include the custom DIR names set in the Xoops_version file by a user. This way the user could set custom folder names (my "/library/" part of the example) in the xoops_version file.



199
Draven
Re: one small step for a man . . .
  • 2003/11/7 19:52

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Quote:

1. What is $xoopsOption, and what does this line do:

$xoopsOption['template_main'] = 'news_index.html';

I think what it does is tell the php file what SMARTY template to use (although on the smarty site the template files are .tpl, not .html). Is that right?

You are correct. You can use .html to call the main template files, then within the SMARTY template you can include both .html and .tpl files using the include function.
Quote:

2. Why is it that $xoopsOption is used for things like:
$xoopsOption['storytopic']
$xoopsOption['storynum']

. . . but $xoopsTpl->assign(...) is used for everything else?

In other words, if 'storytopic' and 'storynum' aren't needed for the template, why not just save them as scalar variables $storytopic and $storynum? Why do you want them as part of the $xoopsOption object? Perhaps knowing the answer to #1 above will help me understand this.


I'd have to double check the code again to know the exact answer here. I can say that $xoopsTpl->assign is used to pass on variables to the SMARTY template.
Quote:


3. At the bottom of the index.php file, there are a bunch of what look like config assignments:

$xoopsTpl->assign('lang_go', _GO);
$xoopsTpl->assign('lang_on', _ON);
$xoopsTpl->assign('lang_printerpage', _NW_PRINTERFRIENDLY);
$xoopsTpl->assign('lang_sendstory', _NW_SENDSTORY);
$xoopsTpl->assign('lang_postedby', _POSTEDBY);
$xoopsTpl->assign('lang_reads', _READS);

Are these required all the time? I can't find where they are used, or how they are used. They don't show up in the template file at all.

Thanks in advance for any help.


Those are language constants (_GO = word "GO" used in a submit button), you find them in the language file



200
Draven
Re: Apache mod_rewrite RewriteRule Success
  • 2003/11/7 18:38

  • Draven

  • Module Developer

  • Posts: 337

  • Since: 2003/5/28


Your example above still requires the key value pairs being passed through the URL in a normal fasion (?this=that). What I'm talking about is writing a url as

http://www.mysite.com/library/articles/articleid/31/page/2


While the above isn't a shorter url it does do one very important thing, it romves the "?" from the URL which is what trips up most search spiders.

Now if there was a way to have mod_rewrite - Keep in mind I'm not all that familiar with this function of apache so I may be missing something - rewrite the url to something like

/modules/wfsection/articles.php?articleid=31&page=2


that would be great. Now this could be done I suppose in this type of fashion:

1. match the first directory against some list of modules where we know /library/ is equal to /modules/wfsections/

2. Then match the next directory in the URL to a php file, in this case /articles/ is equal to /articles.php.

3. Anthing after the page match is a var=value par. simple php loop can determine that.

So the URL is broken up like this

http://[domain name]/[module alias]/[page name]/[var/value]

Once this works for one module it would work for all. The only thing taht might trip it up a bit is sub directories of the main, but if you mape the sub direcotries to the [module alias] it won't matter. The nice things is the [module alias] could be set in the Xoops_version file. Mean while never actually changing the modules absolute path.

Hope this makes sense. It does in my brain, but getting it our is the hard part.

-----

As for the problem of writing the initial url, this is a bit of work since there would need to be a common makeurl() function used in all modules and the core. The nice thing with that is you could have error checking for broken links easily incorporated into such a function.

Something like this:

Quote:

function makeUrl($mod_path,$mod_alias, $page_name, $var_array){

// error check, does this file exist?
if(!file_exists($mod_path.$page_name){
$error = 'return an error, page doesn't exist';
return $error;
}

// assemble var value paring
$count = count($var_array);
if(is_array($var_array)){
for($i=0;$i!=$count;$i++){
var_val .= $var_array[$i]['var'].'/'.$var_array[$i]['value'];
($i < $count)? var_val .= '/':'';
}
}

// strip the ".php" off the page name
$page = substr($page,0,strpos(".php",$page));

// assemble new url
$url = $mod_alias.$page."/".var_val;

return $url;


Don't use the above, it's not tested but you get the idea.




TopTop
« 1 ... 17 18 19 (20) 21 22 23 ... 26 »



Login

Who's Online

140 user(s) are online (109 user(s) are browsing Support Forums)


Members: 0


Guests: 140


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits