I'm trying to get PHPUnit and CodeCoverage over a few hundred PHP code repositories. A consistent problem I receive is that CodeCoverage doesn't work over any of my Admin pages that have session_start or any of my bounce-redirect pages that use header('Location...'); Code that otherwise works fine throws up "Warning: Cannot modify header information - headers already sent by (output started at ...)"
I've tried any number of Google searches to find a way around this and my Google-fu is currently weak. Thanks in advance.
EDIT 20120515:
I've ensured my code has all exit() calls replaced with returns. I do have XDebug installed and it is functioning on very simple, non-authenticated applications.
EDIT 20120531:
Reading further into the code, I found a file_get_contents in the SeleniumTestCase.php was failing under my xampp due to the file_get_contents('https://...'). Solved it by creating a http:// virtual host on a different port and pointing my coverageScriptUrl at that instead. All the warnings above were apparently red herrings.
Related
I am a bit puzzled on using PHP's session. Are there any specific requirements or conditions to use sessions? From all other forums, I can only see that session_start() should be the first line of the php code and nothing else beyond that.
In my test server (with PHP 7.3) it took me a while to get it to work, the only thing I found out is that when I load my site using http, the session doesn't save across load. And when I load it using https, it works fine.
While at this topic, I am also confuse why this tutorial site: https://www.w3schools.com/php/php_sessions.asp doesn't work despite it loaded using https.
I have set-up my WAMP installation to debug a PHP website in NetBeans.
This works fine (up to a point, hence this question) and I can single-step through the PHP code, and watch variables, etc.
However, some bits of the code - those provided within the Yii framework - are throwing exceptions, but attempts to single-step through this code fail - the debugger leaps over portions of the code and I can't observe what's going on.
The debugger lands on a call to HandleError, but I can't see how it got there. The displayed Call Stack isn't showing all the steps taken to get where it is.
I've seen lots of comments on the web about this, but haven't yet seen an answer on how to enable this framework's code to be debugged on my PC.
Any suggestions would be welcome.
I am in the process of migrating an existing Drupal website from another provider to Bluehost.com -- while I think using Bluehost.com is not relevant in this context I thought I'd mention it anyway, in case there are indeed some particularities I'm not aware of.
The site is a Drupal 6 installation and it did work previously I am told on bluehost too so you think it shouldn't be any problems, however, having copied it over I encounter a big problem: all the responses from Drupal are sent with Content-Encoding set to application/x-gzip. This has the implication of all browser presenting a download dialog box rather than rendering the content.
I have actually curl'd the index page and ran it through gunzip and the output is the correct HTML for the site -- just that it somehow ends up being gzip'd and this mangles the content type and confuses the browsers.
Talking to previous maintainers of the site they suggested using PHP 5.4 (they were running it on php 5.5 as I understand and despite all the Drupal suggestions it was running perfectly well I'm told).
I am trying to eliminate now any type of gzip'ing that occurs here so I've got it down to a few layers which could cause it but eliminating those it still doesn't work:
SetEnv no-gzip 1 in .htaccess
zlib.output_compression = Off in php.ini
drupal had the boost module installed and some corresponding settings in .htaccess -- i've removed those from the .htaccess file as well as deleting the boost directory from sites/all/modules
The problem still stands and my files are being sent to the browser compressed. Is there any other way to disable this?
Note that this only happens for pages inside Drupal, having uploaded a simple php page and navigate to that url works fine -- which suggests therefore a drupal (rather than apache/php) problem.
I've noticed a module mimedetect which has a definition for application/x-gzip in there but not sure how could this affect it as removing this didn't render anything useful either.
Any ideas where to look and/or what might cause it?
Happy to provide any other insights that might be useful in diagnosing this.
Ok so having actually reset the database cache and with the settings above this now works. I'm trying to figure out which one of the above actually solved it.
I have just moved my multisite from one server to another, changing the site domain along the way. I followed the steps for moving a multisite described in the WP Codex and after some fiddling about everything seems to work as expected now... apart from one thing:
Whenever I try to create a new page/post or edit or update an existing page/post I get the following debug message and I am not redirected to the page/post edit page:
Notice: Undefined offset: 0 in /x/y/z/wp-includes/capabilities.php on line 1067
Warning: Cannot modify header information - headers already sent by (output started at /x/y/z/wp-includes/capabilities.php:1067) in /x/y/z/wp-includes/pluggable.php on line 876
I have already searched the Wordpress forums, Google and of course Stackoverflow but none of the offered solutions seemed to work.
Interestingly, the URL I am redirected to when hitting the Publish/Update button seems to lack all arguments:
http://mysite.com/wp-admin/post.php
Another interesting thing is that the updates I do are saved and stored in the database. So when I visit the actual site any updates are reflected, but somehow the update process on the admin site is broken. I'm kinda stuck here, so any help would be greatly appreciated.
Wordpress is not the software that would really care about such programing errors as undefined indexes. You have to run it with at least notices off, and I recomend turning off outputting of errors completely. To do it, consult your server administrator. There might be already some setting in control panel for it.
I am new to joomla and I need to work on a joomla website for a school project. I modified an existing module to make it display featured projects and it does that flawlessly when I test the site locally. However, when I uploaded my files to the hosted copy of the website, the module will load but does not display anything. It just loads the title and the area for the php output but there is nothing returned by the script. Why would this be happening? I have joomla mostly figured out but I'm stumped when it comes to this problem.
As far as I can tell, all files related to this module have been copied over successfully and it is setup properly in the module manager. I turned on debugging mode on the hosted copy and got this message when trying to load another page with this module on it:
Parse error: syntax error, unexpected
T_STRING in
/home/content/s/r/s/srsgdmnet/html/components/com_rbids/rbids.html.php
on line 1
I looked at the file and I don't have a clue what it's talking about. Line one is just "<?php" which is fine. Is it just saying line 1 but actually referring to a problem elsewhere? This file is part of a reverse auctions component that my module interacts with. I didn't modify the code in that file with the exception of using a regular expression (search using "\n\s*(\n)", replace with "\n") to remove excessive amounts of whitespace via the replace command in Netbeans. This cut roughly 3200 lines from the file, making it much easier to navigate. I assume this did not alter anything in terms of code because it still works fine when used locally.
I modified my local configuration.php file to use the same database as the hosted copy to see if it was a database issue but it still worked fine so that rules that out. The php.ini files are the same on both copies with the exception of the local one having the Zend stuff commented out so I could use Xdebug (made this change after the problem occurred in an attempt to locate it). I have stepped through the code with Xdebug and haven't been able to track the issue down so I'm thinking it's a configuration problem.
My local copy also does not load certain modules (main menu, for one) and I can't navigate to some of the other pages, not sure if that is related. The code is the same for both copies yet each one has different results. Am I skipping vital steps for migrating the code?
I am using Joomla version 1.5.9. Please help!
Your question is ten days old, so perhaps you solved it already. But my suggestion would be to check the code for forward and back slashes. It might be that the code uses \ which works locally but fails on your server where it needs /. In Joomla extensions you can replace folder separations by DS, in the way of 'folder'.DS.'subfolder' instead of 'folder/subfolder'. The API will replace the DS by \ or / as appropriate.
However, the parse error you get indicates that something is missing in the syntax of your code. You will just have to go over it with a magnifyer glass. Sometimes when the error refers to the first line the impact of something missing works its way back to the beginning of the file. It could be a ' or ; or something small like that.
Regardless of your module, you should update to Joomla version 1.5.15 which at present is the latest version. you are 6 security releases behind schedule!
The group I have been working with has come to the conclusion that somehow Netbeans is messing up some of the files when we edit and save them. We tested by taking files from our server, opening and then saving in Netbeans, and then uploading back to the server. Sometimes this produced files that apparently did not have any newlines in them and led to php errors, breaking components or even taking down the whole site.
Our current workaround for this is to just take the files this happens to and use notepad++ to make our changes before uploading. It's a very strange issue and caused us a lot of grief. Hopefully the Netbeans team fixes this in future releases.
Thank you all for your attempts to help me solve this problem.
Try closing your <?php the traditional way and see if it works or the error line changes.
I remember seeing a similar question either on Joomla or Fabrik forums but cannot remember precise answer