I was trying to use this function like this:
$test = 'tekst';
Zend_Debug::dump($test);
It does not print anything ...
Maybe this part of code is not actually running? (is this part of larger website?)
Maybe you didn't have Zend loaded, and your PHP shows error (like 'Can't find class Zend_Debug') but you have error_reporting disabled?
Related
I am trying to run the Selenium driver with Perl bindings, and due to the lack of examples and documentation, I am running into some roadblocks. I have figured out how to do some basic things, but I seem to be running into some issues with other simple things like validating the text on a page using Remote::Driver package.
If I try to do something like this:
$sel->get("https://www.yahoo.com/" );
$ret = $sel->find_element("//div[contains( text(),'Thursday, April 26, 2012')]");
I get a message back that the element couldn't be found. I am using xpath because the driver package doesn't appear to have a sub specific for finding text.. at least not that I've found.
If my xpath setup is wrong or if someone knows a better way, that would be extremely helpful. I'm having problems with some button clicking too.. but this seems like it should be easier and is bugging me.
Finding text on a web page and comparing that text to some "known good value" using Selenium::Remote::Driver can be implemented as follows:
File: SomeWebApp.pm
package SomeWebApp;
sub get_text_present {
my $self = shift;
my $target = shift;
my $locator = shift;
my $text = $self->{driver}->find_element($target, $locator)->get_text();
return $text;
}
Somewhere in your test script: test.pl
my $text = $some_web_app->get_text_present("MainContent_RequiredFieldValidator6", "id");
The above finds the element identified by $target using the locating scheme identified by $locator and stores it in the variable $text. You can then use that to compare / validate as required / needed.
https is a tad slower loading than http. Although WebDriver is pretty good about waiting until it's figured out that the requested page is fully loaded, maybe you need to give it a little help here. Add a sleep(2); after the get() call and see if it works. If it does, try cutting down to 1 second. You can also do a get_title call to see if you've loaded the page you think you have.
The other possibility is that your text target isn't quite exactly the same as what's on the page. You could try looking first for one word, such as "April", and see if you get a hit, and then expand until you find the mismatch (e.g., does this string actually have a newline or break within it? How about an HTML entity such as a non-breaking space?). Also, you are looking for that bit of text anywhere under a div (all child text supposedly is concatenated, and then the search done). That would more likely cast too wide a net than not get anything at all, but it's worth knowing.
I'm using MongoMapper with Joint on Padrino, and trying to get the
upload working. However, I keep getting thrown a NoMethodError
"undefined method 'path' for #<Hash:0xa6fbdf0>". It seems like it
can't see the path, but the parameters are okay. What is the problem
here?
Gist with the code: https://gist.github.com/1323998
I was able to get it to not error, but when I go to find the file with mongofiles, I can't find. The same goes for rack/grid-fs. Where is Joint saving to, and is it saving at all?
See my comments above:
Here's my thought on what you need to do, I think you need to modify the params so that params[:background][:file] is the tempfile object, like so:
params[:background][:file] = params[:background][:file][:tempfile]
background = Background.create(params[:background])
I'm not 100% sure on this, but if this doen't work I could setup a quick Padrino app and test.
I'm having a strange problem here. I'm moving a (working) site to a new apache server to which I don't have direct access (I have to go through two people to get stuff done).
The site uses a perl script called adframe to parse html templates. The URLs with which it's called look like /cgi-bin/adframe/index.html?x=something with adframe being the script. The missing suffix never caused any real problems. But on this new Ubuntu server $ENV{'QUERY_STRING'} is always empty. $ENV{'REQUEST_METHOD'} shows up correctly as GET, but the query_string shows nothing ...
Regular *.cgi scripts show the query_string without problems.
From the logs I gathered that the server seems to be running fastcgi, mod_fcgid and the server doesn't even accept .pl as an extension for scripts. I don't have that much experience with server software, but I figured it might be a problem with the server not accepting adframe as a cgi script and thus not passing the query_string correctly ... Can anyone give me a few hints to where I could point the administrator or maybe something I could do in .htaccess myself? Anyway to make sure, adframe is recognized as a cgi script!? (if that's the problem ...)
Any help is appreciated!
thomas
EDIT: I found more details: The server seems to be running a VARNISH cache ... thats's the main difference to my usual configurations ...
Also, the way the script works is, if you call /cgi-bin/adframe/somedir/somefile.html?x=something, $ENV{PATH_INFO} tells which template to parse and $ENV{QUERY_STRING} is, well, the query string. Now the query string is empty, but if I call /cgi-bin/adframe?x=something (without any PATH_INFO), the query string shows up!
Does anyone have an idea what's going on here?
thanks!
Got it. The VARNISH cache strips all the query strings off static content (*.html etc) ... phew
Just ran into the same problem. I am complete newbie in perl scripting.
I tried following:
#values = split (/&/, $ENV{'QUERY_STRING'});
but it didn`t work
this worked:
#values = split (/&/, "$ENV{'QUERY_STRING'}");
just in case if other newbies have ran into the same problem.
I'm playing around with Win32::IE:Mechanize to try to access some authentication-required sites automatically. So far I've achieved moderate success, for example, I can automatically log in to my yahoo mailbox. But I find many sites are using some kind of image verification mechanism, which is possibly called CAPTCHA. I can do nothing to them. But one of the sites I'm trying to auto access is using a plain-text verification code. It is comnposed of four digits, selectable and copyable. But they're not in the source file which can be fetched using
$mech->content;
I searched for the keyword that appears on the webpage but not in the source file through all the files in the Temporary Internet Files but still can't find it.
Any idea what's going on? I was suspecting that the verification code was somehow hidden in some cookie file but I can't seem to find it :(
The following is the code that completes all the fields requirements except for the verification code:
use warnings;
use Win32::IE::Mechanize;
my $url = "http://www.zjsmap.com/smap/smap_login.jsp";
my $eccode = "myeccode";
my $username = "myaccountname";
my $password = "mypassword";
my $verify = "I can't figure out how to let the script get the code yet"
my $mech = Win32::IE::Mechanize->new(visible=>1);
$mech->get($url);
sleep(1); #avoids undefined value error
$mech->form_name("BaseForm");
$mech->field(ECCODE => $eccode);
$mech->field(MEMBERACCOUNT => $username);
$mech->field(PASSWORD => $password);
$mech->field(verify => $verify);
$mech->click();
Like always any suggestions/comments would be greatly appreciated :)
UPDATE
I've figured out a not-so-smart way to solve this problem. Please comment on my own asnwer posted below. Thanks like always :)
This is the reason why they are there. To stop program like yours to do automated stuff ;-)
A CAPTCHA or Captcha is a type of
challenge-response test used in
computing to ensure that the response
is not generated by a computer.
This appears to be an irrelevant number. The page uses it in 3 places: generating it; displaying it on the form next to the input field for it; and checking for the input value being equal to the random number chosen. That is, it is a client-only check. Still, if you disable javascript it looks like, I'm guessing, important cookies don't get set. If you can execute JavaScript in the context of the page (you should be able to with a get method call and a javascript URI), you could change the value of random_number to f.e. 42 and fill that in on the form.
The code is inserted by JavaScript – disable JS, reload the page and see it disappear. You have to hunt through the JS code to get an idea where it comes from and how to replicate it.
Thanks to james2vegas, zoul and Shoban.
I've finally figured out on my own a not-so-smart but at-least-workable way to solve the problem I described here. I'd like to share it here. I think the approach suggested by #james2vegas is probably much better...but anyway I'm learning along the way.
My approach is this:
Although the verification code is not in the source file but since it is still selectable and copyable, I can let my script copy everything in the login page and then extract the verification code.
To do this, I use the sendkeys functions in the Win32::Guitest module to do "Select All" and "Copy" to the login page.
Then I use Win32:Clipboard to get the clipboard content and then Regexp to extract the code. Something like this:
$verify = Win32::Clipboard::GetText();
$verify =~ s/.* (\d{4}).*/$1/msg;
A few thoughts:
The random number is generated by something like this in Perl
my $random_number = int(rand(8999)) + 1000; #var random_number = rand(1000,10000);
And then it checks if $verify == $random_number. I don't know how to catch the value of one-session-only $random_number. I think it is stored somewhere in the memory. If I can capture the value directly then I wouldn't have gone to so much trouble of using this and that extra module.
I am trying to use either APC or XCache as an opcode to cache my php pages. I am using it with Zend and Doctrine and it's having a problem with the autoloader.
If I try with APC, I get the following:
Fatal error: spl_autoload() [<a href='function.spl-autoload'>function.spl-autoload</a>]:
Class Doctrine_Event could not be loaded in
C:\\[mydir]\\library\\doctrine\\Doctrine\\Record.php on line 777
If I try with XCache I get the following:
PHP Fatal error: Cannot redeclare class Zend_Registry in
C:\\[mydir]\\library\\zendframework\\Zend\\Registry.php on line 0
I'm running Zend 1.9.1, Doctrine 1.1 on a windows box.
My bootstrap is as follows:
set_include_path(dirname(__FILE__).'/../library/zendframework'
. PATH_SEPARATOR . dirname(__FILE__).'/../library/doctrine'.....
require 'Zend/Loader/Autoloader.php';
$loader = Zend_Loader_Autoloader::getInstance();
$loader->suppressNotFoundWarnings(false);
$loader->setFallbackAutoloader(true);
From what I've read, using APC or xcache is almost a must for performance, but I can't seem to get it working. Any ideas?
You could put a "Zend_Session::writeClose(true);" at the end of your index.php.
This will write the session into a persistent state before necessary Objects (Zend_Loader etc.) get destructed.
Better: Register it as shutdown function.
So it will be executed even if you use exit(), die() or a fatal error occures:
register_shutdown_function(array('Zend_Session', 'writeClose'), true);
It is probably similar to the problem with custom session handling and APC-cache. If you have assigned a custom session handler it is registered with RSHUTDOWN in PHP. It is the same routine that APC uses and will therefor create an internal conflict in PHP and your custom session handler will not close in all situations.
So you will have to make sure you manually close the custom session handler at shutdown
Putting a "Zend_Session::writeClose(true);" at the end of your index.php is not the best way to do that in case you have any exit; calls in your scripts anywhere.
It is better to register a shutdown handler in this way:
function shutdown()
{
Zend_Session::writeClose(true);
}
register_shutdown_function('shutdown');
Put that in top of your index.php file to make sure that the shutdown procedure is registered before any other scripts are run.
Is there something else mucking the include path? Maybe try to log out the include path right before that line in your first APC example.
The XCache one is really weird. That project is pretty dead though, and I'd not trust it on PHP 5.2+. Try eaccelerator instead? We've had the best luck with it.
Benjamin Cremer, you're a life saver. While the above (original) problem is a special case of autoloading with sessions, closing the session seems to be a general solution for such cases. A note though:
Placing Zend_Session::writeClose(true); at the end of your scripts may not always cut it, since you may have exit;'s, die();'s, etc in your code. In this case, you can use
register_shutdown_function(array('Zend_Session', 'writeClose'), true);
or, simply
register_shutdown_function('session_write_close');
if you do not use Zend for sessions.