112
Well, I've answered my own question! Here's how you do it:
First off, the search form needs to include those elements that you need to send to the submit page to make it work. In this case, all I need is the forum elements present on the standard XOOPS search block, along with the additional checkbox element that tells the search page to limit searches to my module. This additional element has it's display set to 'none' so as not to confuse the user.
First off, add a statement like the following to the php page associated with whatever page you need your module specific search on:
Second, add the following code to the appropriate template page that the above php uses to generate the html for the user:
That's it! I hope this helps someone out. Feel free to use and/or post this code however you like!
First off, the search form needs to include those elements that you need to send to the submit page to make it work. In this case, all I need is the forum elements present on the standard XOOPS search block, along with the additional checkbox element that tells the search page to limit searches to my module. This additional element has it's display set to 'none' so as not to confuse the user.
First off, add a statement like the following to the php page associated with whatever page you need your module specific search on:
$xoopsTpl->assign('thisModuleID', $xoopsModule->getVar( 'mid' ));
Second, add the following code to the appropriate template page that the above php uses to generate the html for the user:
<form style="margin-top: 0px;" action="<{$xoops_url}>/search.php" method="get">
<input type="text" name="query" size="34" />
<input type="hidden" name="action" value="results" /><br />
<span style="display: none"><input type='checkbox' name='mids[]' value='<{$thisModuleID}>' checked='checked' />module name could go here, but we don't care since it's hidden anyway</span>
<input type="submit" value="Submit" />
</form>
That's it! I hope this helps someone out. Feel free to use and/or post this code however you like!
113
I apologize in advance if this is in the wrong forum or if this has been answered before.
I am in the process of creating my first custom module for an intranet site. I am basing it off Magazine (which was based off WF-Sections). I would like to include an area on each page in the module that contains a search "block" of sorts.
I want this to function like the advanced search page. I don't want to display all the module names, however. Instead, I would like to hardcode this to limit searches to this specific module. If the user wants to do a specific search, there are the general XOOPS search facilities located elsewhere in the theme.
The search.php code just confuses me, so I was wondering if someone had done this before for one of their themes and had some quick and handy code they could paste here to help me out.
Beyond that, a quick and dirty explanation of how it works would be great -- I'd love to have a better understanding of how this works.
Thanks in advance!
I am in the process of creating my first custom module for an intranet site. I am basing it off Magazine (which was based off WF-Sections). I would like to include an area on each page in the module that contains a search "block" of sorts.
I want this to function like the advanced search page. I don't want to display all the module names, however. Instead, I would like to hardcode this to limit searches to this specific module. If the user wants to do a specific search, there are the general XOOPS search facilities located elsewhere in the theme.
The search.php code just confuses me, so I was wondering if someone had done this before for one of their themes and had some quick and handy code they could paste here to help me out.
Beyond that, a quick and dirty explanation of how it works would be great -- I'd love to have a better understanding of how this works.
Thanks in advance!
114
Not to my knowledge. There are a couple of other webmasters, but they leave 99% of the stuff to me. I've been out of the office (holiday, vacation) nearly all the days from 6/29 to 7/18. I can remember no administrative functions related to the forum that I would have attempted during this time.
Thanks for the post.
Thanks for the post.
115
Xoops: 2.0.13.2
CBB: 3.04
I manage a XOOPS based intranet portal using CBB as my forum. I've had complaints of notifications disappearing. As far as I can tell, CBB is the only module that this happens with.
Here are a couple of screenshots showing the notifications for the same user on two different days. This user says that they did not remove any notifications -- that they just disappeared!
6/29/2006
7/18/2006
Does anybody have any ideas??
Thanks in advance!
CBB: 3.04
I manage a XOOPS based intranet portal using CBB as my forum. I've had complaints of notifications disappearing. As far as I can tell, CBB is the only module that this happens with.
Here are a couple of screenshots showing the notifications for the same user on two different days. This user says that they did not remove any notifications -- that they just disappeared!
6/29/2006
7/18/2006
Does anybody have any ideas??
Thanks in advance!
118
Thanks everyone for your postings. I've found them very helpful (special shout out to Brash for his excellent post).
Believe it or not, I'd never even noticed the block caching feature of XOOPS before. That's bad, I know. Anyway, the biggest difference to my site was made by caching the 'Main Menu' block. Each module gets parsed to see if it needs to have sub-items, and that process was really slowing me down.
So, I now have acceptable (3 seconds, instead of 6 or 7) turn-arounds on the existing hardware. We still plan to purchase a new server, however, because of expected increased demands in usage that are coming. But, because of everyone's great feedback, I am now pulling way back on what my reccomendation for that hardware will be.
Thanks again everyone.
Believe it or not, I'd never even noticed the block caching feature of XOOPS before. That's bad, I know. Anyway, the biggest difference to my site was made by caching the 'Main Menu' block. Each module gets parsed to see if it needs to have sub-items, and that process was really slowing me down.
So, I now have acceptable (3 seconds, instead of 6 or 7) turn-arounds on the existing hardware. We still plan to purchase a new server, however, because of expected increased demands in usage that are coming. But, because of everyone's great feedback, I am now pulling way back on what my reccomendation for that hardware will be.
Thanks again everyone.
119
Sorry if this is in the wrong forum...
Here's what I know:
1) Your XOOPS installation can contain multiple themes.
2) Webmaster can specify a default theme for XOOPS to render in.
3) You can enable the Theme's block and choose which installed themes show up in that block.
4) Users can choose whatever theme the like from that box.
5) That choice is retained until the browser is restarted.
Question:
Is there any way to persist this information between restarts? Can a user's theme choice be stored as a cookie or in the XOOPS database so that they don't have to keep choosing it whenever they return to your site?
Thanks in advance!
Here's what I know:
1) Your XOOPS installation can contain multiple themes.
2) Webmaster can specify a default theme for XOOPS to render in.
3) You can enable the Theme's block and choose which installed themes show up in that block.
4) Users can choose whatever theme the like from that box.
5) That choice is retained until the browser is restarted.
Question:
Is there any way to persist this information between restarts? Can a user's theme choice be stored as a cookie or in the XOOPS database so that they don't have to keep choosing it whenever they return to your site?
Thanks in advance!
120
Wow, I'm kind of surprised that this discussion hasn't generated more interest. Am I the only one out there with this challenge??
Anyway, I've turned on the MySQL debug mode and documented the query counts and page generation times for several pages on my site:
home page: 103 queries - 4.0959119796753 seconds to load.
pd-downloads root: 143 queries - 6.2500469684601 seconds to load.
pd-downloads category: 49 queries - 3.7887420654297 seconds to load.
wiki root: 66 queries - 4.8866550922394 seconds to load.
admin root: 4 queries - 1.0515160560608 seconds to load.
search: 43 queries - 7.092022895813 seconds to load.
It's early in the morning here and I'm the only person on the server. In other words, the numbers above are best case.
So what's the best plan of attack here? Can server software (apache, mysql, etc.) optimization really make a significant difference in these load times? Would running this setup from a newer and faster box make enough of an impact on the turn around times? Or, is 103 queries to the same MySQL database always going to result in several seconds of waiting?
Thanks in advance guys! Sorry to be such on noob on this stuff!
Anyway, I've turned on the MySQL debug mode and documented the query counts and page generation times for several pages on my site:
home page: 103 queries - 4.0959119796753 seconds to load.
pd-downloads root: 143 queries - 6.2500469684601 seconds to load.
pd-downloads category: 49 queries - 3.7887420654297 seconds to load.
wiki root: 66 queries - 4.8866550922394 seconds to load.
admin root: 4 queries - 1.0515160560608 seconds to load.
search: 43 queries - 7.092022895813 seconds to load.
It's early in the morning here and I'm the only person on the server. In other words, the numbers above are best case.
So what's the best plan of attack here? Can server software (apache, mysql, etc.) optimization really make a significant difference in these load times? Would running this setup from a newer and faster box make enough of an impact on the turn around times? Or, is 103 queries to the same MySQL database always going to result in several seconds of waiting?
Thanks in advance guys! Sorry to be such on noob on this stuff!
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | May 31 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|