When saving a CMS block in Magento 1.4.1, I am getting an error, connection reinitalized by my web browser. I only get this this error, when adding the tags <script></script>. Any other changes I can save and I can add new blocks as long as I don't use <script></script>
The only error I'm seeing is in /var/www/website/var/log/exception is this and only if I hit F5 after getting the connection reinitalized error. Apache and other system logs are not reporting any additional errors.
2012-07-06T08:47:22+00:00 DEBUG (7): HEADERS ALREADY SENT: <pre>[0]
/var/www/vhosts/site/app/code/core/Mage/Core/Controller/Response/Http.php:44
[1] /var/www/vhosts/site/lib/Zend/Controller/Response/Abstract.php:727
[2] /var/www/vhosts/site/app/code/core/Mage/Core/Controller/Response/Http.php:75
[3] /var/www/vhosts/site/app/code/core/Mage/Core/Controller/Varien/Front.php:188
[4] /var/www/vhosts/site/app/code/core/Mage/Core/Model/App.php:304
[5] /var/www/vhosts/site/app/Mage.php:596
[6] /var/www/vhosts/site/index.php:78
This website was working fine on a Centos 5.4 with PHP 5.2.13. All the same Apache and PHP modules were installed on the new Debian server. Any help would be sincerely appreciated.
Version Information
Magento 1.4.1
Debian 6.0 i386
PHP 5.3.3-7+squeeze13 with Suhosin-Patch (cli) (built: Jun 10 2012 09:35:18)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with the ionCube PHP Loader v4.0.7, Copyright (c) 2002-2011, by ionCube Ltd.
Server version: Apache/2.2.16 (Debian)
Server built: Apr 1 2012 06:40:08
A rule in our Netasq firewall was blocking the <SCRIPT> tag. Once we disabled the rule, the client was able to use the tag again. We did warn him, however, that netasq probably put that rule their for a very good reason.
Related
I'm using Homebrew to manage both of them and they are up to date.
~ $ brew --version
Homebrew 1.8.4
Homebrew/homebrew-core (git revision a166; last commit 2018-12-08)
~ $ php --version
PHP 7.3.0 (cli) (built: Dec 7 2018 11:00:11) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.3.0, Copyright (c) 1999-2018, by Zend Technologies
~ $ php-cs-fixer --version
PHP needs to be a minimum version of PHP 5.6.0 and maximum version of PHP 7.2.*.
~ $ brew upgrade php-cs-fixer
Error: php-cs-fixer 2.13.1 already installed
This happens when I try to use php-cs-fixer
~ $ php-cs-fixer fix file.php
PHP needs to be a minimum version of PHP 5.6.0 and maximum version of PHP 7.2.*.
So, I downloaded php#7.2 and php-cs-fixer.phar to test and it works that way.
~ $ /usr/local/Cellar/php#7.2/7.2.13/bin/php /Users/aaronk/php-cs-fixer.phar fix file.php
Loaded config default from "/Users/aaronk/.php_cs".
Using cache file ".php_cs.cache".
Paths from configuration file have been overridden by paths provided as command arguments.
1) file.php
Fixed all files in 0.014 seconds, 10.000 MB memory used
~ $
So my question is, how do I get homebrew's php-cs-fixer to work?
Is homebrew doing something wrong here?
(p.s. is there a tag for php7.3)
As said by godbout, PHP-CS-Fixer does not yes support PHP 7.3. You can track the GitHub issue [Meta] PHP 7.3 support #3697, to follow the evolution of the situation. According to this issue, the following changes in PHP 7.3 still need to be adressed:
Flexible Heredoc and Nowdoc Syntaxes
list() Reference Assignment
instanceof now allows literals as the first operand, in which case the result is always false.
Allow a trailing comma in function calls
hrtime function has been added
is_countable function shall be handled as all other native functions
The current version "friendsofphp/php-cs-fixer": "^2.14" now supports php 7.3. You could upgrade it and it should work fine.
Nothing to do with Homebrew. It's php-cs-fixer itself that doesn't support PHP7.3. You would get the same issue through composer, with unmet dependencies.
The mentioned issues isn't related to the PH PC Fixer code, rather to it's features. It's clear missuse of composer.json, where are dependencies, not features.
PHP CS Fixer works fine on PHP 7.3, see this PR.
This command allows you to install it on PHP 7.3:
composer update --ignore-platform-reqs
Let me know if you came across any troubles.
To clarify - PHP CS Fixer being run under PHP 7.3 may fix code written using syntax up to PHP 7.2. But if one would run tool on code written in 7.3, eg is_null($foo, ) (trailing comma), then behavior of fixer is not stable (producing null === $foo, - still, with trailing comma), which is an issue.
I am finishing off a blog tutorial and am trying to do my final push to GitHub and Heroku. I just added the popper gem to the Gemfile and then tried to push to GitHub as usual using git push origin master.
Normally it then asks for my username and password, but instead I got the following error and have no idea what it means or why I got it. I haven't changed anything else as far as I remember.
fatal: unable to access 'https://github.com/<username>/FrogBlog.git/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
I am unsure how to proceed, as this message means nothing to me. I can post more files from my project if required, please advise.
GitHub recently deprecated some old and insecure cryptographic standards, including TLSv1, which is referenced in your error message:
On February 8, 2018 we’ll start disabling the following:
TLSv1/TLSv1.1: This applies to all HTTPS connections, including web, API, and git connections to https://github.com and https://api.github.com.
diffie-hellman-group1-sha1: This applies to all SSH connections to github.com
diffie-hellman-group14-sha1: This applies to all SSH connections to github.com
We’ll disable the algorithms in two stages:
February 8, 2018 19:00 UTC (11:00 am PST): Disable deprecated algorithms for one hour
February 22, 2018 19:00 UTC (11:00 am PST): Permanently disable deprecated algorithms
Most Git clients should continue to work, but there are some known incompatibilities.
If you update your Git client (it looks like you're using the standard CLI client?) pushing to GitHub will probably start working again.
This is the error message I get in the time of installation
4/14/2015 5:14:19 PM - Found installed product - Global Location
4/14/2015 5:14:19 PM - VSIXInstaller.NoApplicableSKUsException: This extension is not installable on any currently installed products.
Please reply me any solution to solve this issue....
I am following steps according to "Install Tools to Build for iOS" on msdn https://msdn.microsoft.com/en-us/library/dn771551.aspx, to setup an iOS build..
On my Mac, I get the following error when I execute the "vs-mda-remote test" command..
Initializing self test for https
downloading cert for pin 390276
Downloading client cert for selftest from https://myMac:3000/certs/390276 to /Users/fred/remote-builds/selftest/selftest-client.pfx
pfxPath: /Users/fred/remote-builds/selftest/selftest-client.pfx
serverUrl: https://myMac:3000
buildUrl: https://myMac:3000/build/tasks?vcordova=4.1.2&cfg=release&command=build&options=--emulator
_tls_common.js:176
c.context.loadPKCS12(pfx);
^
Error: not enough data
at Error (native)
at Object.createSecureContext (_tls_common.js:176:17)
at Object.exports.connect (_tls_wrap.js:850:21)
at Agent.createConnection (https.js:82:14)
at Agent.createSocket (_http_agent.js:194:16)
at Agent.addRequest (_http_agent.js:166:23)
at new ClientRequest (_http_client.js:154:16)
at Object.exports.request (http.js:49:10)
at Object.exports.request (https.js:136:15)
at Request.start (/usr/local/lib/node_modules/vs-mda-remote/node_modules/request/request.js:674:30)
The server appears to be sending one..
vs-mda-remote
Copyright (C) 2014 Microsoft Corporation. All rights reserved.
0.2.7
Loading resources for language en from /usr/local/lib/node_modules/vs-mda-remote/resources/en/resources.json
Build Retention initialized with baseBuildDir /Users/fred/remote-builds/builds, maxBuildsToKeep 20
Initialized BuildManager with installedCordovaVersion: 4.1.2; baseBuildDir /Users/fred/remote-builds/builds; maxBuildsInQueue 10; deleteBuildsOnShutdown true; allowsEmulate true; nextBuildNumber 1479
ios-sim is installed on path at: /usr/local/lib/node_modules/vs-mda-remote/node_modules/ios-sim/build/release/ios-sim
Remote build server listening on [https] port 3000
GET /certs/390276 200 1ms - 3.51kb
Trouble shooting tried:
- to ensure that iOS profiles and xCode developer certs exist - I tested that I can deploy a test app to an iPad.
- rerun install and checked every message to look for failure, none
- regenerated serverCert and clientCert multiple times
possibly linked
- the pfxPath is valid and a pfx does exist. (other issues around this issue indicate that a passphrase must be passed to the context object and I cannot find any passphrase being passed, but this code https://sourcegraph.com/github.com/joyent/node/.CommonJSPackage/node/.def/commonjs/lib/_tls_common.js/-/createSecureContext #176 seems to handle no passphrase..
I've just had the same problem, but managed to figure it out - the following was configured Mac
1: Start the Server without TLS security
vs-mda-remote --secure false
2: Test the server (launch another terminal)
vs-mda-remote test --server http://localhost:3000
At this point - you shouldn't get any errors (this was failing here because the test mode seems to use TLS by default, and the only way to test with no security, is to manually specifiy the server URL)
3: Configure visual studio as per the documentation
https://msdn.microsoft.com/en-us/library/dn771551.aspx
I have managed to get mine working great as of about 5 minutes ago using this. One point to make, in visual studio (2003 + CTP3.1) make sure you select iOS (to the right of the build mode drop down), if you don't select iOS then the iOS specific devices will not appear in the run list - sounds trivial, but it took me a few seconds scratching my head why I couldn't deploy to iOS remotely when I had Android build selected
Hope that helps you out!
I disabled some plugins to upgrade Jira. The upgrade was not carried out as new version of Jira needs 64 bit hardware. Upon stopping and restarting the instance to resume with original application, I get this message:
The following plugins are required by JIRA, but have not been started:
FishEye Plugin (com.atlassian.jirafisheyeplugin)
catalina.out:
***********************************************************************************************************************
The following plugins are required by JIRA, but have not been started: FishEye Plugin (com.atlassian.jirafisheyeplugin)
***********************************************************************************************************************
2011-08-04 16:08:51,896 main FATAL [atlassian.jira.upgrade.UpgradeLauncher] Skipping, JIRA is locked.
2011-08-04 16:08:51,896 main INFO [atlassian.jira.scheduler.JiraSchedulerLauncher] JIRA Scheduler not started: JIR startup checklist failed.
2011-08-04 16:08:52,219 main FATAL [jira.web.dispatcher.JiraWebworkActionDispatcher]
******************************************
JIRA startup failed, JIRA has been locked.
******************************************
Aug 4, 2011 4:08:52 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Aug 4, 2011 4:08:52 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 62989 ms
Does anyone have a clue as to how to re-enable fisheye plugin manually?
Any help greatly appreciated, thanks to all SO`ers.
This also happens when the update is succesfull and you've deactivates FishEye before. Sad.
There's an article in Atlassian's documentation at http://confluence.atlassian.com/display/JIRA/How+to+Enable+the+FishEye+Plugin+from+the+Plugin+Administration+Screen, but this doesn't work for me (note that the plugin name is written wrong there, too).
Any other hints?