date:20160126

Using counter

2016-01-26 Thread TMurNGon

Hi Dan,

I've been trying to apply your example shown on the functions/counter page 
of the documentation, but I keep getting stuck...

If I use the following it does suppress the output, but it also does not 
increment the counter (so the Total result remains 0 which is incorrect):

{(search group=docs* fmt="[(counter id=total)]" count=false output=false)}
Total Pages: <(counter 0 id=total)>


If I use the following it does not suppress the output, but it does 
increment the counter correctly:

{(search group=docs* fmt="[(counter id=total)]" count=false output=true)}
Total Pages: <(counter 0 id=total)>

Any suggestions on how I can set the correct value of Total without getting 
any output from the search?

Thanks lots.
Jan

-- 
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to boltwire+unsubscr...@googlegroups.com.
To post to this group, send email to boltwire@googlegroups.com.
Visit this group at https://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.

Re: introduce BOLTsearchReultsType

2016-01-26 Thread Tiffany Grenier

About this, in order to have the same results as expected in the original 
attempt of TMurNGon, I would advise doing
[(search group={p}.* fmt=toc when='! inlist header,footer,
side,license,support,links,comments,invites,attachments {+page}' 
type=-number)]
instead of
[(search group={p}.* 
type=-header,footer,side,license,support,links,comments,invites,attachments 
fmt=toc when='! number {+page}')]
since some.page.1-123 will be accepted by when="! number {+page}" but 
rejected by type=-number
Cheers,
Tiffany

Le mardi 26 janvier 2016 06:56:13 UTC+1, TMurNGon a écrit :
>
> Great, thanks Dan.  I will give it a go.
>
> On Monday, 25 January 2016 16:48:08 UTC+2, Dan wrote:
>>
>> The number type is a special case rule and it doesn't work with a list 
>> like you have given. Either you check for a number/-number or you check for 
>> a list of types/-list of types.
>>
>> To do what you want, you have two options--
>>
>> 1) Create a custom type rule which does what you want. More trouble but 
>> probably faster if you have a bunch of pages to process.
>>
>> 2) Use the when parameter to exclude numbers. 
>>
>> [(search group={p}.* 
>> type=-header,footer,side,license,support,links,comments,invites,attachments 
>> fmt=toc when='! number {+page}')]
>>
>> For that matter, just for fun, you should be able to do:
>>
>> [(search group={p}.* fmt=toc when='! number {+page} && ! inlist 
>> header,footer,side,license,support,links,comments,invites,attachments 
>> {+page}')]
>>
>> Cheers,
>> Dan
>>
>> On Mon, Jan 25, 2016 at 3:53 AM TMurNGon  wrote:
>>
>>> Hi Dan,
>>>
>>> Given all of the above, how would I structure a 'page search' to exclude 
>>> both a few named pages and number pages?
>>> I tried:
>>>
>>> [(search group={p}.* 
>>> type=-number,header,footer,side,license,support,links,comments,invites,attachments
>>>  
>>> fmt=toc)]
>>>
>>> but this does not seem to interpret 'number' as a being a numeric page 
>>> name.  It does exclude the named pages (footer, side, etc), but does not 
>>> exclude numeric pages; as [(search group={p}.* type=-number fmt=toc)] would.
>>>
>>> Also, what would be the appropriate syntax for specifically including 
>>> some pages and excluding others?  Once the '-' is specified it seems to 
>>> exclude all mentioned pages.
>>>
>>> Thanks.
>>> Jan
>>>
>>>
>>>
>>> On Sunday, 8 November 2015 13:35:32 UTC+2, Tiffany Grenier wrote:

 Hi again,
 It takes much longer to retrieve the results of [(search 
 group=some.page when="number {+p}")] than [(search group=some.page 
 type=number)]. Also, the results are slightly different because a page 
 named "some.page.1-0" would pass the second example and be removed from 
 the 
 first one. I need to discriminate between pages like "some.page.1" and 
 "some.page.1-0", and I wrote a BOLTCthread function that would validate 
 both, while BOLTCnumber only validates the one without the dash, and I 
 wanted these conditionals inside the search function.
 So I first thought about added "type=thread" (and modifying 
 "type=number").
 And then I considered putting in the type argument other conditions in 
 order to go much faster. Like for example type=subthread as replacement 
 for 
 when="thread {+parent} && thread {+p}", which led me to separated the 
 parat 
 of searchResults that does this check and use instead a hookable function.

 Thus I propose the following change:
 --- library.php Sun Nov 08 12:29:55 2015
 +++ library.php Sun Nov 08 12:30:48 2015
 @@ -1775,20 +1775,6 @@
   }
   if (count($outarray) == 0) return;
   if ($args['type'] == '') $args['type'] = BOLTconfig('searchType');
 - $outarray = BOLTsearchResultsType($outarray,$args);
 - if (count($outarray) == 0) return;
 - if ($args['sort'] == '') natcasesort($outarray);
 - elseif ($args['sort'] != 'false') $outarray = 
 BOLTsearchResultsSort($outarray, $args);
 - if ($args['order'] != '') {
 - if ($args['order'] == 'reverse' xor $args['sort'] == 'lastmodified') 
 $outarray = array_reverse($outarray);
 - if ($args['order'] == 'random') shuffle($outarray);
 - }
 - if ($args['when'] != '' || $args['count'] != '') $outarray = 
 BOLTsearchResultsWhenCount($outarray, $args);
 - return $outarray;
 - }
 - 
 -function BOLTsearchResultsType($outarray,$args) {
 - if (function_exists('myBOLTsearchResultsType')) return 
 myBOLTsearchResultsType($outarray, $args);
   if ($args['type'] == 'number') {
   foreach ($outarray as $p => $page) {
   $page = substr($page, strrpos($page, '.') + 1);
 @@ -1813,6 +1799,14 @@
   elseif (strpos($type, $page) !== false) unset($outarray[$p]);
   } 
   }
 + if (count($outarray) == 0) return;
 + if ($args['sort'] == '') natcasesort($outarray);
 + elseif ($args['sort'] != 'false') $outarray = 
 BOLTsearchResultsSort($outarray, $args);
 + if ($args['order'] != '')

Re: BoltWire 5.08

2016-01-26 Thread Tiffany Grenier

Hi,
Noticed a bug in 5.08 (and previous versions), with the count=start-end 
syntax cmbined with a when parametrer.
In BOLTsearchResultWhen, if ($count && $i > $end - 1) break; should 
actually be if ($count && $i > $start+$end-1) break;
Noticed this with count=21-40, where no result was shown.
Cheers,
Tiffany

Le mercredi 20 janvier 2016 06:16:23 UTC+1, TMurNGon a écrit :
>
> That's great news!
> Thanks Dan.
>
>
> On Tuesday, 19 January 2016 17:52:45 UTC+2, Dan wrote:
>>
>> I can do that. Actually, I have almost everything ready. There's only 
>> three modules I haven't "finished", and they just need a bit of polishing 
>> as I have them working elsewhere.
>>
>>  Notify -- being notified when pages are edited.
>>  Inbox -- part of the ez-news script for processing bounces.
>>  Store -- our ecommerce system using Simplify (like stripe).
>>
>> I wanted to get the Store up and running to handle payments for the 
>> XPack, but there's no reason I can't use PayPal now and release the modules 
>> I have...
>>
>> I'll try and get to it next week. I should add there may be a period of 
>> debugging and ironing stuff out as we try and get everything perfect. But 
>> that's easier if we have a few others looking at the code. And we're pretty 
>> close as I'm intentionally using core XPack features everywhere possible on 
>> the BoltWire site.
>>
>> Thanks for sharing our software with your company! Give me a week...
>>
>> Cheers,
>> Dan
>>
>>
>>
>> On Tue, Jan 19, 2016 at 1:23 AM TMurNGon  wrote:
>>
>>> Thanks for that Dan.
>>>
>>> Just asking:  Any chance of you releasing just a partial expansion pack 
>>> (just the bits that are complete to date)?
>>> I'm trying to convince the 'powers that be' to change to Boltwire for 
>>> our company intranet and some (most) of those components would be very 
>>> welcome.
>>>
>>> Just saying ;-)
>>>
>>> Thanks.
>>> Jan
>>>
>>>
>>> On Tuesday, 19 January 2016 04:23:41 UTC+2, Dan wrote:

 Despite my initial desire to have the expansion pack out by the first 
 of the year--I made the strategic decision to focus on a couple other 
 projects first. And I don't see any good openings in my calendar for the 
 next few months at least. 

 There is not a lot left to do--just really having fun with my other 
 projects, and wanting to program a bit less and enjoy life a bit more! :)

 I did just release another version of BoltWire with lot's of nice fixes 
 and improvements, but nothing dramatically different. I posted the 
 changelog below. If you are current, should be a good upgrade.

 Cheers,
 Dan



 *The Cutting Edge...**boltwire5.08.zip 
  January 18, 2016*

- Added a myBOLTskinVar['field'] = 'value' variable so can put 
{field} in skin and insert value. Similar to code.settings page, but 
 can 
control dynamically via php.
- Slight fix in sorting of search results when extra pages are 
included. Also can handle {+1} and {+2} in sort parameter.
- Slight fix to list function so handles no matches the same as 
search function.
- The last release introduced a new bug in the way search results 
were processed where counting took place after sorting. Fixing required 
splitting BOLTresortsWhenCount into two separate functions.
- Tweaked the set condition a bit more, so can do source=field and 
will return true if that post, get or cookie field set. Good for 
 testing if 
a multiline value is set that would otherwise break the markup.
- Improved BOLTfolders function so can put a site.folders page in 
the shared/pages folder.
- A couple slight improvements to the messaging controls in the 
index function.
- Slight improvements to how the type parameter in searches works. 
Now can do number/-number, and mycustom/-mycustom types, and even 
 override 
the default number handling by creating a custom myBOLTtypenumber 
 function.
- Minor tweaks in indexing. Now can do [(index rule=myrule 
batch=10)] and the batch setting will override the default value. Can 
 also 
do [(index 10)] and it will be the equivalent of [(index cron=10)]. And 
lastly, [(index)] will now default to the equivalent of setting the 
 cron 
parameter to whatever your default indexBatch value is.
- Have been having problems with the auto-login process, and think 
I have fixed it at last. Like before, just use a persist=1209600 
 parameter 
in the login command to keep logged in for two weeks. To get the 
 autologin 
effect, the user must visit a page with <(login)> on it--ideally in a 
 zone 
wrapped in a conditional checking their login status. Change to <(login 
persist=1209600)> to extend their auto

Re: Using counter

2016-01-26 Thread The Editor

Could you just do

Total Pages: <(search group=docs* fmt=count count=false)>

As for your question, though, if you change fmt to template it should work.
With fmt, the output is returned unprocessed--so the counter function is
not triggered within the search function. And since the output is
suppressed, it doesn't get triggered later as in the second case.

But when you use template, each match runs through the entire markup table
so it gets processed before returned. With the output suppressed, you never
see that output, but it is all processed. So then the final counter
function should work.

Cheers,
Dan


On Tue, Jan 26, 2016 at 8:13 AM TMurNGon  wrote:

> Hi Dan,
>
> I've been trying to apply your example shown on the functions/counter page
> of the documentation, but I keep getting stuck...
>
> If I use the following it does suppress the output, but it also does not
> increment the counter (so the Total result remains 0 which is incorrect):
>
> {(search group=docs* fmt="[(counter id=total)]" count=false output=false)}
> Total Pages: <(counter 0 id=total)>
>
>
> If I use the following it does not suppress the output, but it does
> increment the counter correctly:
>
> {(search group=docs* fmt="[(counter id=total)]" count=false output=true)}
> Total Pages: <(counter 0 id=total)>
>
> Any suggestions on how I can set the correct value of Total without
> getting any output from the search?
>
> Thanks lots.
> Jan
>
> --
> You received this message because you are subscribed to the Google Groups
> "BoltWire" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to boltwire+unsubscr...@googlegroups.com.
> To post to this group, send email to boltwire@googlegroups.com.
> Visit this group at https://groups.google.com/group/boltwire.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to boltwire+unsubscr...@googlegroups.com.
To post to this group, send email to boltwire@googlegroups.com.
Visit this group at https://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.

Re: BoltWire 5.08

2016-01-26 Thread The Editor

Thank you!  Will fix that for the next release.

On Tue, Jan 26, 2016 at 11:35 AM Tiffany Grenier 
wrote:

> Hi,
> Noticed a bug in 5.08 (and previous versions), with the count=start-end
> syntax cmbined with a when parametrer.
> In BOLTsearchResultWhen, if ($count && $i > $end - 1) break; should
> actually be if ($count && $i > $start+$end-1) break;
> Noticed this with count=21-40, where no result was shown.
> Cheers,
> Tiffany
>
>
> Le mercredi 20 janvier 2016 06:16:23 UTC+1, TMurNGon a écrit :
>>
>> That's great news!
>> Thanks Dan.
>>
>>
>> On Tuesday, 19 January 2016 17:52:45 UTC+2, Dan wrote:
>>>
>>> I can do that. Actually, I have almost everything ready. There's only
>>> three modules I haven't "finished", and they just need a bit of polishing
>>> as I have them working elsewhere.
>>>
>>>  Notify -- being notified when pages are edited.
>>>  Inbox -- part of the ez-news script for processing bounces.
>>>  Store -- our ecommerce system using Simplify (like stripe).
>>>
>>> I wanted to get the Store up and running to handle payments for the
>>> XPack, but there's no reason I can't use PayPal now and release the modules
>>> I have...
>>>
>>> I'll try and get to it next week. I should add there may be a period of
>>> debugging and ironing stuff out as we try and get everything perfect. But
>>> that's easier if we have a few others looking at the code. And we're pretty
>>> close as I'm intentionally using core XPack features everywhere possible on
>>> the BoltWire site.
>>>
>>> Thanks for sharing our software with your company! Give me a week...
>>>
>>> Cheers,
>>> Dan
>>>
>>>
>>>
>>> On Tue, Jan 19, 2016 at 1:23 AM TMurNGon  wrote:
>>>
 Thanks for that Dan.

 Just asking:  Any chance of you releasing just a partial expansion pack
 (just the bits that are complete to date)?
 I'm trying to convince the 'powers that be' to change to Boltwire for
 our company intranet and some (most) of those components would be very
 welcome.

 Just saying ;-)

 Thanks.
 Jan


 On Tuesday, 19 January 2016 04:23:41 UTC+2, Dan wrote:
>
> Despite my initial desire to have the expansion pack out by the first
> of the year--I made the strategic decision to focus on a couple other
> projects first. And I don't see any good openings in my calendar for the
> next few months at least.
>
> There is not a lot left to do--just really having fun with my other
> projects, and wanting to program a bit less and enjoy life a bit more! :)
>
> I did just release another version of BoltWire with lot's of nice
> fixes and improvements, but nothing dramatically different. I posted the
> changelog below. If you are current, should be a good upgrade.
>
> Cheers,
> Dan
>
>
>
> *The Cutting Edge...**boltwire5.08.zip
>  January 18, 2016*
>
>- Added a myBOLTskinVar['field'] = 'value' variable so can put
>{field} in skin and insert value. Similar to code.settings page, but 
> can
>control dynamically via php.
>- Slight fix in sorting of search results when extra pages are
>included. Also can handle {+1} and {+2} in sort parameter.
>- Slight fix to list function so handles no matches the same as
>search function.
>- The last release introduced a new bug in the way search results
>were processed where counting took place after sorting. Fixing required
>splitting BOLTresortsWhenCount into two separate functions.
>- Tweaked the set condition a bit more, so can do source=field and
>will return true if that post, get or cookie field set. Good for 
> testing if
>a multiline value is set that would otherwise break the markup.
>- Improved BOLTfolders function so can put a site.folders page in
>the shared/pages folder.
>- A couple slight improvements to the messaging controls in the
>index function.
>- Slight improvements to how the type parameter in searches works.
>Now can do number/-number, and mycustom/-mycustom types, and even 
> override
>the default number handling by creating a custom myBOLTtypenumber 
> function.
>- Minor tweaks in indexing. Now can do [(index rule=myrule
>batch=10)] and the batch setting will override the default value. Can 
> also
>do [(index 10)] and it will be the equivalent of [(index cron=10)]. And
>lastly, [(index)] will now default to the equivalent of setting the 
> cron
>parameter to whatever your default indexBatch value is.
>- Have been having problems with the auto-login process, and think
>I have fixed it at last. Like before, just use a persist=1209600 
> parameter
>in the login command to keep logged in for two weeks. To get the 
> autologin
>effect, the user m

Re: introduce BOLTsearchReultsType

2016-01-26 Thread The Editor

I'm going to consider this a bug and change the default number type to
check for numbers and not just that the page is numeric. This could break
some sites if you are relying on this feature though I don't believe the
documents claim this. If anyone has a concern I can deprecate for a release
or two, and then make the switch.

Cheers,
Dan

On Tue, Jan 26, 2016 at 11:30 AM Tiffany Grenier 
wrote:

> About this, in order to have the same results as expected in the original
> attempt of TMurNGon, I would advise doing
> [(search group={p}.* fmt=toc when='! inlist header,footer,
> side,license,support,links,comments,invites,attachments {+page}'
> type=-number)]
> instead of
>
> [(search group={p}.* 
> type=-header,footer,side,license,support,links,comments,invites,attachments
> fmt=toc when='! number {+page}')]
> since some.page.1-123 will be accepted by when="! number {+page}" but
> rejected by type=-number
> Cheers,
> Tiffany
>
>
> Le mardi 26 janvier 2016 06:56:13 UTC+1, TMurNGon a écrit :
>>
>> Great, thanks Dan.  I will give it a go.
>>
>> On Monday, 25 January 2016 16:48:08 UTC+2, Dan wrote:
>>>
>>> The number type is a special case rule and it doesn't work with a list
>>> like you have given. Either you check for a number/-number or you check for
>>> a list of types/-list of types.
>>>
>>> To do what you want, you have two options--
>>>
>>> 1) Create a custom type rule which does what you want. More trouble but
>>> probably faster if you have a bunch of pages to process.
>>>
>>> 2) Use the when parameter to exclude numbers.
>>>
>>> [(search group={p}.* 
>>> type=-header,footer,side,license,support,links,comments,invites,attachments
>>> fmt=toc when='! number {+page}')]
>>>
>>> For that matter, just for fun, you should be able to do:
>>>
>>> [(search group={p}.* fmt=toc when='! number {+page} && ! inlist
>>> header,footer,side,license,support,links,comments,invites,attachments
>>> {+page}')]
>>>
>>> Cheers,
>>> Dan
>>>
>>> On Mon, Jan 25, 2016 at 3:53 AM TMurNGon  wrote:
>>>
 Hi Dan,

 Given all of the above, how would I structure a 'page search' to
 exclude both a few named pages and number pages?
 I tried:

 [(search group={p}.*
 type=-number,header,footer,side,license,support,links,comments,invites,attachments
 fmt=toc)]

 but this does not seem to interpret 'number' as a being a numeric page
 name.  It does exclude the named pages (footer, side, etc), but does not
 exclude numeric pages; as [(search group={p}.* type=-number fmt=toc)] 
 would.

 Also, what would be the appropriate syntax for specifically including
 some pages and excluding others?  Once the '-' is specified it seems to
 exclude all mentioned pages.

 Thanks.
 Jan



 On Sunday, 8 November 2015 13:35:32 UTC+2, Tiffany Grenier wrote:
>
> Hi again,
> It takes much longer to retrieve the results of [(search
> group=some.page when="number {+p}")] than [(search group=some.page
> type=number)]. Also, the results are slightly different because a page
> named "some.page.1-0" would pass the second example and be removed from 
> the
> first one. I need to discriminate between pages like "some.page.1" and
> "some.page.1-0", and I wrote a BOLTCthread function that would validate
> both, while BOLTCnumber only validates the one without the dash, and I
> wanted these conditionals inside the search function.
> So I first thought about added "type=thread" (and modifying
> "type=number").
> And then I considered putting in the type argument other conditions in
> order to go much faster. Like for example type=subthread as replacement 
> for
> when="thread {+parent} && thread {+p}", which led me to separated the 
> parat
> of searchResults that does this check and use instead a hookable function.
>
> Thus I propose the following change:
> --- library.php Sun Nov 08 12:29:55 2015
> +++ library.php Sun Nov 08 12:30:48 2015
> @@ -1775,20 +1775,6 @@
>   }
>   if (count($outarray) == 0) return;
>   if ($args['type'] == '') $args['type'] = BOLTconfig('searchType');
> - $outarray = BOLTsearchResultsType($outarray,$args);
> - if (count($outarray) == 0) return;
> - if ($args['sort'] == '') natcasesort($outarray);
> - elseif ($args['sort'] != 'false') $outarray =
> BOLTsearchResultsSort($outarray, $args);
> - if ($args['order'] != '') {
> - if ($args['order'] == 'reverse' xor $args['sort'] ==
> 'lastmodified') $outarray = array_reverse($outarray);
> - if ($args['order'] == 'random') shuffle($outarray);
> - }
> - if ($args['when'] != '' || $args['count'] != '') $outarray =
> BOLTsearchResultsWhenCount($outarray, $args);
> - return $outarray;
> - }
> -
> -function BOLTsearchResultsType($outarray,$args) {
> - if (function_exists('myBOLTsearchResultsType')) return
> myBOLTsearchResultsType($out

Re: Community Module

2016-01-26 Thread The Editor

Hi Edward,

So sorry for the inconvenience. Trying to get all the settings just right
can be a bit tricky. In this case I had the email authorization off for the
page. Just tried it and the email came right to me.

Give it a shot and let me know if you have any further problems. Appreciate
your persistence!!!

Cheers,
Dan

On Sun, Jan 24, 2016 at 5:24 PM  wrote:

> Hello Dan,
> today I tried once again to create an account.
> I have come nearer to succeeding, I reached the page "
> www.boltwire.com/enroll/verify".
> Now I have been waiting for an hour without receiving an email containing
> the activation code.
>
> Can you help me to progress further?
> Edward
>
> PS.
> Searching for my account using Login Help returns the following which
> seems to confirm that the account has not been created.
> =
> Community Lost Account
>
> Can't remember your id, or password? Enter your email below and we will
> try to help.
> No search results found.
> *Email:  mail ( at ) doggie-best.de  *
>
> *No account found with this email address. If your email has changed,
> please contact us  for additional
> assistance.*
> *==*
>
>
> Am Dienstag, 19. Januar 2016 00:40:33 UTC+1 schrieb Dan:
>
>> Sorry about that. Looks like we had a permissions problem. Something
>> broken in one of our recent upgrades.
>>
>> Give it another try and if you still have problems let me know.  Sorry
>> for the inconvenience!
>>
>> Cheers,
>> Dan
>>
>> On Mon, Jan 18, 2016 at 5:11 PM  wrote:
>>
> Hello Dan,
>>> I have tried several times to to create an account. Every time I get the
>>> same rejection message "You are not authorized to save data to page
>>> temp.account.793e53751"
>>>
>>> Can you tell me how I can join the Boltwire Community?
>>> Edward
>>>
>>>
>>>
>>> Am Freitag, 29. Mai 2015 20:42:19 UTC+2 schrieb Dan:
>>>
 I hope to finish up the Community Module early next week, which means
 more than half the modules are pretty much ready for release.

 If anyone would like to help by testing out the various features in the
 BoltWire Community area, that would be appreciated:

 Account Creation
 Lost Account Retrieval
 Profile Update

>>> Image UploaderHello Dan,

>>> Password Update
 Email Update

 Feel free also to check out the Site Messaging, Blog, Forum, (and
 comments), Social Media, and Chatroom features. These modules are all
 pretty much ready to go, other than polishing up their admin pages.

 Store and Newsletter will be easy enough to do. The main part of the
 File Tools module is finished as well, though I'd like to eventually add a
 few more features. The inbox and notify modules are the only two likely to
 take much time as I will have to dust off some really old plugins. But we
 can roll them out later. And then that's it on my module plans...

 Cheers,
 Dan

 PS. Any feedback on the Dashboard?

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "BoltWire" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to boltwire+u...@googlegroups.com.
>>> To post to this group, send email to bolt...@googlegroups.com.
>>
>>
>>> Visit this group at https://groups.google.com/group/boltwire.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "BoltWire" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to boltwire+unsubscr...@googlegroups.com.
> To post to this group, send email to boltwire@googlegroups.com.
> Visit this group at https://groups.google.com/group/boltwire.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to boltwire+unsubscr...@googlegroups.com.
To post to this group, send email to boltwire@googlegroups.com.
Visit this group at https://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.

Re: introduce BOLTsearchReultsType

2016-01-26 Thread TMurNGon

Thanks lots for the advice Tiffany!


On Tuesday, 26 January 2016 19:30:13 UTC+2, Tiffany Grenier wrote:
>
> About this, in order to have the same results as expected in the original 
> attempt of TMurNGon, I would advise doing
> [(search group={p}.* fmt=toc when='! inlist header,footer,
> side,license,support,links,comments,invites,attachments {+page}' 
> type=-number)]
> instead of
> [(search group={p}.* 
> type=-header,footer,side,license,support,links,comments,invites,attachments 
> fmt=toc when='! number {+page}')]
> since some.page.1-123 will be accepted by when="! number {+page}" but 
> rejected by type=-number
> Cheers,
> Tiffany
>
> Le mardi 26 janvier 2016 06:56:13 UTC+1, TMurNGon a écrit :
>>
>> Great, thanks Dan.  I will give it a go.
>>
>> On Monday, 25 January 2016 16:48:08 UTC+2, Dan wrote:
>>>
>>> The number type is a special case rule and it doesn't work with a list 
>>> like you have given. Either you check for a number/-number or you check for 
>>> a list of types/-list of types.
>>>
>>> To do what you want, you have two options--
>>>
>>> 1) Create a custom type rule which does what you want. More trouble but 
>>> probably faster if you have a bunch of pages to process.
>>>
>>> 2) Use the when parameter to exclude numbers. 
>>>
>>> [(search group={p}.* 
>>> type=-header,footer,side,license,support,links,comments,invites,attachments 
>>> fmt=toc when='! number {+page}')]
>>>
>>> For that matter, just for fun, you should be able to do:
>>>
>>> [(search group={p}.* fmt=toc when='! number {+page} && ! inlist 
>>> header,footer,side,license,support,links,comments,invites,attachments 
>>> {+page}')]
>>>
>>> Cheers,
>>> Dan
>>>
>>> On Mon, Jan 25, 2016 at 3:53 AM TMurNGon  wrote:
>>>
 Hi Dan,

 Given all of the above, how would I structure a 'page search' to 
 exclude both a few named pages and number pages?
 I tried:

 [(search group={p}.* 
 type=-number,header,footer,side,license,support,links,comments,invites,attachments
  
 fmt=toc)]

 but this does not seem to interpret 'number' as a being a numeric page 
 name.  It does exclude the named pages (footer, side, etc), but does not 
 exclude numeric pages; as [(search group={p}.* type=-number fmt=toc)] 
 would.

 Also, what would be the appropriate syntax for specifically including 
 some pages and excluding others?  Once the '-' is specified it seems to 
 exclude all mentioned pages.

 Thanks.
 Jan



 On Sunday, 8 November 2015 13:35:32 UTC+2, Tiffany Grenier wrote:
>
> Hi again,
> It takes much longer to retrieve the results of [(search 
> group=some.page when="number {+p}")] than [(search group=some.page 
> type=number)]. Also, the results are slightly different because a page 
> named "some.page.1-0" would pass the second example and be removed from 
> the 
> first one. I need to discriminate between pages like "some.page.1" and 
> "some.page.1-0", and I wrote a BOLTCthread function that would validate 
> both, while BOLTCnumber only validates the one without the dash, and I 
> wanted these conditionals inside the search function.
> So I first thought about added "type=thread" (and modifying 
> "type=number").
> And then I considered putting in the type argument other conditions in 
> order to go much faster. Like for example type=subthread as replacement 
> for 
> when="thread {+parent} && thread {+p}", which led me to separated the 
> parat 
> of searchResults that does this check and use instead a hookable function.
>
> Thus I propose the following change:
> --- library.php Sun Nov 08 12:29:55 2015
> +++ library.php Sun Nov 08 12:30:48 2015
> @@ -1775,20 +1775,6 @@
>   }
>   if (count($outarray) == 0) return;
>   if ($args['type'] == '') $args['type'] = BOLTconfig('searchType');
> - $outarray = BOLTsearchResultsType($outarray,$args);
> - if (count($outarray) == 0) return;
> - if ($args['sort'] == '') natcasesort($outarray);
> - elseif ($args['sort'] != 'false') $outarray = 
> BOLTsearchResultsSort($outarray, $args);
> - if ($args['order'] != '') {
> - if ($args['order'] == 'reverse' xor $args['sort'] == 
> 'lastmodified') $outarray = array_reverse($outarray);
> - if ($args['order'] == 'random') shuffle($outarray);
> - }
> - if ($args['when'] != '' || $args['count'] != '') $outarray = 
> BOLTsearchResultsWhenCount($outarray, $args);
> - return $outarray;
> - }
> - 
> -function BOLTsearchResultsType($outarray,$args) {
> - if (function_exists('myBOLTsearchResultsType')) return 
> myBOLTsearchResultsType($outarray, $args);
>   if ($args['type'] == 'number') {
>   foreach ($outarray as $p => $page) {
>   $page = substr($page, strrpos($page, '.') + 1);
> @@ -1813,6 +1799,14 @@
>   elseif (strpos($type, $page) !== false) unset($outarray[$p]);
>

Re: Using counter

2016-01-26 Thread TMurNGon

Hi Dan,

The reason I did not use 'Total Pages: <(search group=docs* fmt=count 
count=false)>' is that I was trying to run the search only once, get the 
value and store it in a variable to use in a number of places on the page 
(without running the search multiple times).

I will definitely give the template idea a go (haven't played with 
templates yet).

Thanks.
Jan


On Wednesday, 27 January 2016 02:33:58 UTC+2, Dan wrote:
>
> Could you just do 
>
> Total Pages: <(search group=docs* fmt=count count=false)>
>
> As for your question, though, if you change fmt to template it should 
> work. With fmt, the output is returned unprocessed--so the counter function 
> is not triggered within the search function. And since the output is 
> suppressed, it doesn't get triggered later as in the second case.
>
> But when you use template, each match runs through the entire markup table 
> so it gets processed before returned. With the output suppressed, you never 
> see that output, but it is all processed. So then the final counter 
> function should work.
>
> Cheers,
> Dan
>
>
> On Tue, Jan 26, 2016 at 8:13 AM TMurNGon > 
> wrote:
>
>> Hi Dan,
>>
>> I've been trying to apply your example shown on the functions/counter 
>> page of the documentation, but I keep getting stuck...
>>
>> If I use the following it does suppress the output, but it also does not 
>> increment the counter (so the Total result remains 0 which is incorrect):
>>
>> {(search group=docs* fmt="[(counter id=total)]" count=false output=false)}
>> Total Pages: <(counter 0 id=total)>
>>
>>
>> If I use the following it does not suppress the output, but it does 
>> increment the counter correctly:
>>
>> {(search group=docs* fmt="[(counter id=total)]" count=false output=true)}
>> Total Pages: <(counter 0 id=total)>
>>
>> Any suggestions on how I can set the correct value of Total without 
>> getting any output from the search?
>>
>> Thanks lots.
>> Jan
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "BoltWire" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to boltwire+u...@googlegroups.com .
>> To post to this group, send email to bolt...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/boltwire.
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to boltwire+unsubscr...@googlegroups.com.
To post to this group, send email to boltwire@googlegroups.com.
Visit this group at https://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/d/optout.

Using counter

Re: introduce BOLTsearchReultsType

Re: BoltWire 5.08

Re: Using counter

Re: BoltWire 5.08

Re: introduce BOLTsearchReultsType

Re: Community Module

Re: introduce BOLTsearchReultsType

Re: Using counter

9 matches

Site Navigation

Mail list logo

Footer information