soo_page_numbers: page counting and navigation widgets

kostas45 · 2009-09-10 15:29:06

Stef, thank you for the tip.
However, to me it looks like reinventing the wheel…
I ‘ll see if I can come up to anything working.

Cheers,
Kostas

jsoo · 2009-09-11 01:43:05

txpnisti wrote:

So it is something with my setup then.

I’m not certain that it is, but I think so. I’ve just tested a similar setup, with a search input form in one section and the search results in another, and I am getting correct links from soo_page_links. (You can see this by going to the Txp section of my website and typing a search term into the search box at the bottom of the page (which I’ve just stuck there temporarily). Try a term such as “textpattern” to get a few pages of results. I’ve stuck both the <txp:older /> and <txp:newer /> tags as well as soo_page_links onto the page.

I’ve tried this both with the <txp:search_input section="search" /> tag and with hard-coded HTML, and both worked on my setup. Are you using <txp:search_input />?

Along the subdomain installation, I also have MLP installed. These both maybe could affect. But it still doesn’seem to mess with languages, just with sections.

I vaguely recall that MLP does some URL manipulation and quite possibly there is an incompatibility with my plugin. I will look into this, but will probably not be able to for a few days.

jsoo · 2009-09-11 01:49:25

kostas45 wrote:

I am using smd_query in a form to do fulltext search against keywords field.
I am trying to figure out if I can use your plugin to paginate resulting rows.

soo_page_numbers depends on the global $thispage array. In short, it only paginates output from a <txp:article /> tag. So I doubt it will work with results from smd_query.

kostas45 · 2009-09-11 06:23:56

jsoo wrote:

soo_page_numbers depends on the global $thispage array. In short, it only paginates output from a <txp:article /> tag. So I doubt it will work with results from smd_query.

Ah, I see.
I suspected so, but was not in the Help, so now I know.

Thanks anyway,
Kostas

txpnisti · 2009-09-11 06:35:08

jsoo, I’m using hardcoded input, but I’don’t think that make any difference here. Maybe it is something with the MLP.

jsoo · 2009-09-11 09:52:32

txpnisti wrote:

jsoo, I’m using hardcoded input, but I’don’t think that make any difference here. Maybe it is something with the MLP.

I’m quite sure you’re right about hardcoded vs. tag — I don’t think search_input does anything tricky. It does use a hidden input for the section instead of including it in the action attribute; I doubt that will make a difference, but you might try it just to check.

After some looking into MLP, I see that the issue is that MLP changes the value of $_SERVER['REQUEST_URI'], on which my plugin depends. Furthermore, MLP makes every effort to be first in line — highest priority plugin load order, a callback on pretext, and even sneaks to the front of the callback array for good measure. I don’t know that it will be possible for me to get around this and achieve compatibility with MLP.

Although maybe, just maybe, if I try the same trick of jumping to the front of the callback array, I would get in ahead of MLP by keeping a standard medium-priority plugin load order. Turnabout is fair play. When I have time I will certainly look into this.

Edit: Still, what surprises me is that when I had a previous issue with MLP and pagination in a different plugin, the resolution was a simple MLP issue. That other plugin uses the same mechanism for pagination as this one. Now I am wondering why that worked, given MLP’s manipulation of $_SERVER['REQUEST_URI'].

Last edited by jsoo (2009-09-11 10:14:54)

jsoo · 2009-09-17 00:01:56

jsoo wrote:

*maybe, just maybe, if I try the same trick of jumping to the front of the callback array, I would get in ahead of MLP by keeping a standard medium-priority plugin load order. Turnabout is fair play. When I have time I will certainly look into this.

~~I think this works!~~ (Edit: see next post) txpinsti, I’ve just tried this with a test MLP installation, and it seems to be working. Can you help me test this? Exact procedure depends on whether you are using the standalone version of soo_page_numbers, or in conjunction with soo_txp_obj. In either case, the editing needs to be done wherever you have the class soo_uri declaration. ~~Just above the class definition add these lines:~~

register_callback('soo_uri_mlp', 'pretext');
function soo_uri_mlp() {
	global $soo_request_uri;
	$soo_request_uri =  $_SERVER['REQUEST_URI'];
}

Then inside class soo_uri, in the __construct() function, look for this line:

	$this->request_uri = $_SERVER['REQUEST_URI'];

~~and replace it with these lines:~~

	global $soo_request_uri;
	$this->request_uri = $soo_request_uri;

Last edited by jsoo (2009-09-17 11:15:39)

jsoo · 2009-09-17 10:48:05

OK, hold that thought: not quite working yet. Forgot that working on a plugin in the local plugin cache gives you a different load sequence.

jsoo · 2009-09-17 11:15:06

OK, I’ve now tested this with a regularly-installed plugin (not in the cache), and also followed my own suggestion for jumping the callback queue. So, the following code goes above the soo_uri class declaration:

global $plugin_callback;
if( is_array($plugin_callback) and $plugin_callback[0]['function'] == '_l10n_pretext' )
	array_unshift($plugin_callback, array(
		'function'	=>	'soo_uri_mlp', 
		'event'		=>	'pretext', 
		'step'		=>	'', 
		'pre'		=>	0 
	));

function soo_uri_mlp() {
	global $soo_request_uri;
	$soo_request_uri =  $_SERVER['REQUEST_URI'];
}

and then the first line of soo_uri::__construct() is replaced by this:

	global $soo_request_uri;		
	$this->request_uri = $soo_request_uri ? $soo_request_uri : $_SERVER['REQUEST_URI'];

This is working correctly on my test MLP installation, for a search setup similar to txpinisti’s.

Last edited by jsoo (2009-09-17 11:18:05)

jsoo · 2009-09-18 14:14:18

The download page now has an updated version of the library plugin, including the above changes.

THE BLUE DRAGON · 2009-09-22 09:34:13

Hey thank you for the plugin! =)

I’m having one problem that I got this code before the pagging:

<txp:php>
  $_GET['zem_contact_send_article']='yes';
</txp:php>

so when I click on a page number the url become: http://www.domain.com/news/blalba?zem_contact_send_article=yes&pg=2
I know you made it to be like this for working with plugins’ params,
but is there a way to disable it please?
(so there will not be: zem_contact_send_article=yes in the url [or any other plugin])

THE BLUE DRAGON · 2009-09-22 11:14:14

2. ~~I found something: (a bug I think)~~
when using pageby="10" and pagging to page #12+
the <txp:article /> is disappear and not geting loaded.

(this post has nothing to do with my prev post above)

Last edited by THE BLUE DRAGON (2009-09-22 12:00:15)

Textpattern CMS

Textpattern CMS support forum

#25 2009-09-10 15:29:06

Re: soo_page_numbers: page counting and navigation widgets

#26 2009-09-11 01:43:05

Re: soo_page_numbers: page counting and navigation widgets

#27 2009-09-11 01:49:25

Re: soo_page_numbers: page counting and navigation widgets

#28 2009-09-11 06:23:56

Re: soo_page_numbers: page counting and navigation widgets

#29 2009-09-11 06:35:08

Re: soo_page_numbers: page counting and navigation widgets

#30 2009-09-11 09:52:32

Re: soo_page_numbers: page counting and navigation widgets

#31 2009-09-17 00:01:56

Re: soo_page_numbers: page counting and navigation widgets

#32 2009-09-17 10:48:05

Re: soo_page_numbers: page counting and navigation widgets

#33 2009-09-17 11:15:06

Re: soo_page_numbers: page counting and navigation widgets

#34 2009-09-18 14:14:18

Re: soo_page_numbers: page counting and navigation widgets

#35 2009-09-22 09:34:13

Re: soo_page_numbers: page counting and navigation widgets

#36 2009-09-22 11:14:14

Re: soo_page_numbers: page counting and navigation widgets

Board footer