Magento seems to be using "Happy go Lucky" error handling, where all errors in xml files will just cause the xml config file to be ignored. And missing/wrong tags will just be ignored too, sometimes causing Magento to skip parts of the xml file.
But is there any way(A log file or something) which shows exactly what part of the config files Magento skips, and which tags are unknown/wrong. Using Magento 1.6 if that matters.
From what I have seen in Magento, it will throw out the entire XML file if there is invalid XML in it - broken/mismatched tags, erroneous characters, etc. I think it would be somewhat impossible for a xml parser to do any sort of a decent job parsing this out - that's the goal of XML. If my configuration isn't loading, the first think I like to do is go and perform a wellformedness validation on the code, which will show me if I have a problem there.
If there is references to invalid classes, usually it will break. Layout XML is different - it will ignore the block and continue on, which can be a real pain to troubleshoot.
So, to answer your question - no, there isn't a native way to do this. The best way, IMO, is to go and validate it at a third party.
There is logging in Magento, to enable it:
Go into your Admin Panel, then System > Configuration > Advanced > Developer
Under Log Settings ensure Enabled = Yes
This will create two separate logs in magento root/var/log (in my case /var/www/html/var/log)
Exception.log will hold any errors created using Mage::LogException($e)
System.log will hold any logging created using Mage::Log('message')
You can also create your own log files...if you so wish by
Mage::Log('message', null, 'my.log');
This will create a my.log file in the var/log directory.
FYI - I believe the reason Magento handles configuration files in this manner is to protect the rest of the system from an issue with a single extension.
Related
I am translating my application through *.po-files, but the command
mix gettext.extract --merge
generates options only for hardcoded strings.
I have read in documentation that I can't edit *.po-files manually because they are overwritten every time.
How can I translate errors that come from changeset validations and so on?
dgettextfor errors is called in web/views/error_helpers.ex
I'm not sure if these get extracted and merged into errors.po, but that's where you'd likely put them manually if they do not.
I tried to disable a magento extension by setting it as "False" in /public_html/app/etc/modules/{extension folder} but now I am receiving an error
"Fatal error: Class 'Mage_Enquireproducts_Helper_Data' not found in /home/devbseatedglobal/public_html/app/Mage.php on line 546"
Why is this happening?
The extension probably has an XML file that has an attribute that looks something like this.
module="enquireproducts"
This XML instruction tells Magento to load the module's data helper to translate a string.
When Magento loads all those XML files, it places them into a cache so it only needs to load them once. Although you've disabled the extension, my guess is there's still a cached XML file somewhere. Try manually clearing your cache. (If you're running stock, cache files are stored in /var/cache/* -- you can clear them by deleting them)
It's also possible a different extension has XML configured that includes the attribute
module="enquireproducts"
If that's the case, these modules are dependent on that first module, and disabling that first module will basically break things unless you disable the dependent modules.
Hope that helps!
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.
I installed a new module and now I get this error and can't log into the admin area of Magento:
Warning: include(Mage/Awautorelated/Helper/Data.php): failed to open stream: No such file or directory in /var/www/spasandstuff.com/lib/Varien/Autoload.php on line 93
I have removed the module, cleared the cache and session folders and it still gives me that error.
I ran grep -r "Awautorelated" * and found nothing on the server. I restarted Apache to clear APC cache. Magento uses Lightspeed but I believe that just uses the Magento cache directory which I cleared. So I am at a loss as to how to fix this issue. Is there a database table that caches module info?
Any help will be greatly appreciated.
Somewhere, a piece of Magento code is attempting to instantiate a helper class with code that looks something like
Mage::helper('awautorelated');
Mage::helper('awautorelated/data');
Since you've removed the module from the server and cleared your cache, there's no <model> node for the <awautorelated> group. That's why Magento is looking for this class in Mage/Awautorelated instead of AW/Awautorelated.
Based on everything you've said, my guess is you have an XML file somewhere, likely in the layout, that still contains an attribute something like this
<sometag ... module="awautorelated" ...>
These module attributes are used to specify a translation helper for "inner nodes". Your Magento system loads the XML file, parses it, sees the module="awautorelated", and then attempts to instantiate a awautorelated helper to translate the nodes. Since you've remove that module files, it can't instantiate the helper and yells at you. Try a case insensitive grep (or ack)
grep -i -r 'awautorelated'
and make sure you search the entire Magento source tree. Not just app/code, but app/design as well.
Did you remove
AW_All.xml
AW_Productrelater.xml
from /app/etc directory
Yes, there is the table core_config_data, but I don't expect removing the module entry from their will be realted to this problem, but you can certainly remove the entry now the module has been removed.
Are you using memcached for caching? you could remove that. I'm not 100% sure restarting apache clears the APC cache either ...
What is the best practice when serving files from the Zend Framework MVC? These files have to be served from the MVC as they are protected.
I know you can read in the file and place it into the Response object but this seems like a bad practice as you would be reading the entire file into memory then serving it. Right now I usually do:
header('Content-type: image/jpeg');
fpassthru(fopen($path, 'rb'));
exit;
But this also doesn't seem right as I'm stopping the execution of the script. Any suggestions?
I see nothing wrong with just exit(); What you will need to be careful of is any output buffering layers you may have on (gzip compression, etc). Large files could blow up those buffers pretty quick, so you'll want to close them out and potentially 'chunk' your output with a fopen/fread loop.
I would suggest building a super-simple script for retrieving files based on ticket system like in CMS you generate ticket to DB - filename, unique-hash and than redirect to the super-simple file-retieving script (file.php?hash=asd52ad3as1g5). It will get the hash from query and based on it fetch the real filename and push that to output as you have written using fpassthru. The hash need to be unique and hard to guess...
You could try using the X-Sendfile header. It is supported by lighttpd and newer versions of apache. Basically the webserver will replace the output of the script with the file you specified. The downside being that it is specific to the configuration of the webserver, so you may be on a host that doesn't support it.