2. PHPRunner General questions
  3. [SOLVED]   Search doesn't work
This topic is locked
[SOLVED]

  Search doesn't work

 		2/7/2011 6:22:43 PM
PHPRunner General questions
E
 electromotive author

[note this was split out of another thread http://www.asprunner.com/forums/topic/16264-search-does-not-work-at-all/]
Upgraded my monster project finally, to 5.3 <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=question&id=16381&image=1&table=forumtopics' class='bbc_emoticon' alt=':)' />
But my "All Fields Search" no longer works after upgrading to 5.3, at least in the majority of [core] tables.

When you start typing, the ajax hints come up ok.

But when you start the search, the search never completes, just says "Loading..." or eventually times out.
Advanced search works fine.

Have checked my Search Settings on the Fields tab, looks proper.

Have "reset" the affected pages to defaults. Using Paris/Rome.

List page settings are set to Ajax search alone.

Has been working ok since 5.1 and 5.2.
Anybody else having search problems with 5.3 (7113) ?
Furthermore..

When running this under IE8, I get an "error on page" with the following text:
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; .NET4.0C; .NET4.0E)

Timestamp: Tue, 1 Feb 2011 00:39:54 UTC
Message: Exception thrown and not caught

Line: 28

Char: 1

Code: 0

URI: http://localhost/pro...include/json.js
Also in Firefox with Firebug enabled, a javascript error is associated with this (also Showall):
throw new SyntaxError('JSON.parse');};}}());

Which is in json.js, line 28
I know that's not very helpful <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=question&id=16381&image=2&table=forumtopics' class='bbc_emoticon' alt=':)' />
E
 		electromotive author 2/7/2011



electro rick,
post your application to Demo Account and open a ticket at http://support.xlinesoft.com sending your Demo Account URL. 'Demo Account' button can be found on the last screen in the program


Thanks for the offer. The project is big and proprietary and I'd need to clean it before uploading it anywheres. I'll take you up on this if I don't make any progress on isolating it and reproducing it on a small test system.
The first thing I'll do is go through table by table, see which ones work and which don't, and then try and understand the differences. Excuse the blog format as I work through things, hopefully the process is as interesting as the results.
[Update] Of the 75-odd tables, only about dozen have errors, unfortunately they are core tables.
From firebug, the js always stops with this snippet:

2this.JSON={};(function(){var charset=document.charset||document.characterSet||document.defaultCharset;function f(n){return n<10?'0'+n:n;}

3if(typeof Date.prototype.toJSON!=='function'){Date.prototype.toJSON=function(key){return isFinite(this.valueOf())?this.getUTCFullYear()+'-'+

4f(this.getUTCMonth()+1)+'-'+

5f(this.getUTCDate())+'T'+

6f(this.getUTCHours())+':'+

7f(this.getUTCMinutes())+':'+

8f(this.getUTCSeconds())+'Z':null;};String.prototype.toJSON=Number.prototype.toJSON=Boolean.prototype.toJSON=function(key){return this.valueOf();};}

9var cx=/[\u0000\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-\u206f\ufeff\ufff0-\uffff]/g,escapable=/[\\\"\x00-\x1f\x7f-\x9f\u00ad\u0600-\u0604\u070f\u17b4\u17b5\u200c-\u200f\u2028-\u202f\u2060-\u206f\ufeff\ufff0-\uffff]/g,gap,indent,meta={'\b':'\\b','\t':'\\t','\n':'\\n','\f':'\\f','\r':'\\r','"':'\\"','\\':'\\\\'},rep;function quote(string){escapable.lastIndex=0;return escapable.test(string)?'"'+string.replace(escapable,function(a){var c=meta[a];if(typeof c==='string'){return c;}else if(charset.toLowerCase()=='utf-8'){return'\\u'+('0000'+a.charCodeAt(0).toString(16)).slice(-4);}else{return a;}})+'"':'"'+string+'"';}

10function str(key,holder){var i,k,v,length,mind=gap,partial,value=holder[key];if(value&&typeof value==='object'&&typeof value.toJSON==='function'){value=value.toJSON(key);}

11if(typeof rep==='function'){value=rep.call(holder,key,value);}

12switch(typeof value){case'string':return quote(value);case'number':return isFinite(value)?String(value):'null';case'boolean':case'null':return String(value);case'object':if(!value){return'null';}

13gap+=indent;partial=[];if(Object.prototype.toString.apply(value)==='[object Array]'){length=value.length;for(i=0;i<length;i+=1){partial*=str(i,value)||'null';}

14v=partial.length===0?'[]':gap?'[\n'+gap+

15partial.join(',\n'+gap)+'\n'+

16mind+']':'['+partial.join(',')+']';gap=mind;return v;}

17if(rep&&typeof rep==='object'){length=rep.length;for(i=0;i<length;i+=1){k=rep[i];if(typeof k==='string'){v=str(k,value);if(v){partial.push(quote(k)+(gap?': ':':')+v);}}}}else{for(k in value){if(Object.hasOwnProperty.call(value,k)){v=str(k,value);if(v){partial.push(quote(k)+(gap?': ':':')+v);}}}}

18v=partial.length===0?'{}':gap?'{\n'+gap+partial.join(',\n'+gap)+'\n'+

19mind+'}':'{'+partial.join(',')+'}';gap=mind;return v;}}

20if(typeof JSON.stringify!=='function'){JSON.stringify=function(value,replacer,space){var i;gap='';indent='';if(typeof space==='number'){for(i=0;i<space;i+=1){indent+=' ';}}else if(typeof space==='string'){indent=space;}

21rep=replacer;if(replacer&&typeof replacer!=='function'&&(typeof replacer!=='object'||typeof replacer.length!=='number')){throw new Error('JSON.stringify');}

22return str('',{'':value});};}

23if(typeof JSON.parse!=='function'){JSON.parse=function(text,reviver){var j;function walk(holder,key){var k,v,value=holder[key];if(value&&typeof value==='object'){for(k in value){if(Object.hasOwnProperty.call(value,k)){v=walk(value,k);if(v!==undefined){value[k]=v;}else{delete value[k];}}}}

24return reviver.call(holder,key,value);}

25cx.lastIndex=0;if(cx.test(text)){text=text.replace(cx,function(a){return'\\u'+

26('0000'+a.charCodeAt(0).toString(16)).slice(-4);});}

27if(/^[\],:{}\s]*$/.test(text.replace(/\\(?:["\\\/bfnrt]|u[0-9a-fA-F]{4})/g,'@').replace(/"[^"\\\n\r]*"|true|false|null|-?\d+(?:\.\d*)?(?:[eE][+\-]?\d+)?/g,']').replace(/(?:^|:|,)(?:\s*\[)+/g,''))){j=eval('('+text+')');return typeof reviver==='function'?walk({'':j},''):j;}

28throw new SyntaxError('JSON.parse');};}}());


I can't help but wonder if this is just 5.3's blue screen, that the real problem is something else.
Fortunately of one of the tables that consistently doesn't work, I have a PHPR view of the table which does work. The view is a limited set, SQL filters, different fields displayed. I'll try and use this to isolate the factors which at least trigger the problem.
[update] A View "copy" of a not-working table (with no changes)does not work either. Strip it back far enough (ie., delete SQL, events, validations, etc) and it starts working ! Just have to find that particular point... Deleting all extra SQL? Nope. Deleting all validations? Nope. Resetting the HTML? Nope. But possibly it's resetting all the event code... Will go through again to be sure.
[update] When deleting and adding views with the same name, in order to test what's going on with events, you have to close the project and reopen again, as there is some temporary context which persists. Still looking at what's happened to the events.
[update] Have disabled some echo'ed development breadcrumbs that were in the BeforeProcessList event, on this particular table and its working again. I can't remember why these were still here, they go back a long ways. Anyways, will continuing looking at the other broken lists and see if its the same pattern.
[update] Next table - echo statements in the BeforeDisplay event, they work (echo some information on the screen), but when I comment them out then the search and showall starts working normally again <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=reply&id=56302&image=1&table=forumreplies' class='bbc_emoticon' alt=':)' /> There is a pattern. If its only removing the echo statements from events, I can fix this.
[update] went through entire project, commented out all echo statements from list events, and all the search and showalls in those tables appear to be working again. I'll be able to go to 5.3 again (after more careful testing this time ) However, seems a bit funny that PHP echo statements affect javascript search and showall, eh.
[update] While testing I found that in many cases the actual advanced search fields didn't match what had been setup (you can preview this in Editor - Search too). But when you just go into Fields -> Search settings, and then OK without changing anything, on next build it comes out ok. This may also affect whats happening in the All Fields search as well, because until you do this, while you are typing in the simple search box you can see search results coming up from fields its not supposed to be searching. So I suggest on 5.3 (7113) you go into the Search settings for all tables to work around this bug.
[update] If you are adding views or reports and modify the menu, then you need to "full build" to get them to show up in the dynamic permissions Admin Area.
[update] Still testing, and trying resolve a few other issues. Now I am getting a browser error on a new report's advanced search:
[i]Bad Request
Your browser sent a request that this server could not understand.

Size of a request header field exceeds server limit.*
It persists, and to clear it I have to reset my FF "recent history" in order for anything to work again. It's a bad Post, which means something's getting trashed. Am reluctant to push forward into 5.3 until I know what's causing this. I have tried several times with the same outcome.
Sergey Kornilov admin 2/8/2011

Googling on "Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit." gives the following suggestions:

  • clear your browser's cache
  • clear cookies
  • Increase allowed request size in web server configuration

    To increase request size in Apache, add directive LimitRequestFieldSize to the configuration file. Default value is 8190 bytes. To increase it 2 times add

    LimitRequestFieldSize 16380

    Apache restart is required.
E
 		electromotive author 2/8/2011



Googling on "Your browser sent a request that this server could not understand. Size of a request header field exceeds server limit." gives the following suggestions:

  • clear your browser's cache
  • clear cookies
  • Increase allowed request size in web server configuration

    To increase request size in Apache, add directive LimitRequestFieldSize to the configuration file. Default value is 8190 bytes. To increase it 2 times add

    LimitRequestFieldSize 16380

    Apache restart is required.


I'll try doubling it to see if this solves the problem. <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=reply&id=56324&image=1&table=forumreplies' class='bbc_emoticon' alt=':)' />
E
 		electromotive author 2/8/2011



I'll try doubling it to see if this solves the problem. <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=reply&id=56328&image=1&table=forumreplies' class='bbc_emoticon' alt=':)' />


Yay. Setting LimitRequestFieldSize 16380 works on my test system.

And you have to clear browser cache and cookies too.
Will continue testing and refining this report. It will be a while before I can restart the main server apache. [updated linux/apache, have candidate 5.3(7113) test system running there. All good so far]
G
 		GamezBeCJ 2/10/2011

I've been having the same issue since I upgraded to 5.3. It says the problem is in RunnerPages.js. I don't know much of JavaScript. Don't know what to do.
Sergey Kornilov admin 2/10/2011

GamezBeCJ,
as a first step you need to post your application to Demo Account and open a ticket at http://support.xlinesoft.com sending your Demo Account URL. 'Demo Account' button can be found on the last screen in the program.
E
 		electromotive author 2/10/2011



I've been having the same issue since I upgraded to 5.3. It says the problem is in RunnerPages.js. I don't know much of JavaScript. Don't know what to do.



Yep, take Xlinsoft's offer to look at your project. If you want to debug yourself, do the binary sort approach that I outlined above in order to isolate the problem. I'd be sceptical that there is a problem in RunnerPages.js, its probably only a symptom of something else. Roll up your sleeves, make a copy of everything (DB, Project). In the copy strip out all PHPR mods you've made (sql, validations, HTML, Javascript, etc), just go back to the original code and tables. Assuming you are on a fairly clean development environment like a recent XAMPP running on XP or W7. In your browser clear everything, history, cookies, etc, start from scratch. Test everything, see what works and what doesn't. If that doesn't even work, then go back further, just try one table. If that doesn't work, go to a known working environment, start from scratch, test the basic server, PHP, SQL, etc. Once you get something working, start going forward again until it breaks. Report back your results. Using the binary approach (ie, cutting the problem space in half or doubling it) its surprisingly quick to isolate issues. The real hard ones to solve is when 3 or more things are broken. Good luck.
E
 		electromotive author 2/15/2011

[[
NOTE: From here down, this has been split into a new topic. http://www.asprunner.com/forums/topic/16458-upgrade-to-5-3-javascript-methods-stopped-working/
]]
5.3 testing going reasonably well.
However, some javascript is not working quite the same as 5.2.
This is a list page with has both inline and normal edit enabled. Only two fields are enabled for editing in the inline mode.
What I was trying to do was use the setFocus method to put the cursor in the correct field (exactly as from the help) on the inline-edit (list). This works on 5.2 but not on 5.3.

var ctrl = Runner.getControl(pageid, 'myfield');

ctrl.setFocus(); //ok on 5.2 but not on 5.3
or
var tName = 'mytable';

var ctrl = Runner.controls.ControlManager.getAt(tName, pageid, 'myfield');

ctrl.setFocus(); // ok on 5.2 but not on 5.3


Anyone have advise for me?
V
 		Vienna 2/16/2011



5.3 testing going reasonably well.
However, some javascript is not working quite the same as 5.2.
This is a list page with has both inline and normal edit enabled. Only two fields are enabled for editing in the inline mode.
What I was trying to do was use the setFocus method to put the cursor in the correct field (exactly as from the help) on the inline-edit (list). This works on 5.2 but not on 5.3.

var ctrl = Runner.getControl(pageid, 'myfield');

ctrl.setFocus(); //ok on 5.2 but not on 5.3
or
var tName = 'mytable';

var ctrl = Runner.controls.ControlManager.getAt(tName, pageid, 'myfield');

ctrl.setFocus(); // ok on 5.2 but not on 5.3


Anyone have advise for me?


I was on this topic over a month ago complaining about PHPRunner 5.3 that on a 1und1.de server account in Germany (I have 1and1.com accounts in the USA) that the javascript was failing on both PHP 4.9 and PHP 5.2 environments. Just different parts of the javascripting for each environment. Either the Search panel or the dropdown list dependencies using ajax updating.



Within the past week I discovered that my PHPRunner 5.3 projects DID work completely in a PHP 5.2 environment on a 1und1.de shared hosting account IF I removed a part of the .htaccess mod rewrite rules that I was using.
Where the PHPRunner 5.3 project was in a path from the directory where WordPress was installed and was INHERITING the .htaccess settings for Mod Rewrite for WordPress it was having Javascript issues -- specifically in the PHP 5.3 environment of 1und1.de.
The ajax updates for dropdown dependencies (one field's options being refreshed and changed after a preceding field option was selected) did NOT work although the Search panel with suggestive (ajax) updates did.
So, in your case you might also look at your .htaccess rules as a possible influence on PHPRunner 5.3.
Maybe with PHPRunner 5.2 this was not an issue but it sure made a difference in the working of my PHPRunner 5.3 projects.
I know in most localhost testing servers we don't use .htaccess to modify things at all, but if you are online and testing remote server problems with PHPRunner 5.3 projects and running PHP 5 you should also examine what your .htaccess is doing. Or if you depend on php.ini, check that one, too.
Eliminate the mod rewrite rules just as a test and see what happens. If it works then it is a question of how to modify the mod rewrite.
Or possibly put a Counter mod-rewrite .htaccess file into the same folder as the PHPRunner 5.3 project.
E
 		electromotive author 2/16/2011



I was on this topic over a month ago complaining about PHPRunner 5.3 that on a 1und1.de server account in Germany (I have 1and1.com accounts in the USA) that the javascript was failing on both PHP 4.9 and PHP 5.2 environments. Just different parts of the javascripting for each environment. Either the Search panel or the dropdown list dependencies using ajax updating.



Within the past week I discovered that my PHPRunner 5.3 projects DID work completely in a PHP 5.2 environment on a 1und1.de shared hosting account IF I removed a part of the .htaccess mod rewrite rules that I was using.
Where the PHPRunner 5.3 project was in a path from the directory where WordPress was installed and was INHERITING the .htaccess settings for Mod Rewrite for WordPress it was having Javascript issues -- specifically in the PHP 5.3 environment of 1und1.de.
The ajax updates for dropdown dependencies (one field's options being refreshed and changed after a preceding field option was selected) did NOT work although the Search panel with suggestive (ajax) updates did.
So, in your case you might also look at your .htaccess rules as a possible influence on PHPRunner 5.3.
Maybe with PHPRunner 5.2 this was not an issue but it sure made a difference in the working of my PHPRunner 5.3 projects.
I know in most localhost testing servers we don't use .htaccess to modify things at all, but if you are online and testing remote server problems with PHPRunner 5.3 projects and running PHP 5 you should also examine what your .htaccess is doing. Or if you depend on php.ini, check that one, too.
Eliminate the mod rewrite rules just as a test and see what happens. If it works then it is a question of how to modify the mod rewrite.
Or possibly put a Counter mod-rewrite .htaccess file into the same folder as the PHPRunner 5.3 project.



Thanks for your suggestion. Had a look through the .htaccess, php.ini, etc., don't see anything. Think I'll split this out into a new thread, as this one has been solved.