How to enable Joomla debug mode from the URL - debugging

I often need performance information from live sites. Since I cannot show debug information to the end users, I need a way to enable Joomla! debug mode with a URL parameter, that is,
http://example.com/?debug=1
I have only been able to achieve this with a core hack of includes/framework.php at line 91 (Joomla 2.5.9):
define('JDEBUG', $config->debug || JRequest::getVar('debug','0')=='1');
Which alternatively could be played on configuration.php:
public $debug = JRequest::getVar('debug','0')=='1';
I just tested overriding the configuration with a system plugin following Mark Dexter and Louis Landry's post at Using Plugins to Override Core Classes. But a quick-test with Ivan Rajkovic suggestion,
print_r(JLoader::getClassList());
shows that the configuration is already loaded, so it cannot be overridden.
Can you suggest a better way to achieve this without a core hack?
Is there a solution for Joomla! 3?

I think if you enabled the debug plugin (in the plugins list) and set its access level to Superuser or whatever your rank is, no one else will be able to see the debug information except you.
Update
There's a plugin (for Joomla! 1.5 though) that limit the debug output for certain IPs to make it possible for you to debug a live site without exposing it to everyone. Not sure how easy is it to make it work with Joomla! 2.5

Related

How to add an application to Apache Brooklyn catalog

I am trying to add applications into Brooklyn catalog. can anyone explain steps to add a new application to catalog.xml?
I did try the sample catalog provided at https://brooklyn.incubator.apache.org/v/0.7.0-M1/use/guide/quickstart/policies-and-catalogs.html . The application gets listed in catalog tab but when I try to launch it, it gets stuck at 'configuring'. Is there something else that needs to be done ?
I tried adding existing application to catalog ( https://brooklyn.incubator.apache.org/v/latest/ops/catalog/index.html ) but it failed. Can anyone help me with this ?
I'd strongly recommend upgrading to 0.7.0-M2-incubating, as the catalog has significantly improved since 0.7.0-M1. The documentation at https://brooklyn.incubator.apache.org/v/latest/ops/catalog/index.html describes the steps for 0.7.0-M2-incubating; they will not work for 0.7.0-M1.
The link to an explicit version of the docs (rather than latest) is https://brooklyn.incubator.apache.org/v/0.7.0-M2-incubating/ops/catalog/index.html
There are also more improvements in snapshot (and in existing pull requests), if you fancy trying the bleeding edge!
For the 0.7.0-M1 error "gets stuck at configuring", we'd need more info (e.g. logs, etc). Suggest you e-mail the mailing list or jump on IRC if it's still a problem (https://brooklyn.incubator.apache.org/community/mailing-lists.html).

Get uRapidFlow logs for an import profile batch

I am running a php script using a cron job to run a uRapidFlow / RapidFlow import profile. Here is the documented code I found to help me do this.
I need to be able to run through the imported batch, row by row, and do some processing based on if the row was imported successfully or not. It would also be very convenient and useful to be able to send email notifications on failed imports in general as well. If anyone has any idea, or can point me in the right direction, I would be very grateful. I don't see any documentation for this online, so I am going through the module code and database trying to figure it out myself.
I am using Magento EE 1.12.0.2
The best bet, unless you modify the uRapidFlow extension (check license information before doing so). Would be to extend it and use a observed event.
Try the observer : catalog_product_import_finish_before Which is triggered after each product is imported. Bare in mind this solution would be triggered globably for any manual imports, so if you build a small extension, perhaps make it easy to toggle on and off.
More can be found on Magento's observers here : http://www.magentocommerce.com/wiki/5_-_modules_and_development/0_-_module_development_in_magento/customizing_magento_using_event-observer_method
Note as you've not specified which version of Magento you are using, you'll have to check if that observer is supported in your version.

Editing velocity template of Liferay changes not showing or takes a while

I'm currently editing my portal_normal.vm (server/tomcat/webapps/mytheme-theme/templates) testing if I can write on the file and see it on my browser. I tried putting a test comment "<!-- test -->" just to see if I can really write on the file. So I refreshed the file and hope I can see the comment I've added, but there we're none. So I continued refreshing (ctrl+r),\ and viewing the source code for almost an twenty minutes. After a while when I tried viewing it again it reflected in my source code. So I thought it was cached by either Liferay or my browser.
So I tried tweaking the comment adding version on it ("<!-- test v2 -->"), hoping to see changes. I checked it on another browser and the comment didn't update or include my added version. So I think Liferay is responsible for the issue.
this is what my portal-ext.properties contain:
auth.token.check.enabled=false
# Database settings
jdbc.default.jndi.name=jdbc/LiferayPool
#For removing captch
captcha.check.portal.create_account=false
session.enable.phishing.protection=false
default.regular.theme.id=my_site_WAR_my_theme
#Delete cookies while deleting session
session.enable.persistent.cookies=false
#redirecting null problem.
redirect.url.security.mode=mysite.com
journal.template.velocity.restricted.variables=
admin.email.from.name=Market.Travel Team
admin.email.from.address=admin#mysite.com
# Added because of the Error - No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
hibernate.current_session_context_class=thread
session.enable.url.with.session.id=false
and my portal-developer.properties
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
Addition: When I tried editing the css files I can see the changes fast. Just one reload the the changes appear. I think it is just in my velocity template that take some time or there's something wrong.
Liferay version: Liferay Portal Community Edition 6.0.6 CE
Thank You!
There is really no need to define your own portal-developer.properties. By adding -Dexternal-properties=portal-developer.properties to your JAVA_OPTS in tomcat/bin/setenv.(sh|bat) Liferay will use it's default developer settings, which are almost identical to what you have provided. However, I do not believe this is contributes to (or could resolve) your problem. More details here.
The developer properties do allow you to make live changes to the templates provided you are changing the right file. Due to the default context.xml Liferay provides to the deployed webapps, the webapps are copied/cached in tomcat/temp/{id}-webapp-name. This means if you change the template in webapp/mytheme then it may take tomcat a while to pick up on the change, if it notices the change at all (this will depend on the tomcat configuration). On the other hand, if you make a change in temp/1-mytheme it will show up immediately. Editing the files in the temp folder is probably not ideal, so...
How to fix this: (no specific order)
Prevent Tomcat from using the temp directory for your theme. Create a context.xml file for your theme.
<Context cachingAllowed="false"/>
This file should be placed in the META-INF folder of your
theme. If you are using the Liferay auto-deploy feature the
context.xml file may be clobbered, here, and here. If this
is the case you will need to find a work around that best suits your
needs, such as modifying the context.xml after the theme is deployed.
If you are using the Liferay Plugin-SDK the you can follow the fast plugin development guide for setting up your development environment.

couchdb public interface authentication through rewrites

I have a website set on a specific domain which is completely separated from my couchdb url through rewrites and virtual hosts, and I got to a point where I need to add some user authentication using _sessions API but I'm afraid I can't do it with rewrites:
{
"from": "auth",
"to": "../../../_session"
}
gives me:
{"error":"insecure_rewrite_rule","reason":"too many ../.. segments"}
which is acceptable, but now I'm wondering how would I get the session authentication to work from my domain without exposing couchdb url, and also, the session seems to be related to the domain so if I login through couchdb.example.com it won't work when using mywebsite.com as the public interface?
Thanks
PS. I've just found this post where there's an alternative by disabling secure_rewrites on the httpd config file, which seems to work, although, I was wondering that perhaps might be not a good approach and if is there something else which is ideal for this kind of problem.
I recommend to set secure_rewrites=false and don't worry about it.
We had a great discussion about CouchDB rewrites and security in the Iris Couch forum. Also see my post later about using Audit CouchDB. These are the highlights:
The secure_rewrites option is not the ultimate source of security for your data. At best, it is one layer in a multi-layer solution
The ultimate source of security is the _security object in the database. So that is where you should focus your attention
The Audit CouchDB tool scans every detail about your couch and it will tell you if any red-flags are present. It is implemented in Javascript so if you have NodeJS, you can run it; or simply reading the source code gives you an idea of what it is looking for.
If you are using vhost, than /_session handler is available at the vhost root without any rewrite rules (by default).
See the section [httpd] of default.ini:
vhost_global_handlers = _utils, _uuids, _session, _oauth, _users

Toggle javascript support programmatically without restarting firefox

The problem: toggle javascript support without restarting firefox (nor resorting to different driver) during cucumber test run.
If Firefox's prefutils were exposed to javascript in a web page, that would make it possible. But it is not the case.
So, is there a plugin that does it? Or is there another way to solve the problem? Or is there a good tutorial (that highlights the exposing bit) on how to make such a plugin?
Edit
On a second thought, how would javascript be of any help once it is disabled? Probably the whole idea is a bit screwed.
I assume that your tests run with normal web content privileges. In that case, they aren't going to be able to affect browser settings such as whether JavaScript is enabled (I assume that's what you mean by "toggle JavaScript support").
I'd implement a simple XPCOM component with a method to turn JS support on and off (by setting the appropriate pref). You can expose it as a JavaScript global property so that your tests can access it. See Expose an XPCOM component to javascript in a web page for more details. Package your component in an extension and make sure it is installed in the Firefox instance where your tests are running.
If you want to access the preferences API directly from your content script, you can add the following prefs to Firefox, either in about:config or by adding the following lines to prefs.js in your profile directory:
user_pref("capability.principal.codebase.p1.granted", "UniversalXPConnect UniversalBrowserRead UniversalBrowserWrite UniversalPreferencesRead UniversalPreferencesWrite UniversalFileRead");
user_pref("capability.principal.codebase.p1.id", "http://www.example.com");
user_pref("capability.principal.codebase.p1.subjectName", "");`
user_pref("signed.applets.codebase_principal_support", true);
Replace www.example.com with the domain that you want to grant the privileges to. Also add this line to your JS code before you call the preferences API:
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
A local file (something loaded from file:///) is allowed to request additional privileges. Normally you would get a prompt asking whether you want to allow access - you can "auto-accept" the prompt by adding the following lines to prefs.js in the Firefox profile:
user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p0.id", "file://");
user_pref("capability.principal.codebase.p0.subjectName", "");
You page can then do:
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");
var branch = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
branch.setBoolPref("javascript.enabled", false);
This will definitely work if your page is a local file. Judging by the error message however, you are currently running code from about:blank. It might be that changing capability.principal.codebase.p0.id into about:blank or into moz-safe-about:blank will allow that page to get extended privileges as well but I am not sure.
However, none of this will really help if JavaScript is already disabled and you need to enable it. This can only be solved by writing an extension and adding it to the test profile. JavaScript in Firefox extensions works regardless of this setting.
That means you need Javascript to toggle enabling or disabling Javascript.
function setJavascriptPref(bool) {
prefs = Components.classes["#mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefBranch);
prefs.setBoolPref("javascript.enabled", bool);
}

Resources