I have the problem that with merchandise where there multiple options (t-shirt sizes, etc) that the 'add to cart' button is missing. It is OK where there there is only one option - a cd for example. I have entered all the info, stock numbers, prices, etc.
The problem persists if I turn off all other plugins. I can't see an error in the Java console (I tried a plugin that is supposed to fix java errors anyway) and the add to cart button is visible if I switch to another theme. Be great of someone who has been down this path can get me started on finding a solution.
Thanks for you help!
http://5.133.182.68/~knifewor/product/knifeworld-gold-logo-t-shirt/
Update
Turning debugging on I can see the following error:
Notice: wp_enqueue_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /home/knifewor/public_html/wp-includes/functions.php on line 3245
Notice: wp_enqueue_style was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. Please see Debugging in WordPress for more information. (This message was added in version 3.3.) in /home/knifewor/public_html/wp-includes/functions.php on line 3245
Notice: Cookie cannot be set - headers already sent in /home/knifewor/public_html/wp-content/plugins/woocommerce/includes/wc-core-functions.php on line 375
Notice: Cookie cannot be set - headers already sent in /home/knifewor/public_html/wp-content/plugins/woocommerce/includes/wc-core-functions.php on line 375
Notice: Cookie cannot be set - headers already sent in /home/knifewor/public_html/wp-content/plugins/woocommerce/includes/wc-core-functions.php on line 375
And I now notice on the shop page the footer fails to load.
There is a php error in the page. You need to turn on the WP_DEBUG to see the error.
Normally, if the problem goes away when you switch themes, especially if there's no JS error, then we can assume the problem is in your theme's WooCommerce templates. They are probably out of date. I fixed a lot of themes that "broke" when WooCommerce updated to 2.0/2.1.
In the admin, under WooCommerce go to System Settings and at the bottom of the page you should see any templates that are being overridden in the theme. I think it should also say which templates are out of date.
If you view source you will see the page is incompletely loaded. This means wp_footer() is never run and therefore all the scripts that belong in the footer are never loaded... including WooCommerce's add to cart scripts.
Therefore, I second #sabanix's answer to turn on WP_DEBUG. The problem may or may not be in your theme's WooCommerce templates, or a more generic error in your theme.
If I had to guess, it is probably single-product/add-to-cart/variable.php template. I would suggest renaming it (or deleting it) so that WooCommerce will use its default template and see if that resolves it.
Related
I have a java project I'm assessing using Fortify. Some of the issues need to be suppressed and if so, a comment needs to be made describing why the issue is being suppressed.
How can I see this comment in the generated application report? I'm using the web interface, not workbench.
The suppressed issue appears, I just want to be able to see the comment along with it.
Thank you in advance.
EDIT:
I am able to work in the workbench if needed.
After awhile of searching I was able to figure out how to go about this.
For starters, I should mention that our Fortify scan was initiated by a Jenkins build. In the web interface, or SSC, I had to navigate to the artifacts tap. From there, I pressed the "Download Application File With Sources" button, which gave me an updated FPR that contained all of the suppressions and comments.
After that I had to use the Audit WorkBench to open that .fpr file. Then I chose not to override the default filter (not sure if that will pop up for everyone) and clicked the "Reports" tab.
I then selected the "Developer Workbook" template from the dropdown then clicked Issue Filter Settings. I checked "Suppressed" and deselected Collapse Issues (only Suppressed should be checked).
Next, I added a filter for only high's and criticals by selecting advanced to the right of filter and choosing "fortify priority order", "does not contain", "low" or "medium". There's an "||" to the top right you can click to have an additional filter.
Then I selected generate and it worked! The comments for suppressed issues will appear under "Audit Comments" in the report for each issue. Hope this helps others in the future.
I can't seem to edit some webdynpro java views, whenever I try to edit the code it prompts me to logon to DTR and when i do logon, a DTR console appears at the bottom and still i can't edit. I repeat this step over and over again no luck.
Any assistance will be highly appreciated.
Below are images of my screen results:
It seems like some of your views have been checked-in already and some have not. The latter require DTR login and this is normal. The problem lies in that you cannot login somehow (because of permissions or other reason) and that's why you cannot edit. Try to:
Set up DTR client properly
Set up development configuration
Synchronize resources again
Afterwards try to edit once more.
This issue may have to do with a very specific Domino version (see below), so I start with a few technical details:
Server in question is a virtualized Windows 2008 R2 64bit machine. Domino release is
IBM Domino (r) Server (64 Bit) (Release 9.0.1FP4 HF70 for Windows/64)
The latest JVM security patch (9.0.1.4 dated 20150724) is installed.
I may be wrong but I feel that the issue started after we installed the latest patches (FP4 HF70 and JVM):
On an Xpage I have a very simple "Refresh" type button just triggering a partial refresh on an xp:panel (id="pnMainContainer") surrounding the bigger part of my page. Amongst other components there is a tabbed panel inside pnMainContainer. This is set to open with the first of three tabs upon loading the page.
Assuming that I have the third tab open, usually if I click the Refresh button tab #3 stays open, and its contents are freshed as expected.
Sometimes however, after I left the page open for a several minutes (can't really say how long, maybe somewhere around half an hour), the refresh obviously is returning to its initial state, showing the first tab instead of the one that was open before, and emptying all editable fields that were filled before.
When that happens I see the following warning appear on the console:
HTTP JVM: WARNING: CLFAD####W: State data not available for /myPage
because no control tree was found in the cache.
I am aware of this post here: Xpages document changing document mode?, and although I don't use Xagents in my application I tried setting my page's viewState property to nostate. This apparently didn't help solve the problem.
One more detail that might be helpful is the fact that the page in question makes use of a managedBean bound to the viewScope.
Any ideas what could be causing this, and - moreover - how to change this behaviour?
Update 2015-09-10: following #Paul's suggestions below I set my application's session timeout to 120 minutes last night (xsp.session.timeout=120). This morning I tried again: loaded the page in question then let it sit there for approx. 45 minutes. After that time hit my partial refresh button. Result: page is reloaded to its initial state, and server console is showing the same warning as yesterday.
For completeness sake here's the entire contant of my application's xsp.properties as it is at the moment:
xsp.error.page.default=true
xsp.library.depends=com.ibm.xsp.extlib.library
xsp.resources.aggregate=true
xsp.theme=oneuiv3.0.2
xsp.session.timeout=120
xsp.application.timeout=120
xsp.persistence.mode=basic
Is there probably something in there that would be causing this behaviour?
Some more details: did some more testing and found the following details:
with the above mentioned xsp.properties caching appears to be stable for quite a while as long as I let the pages just sit there
as soon as I make any kind of adjustments somewehere on my page or in related codes (SSJS libs, managed beans, or the page itself) cache needs to be rebuilt as the state of my page is lost (even after a few seconds). It doesn't matter at all whether "Build automatically" is turned on in Designer or not
Tried setting page persistence from xsp.persistence.mode=basic to xsp.persistence.mode=file. This results in a "java.io.NotSerializableException" as soon as I open tab #3 which makes use of internal properties of a managedBean that is registered at a viewScope level
Built a very simple app on the same server with just a few partial refesh buttons: result is that page state is never lost for pages from this test application
As long as the cache is lost only when I update design I don't really care. But I'm afraid that this might escalate if many users are starting to access the pages.
Anything else I could do to improve performance?
viewState="nostate" basically means don't store the component tree or scoped variables for this page server-side. That's why you use it for XAgents, which will never be partially refreshed.
The key data is:
1) How quickly the XPages session is set to timeout. Once that times out, you'll lose state data. I don't think keepSessionAlive control helps here.
2) Whether other tabs are being opened in the browser. There are other XPages properties that determine the number of pages stored in memory / disk. The maximum is stored for the whole browser session and, once you hit the maximum, the earliest is dropped from memory, hence the same message (and the other reason for setting nostate on XAgents.
It sounds like the first is the cause. Note that XPages session timeout and http timeout are separate timeouts. The first is when the state data for the current session is removed and is application-specific (because each XPages app has a separate runtime JVM), the second when a subsequent request to the browser will prompt for authentication.
I have created a subpackage of views in order to customize the default look of securesocial's templates. (I have used https://github.com/ngarera/securesocial-custom-views-sample as an example and basically copied the relevant files)
There are two i18n-files (messages.en, messages.de) in my /conf folder.
Viewing the main page confirms that the messages.en is correctly used.
However, when calling /login (and therefore displaying the custom template), no messages-key is correctly looked up - instead only the key itself (e.g. "auth.login") is displayed, when really it should show "Login".
I have seen a similar request at Stackoverflow (How to change text in SecureSocial) where it was stated to remove the .en file extension. Doing that will show the correct Message...but creating one messages file is not really the point of internationalization...
I have confirmed that my browser sends the correct language (http://www.mybrowserinfo.com/detail.asp?bhcp=1) so messages.de should work...(which it does when I open a self-made controller - only the custom-securesocial-view is not working...)
Does anybody have similar problems?
And why does the localization work for securesocial's messages?
Regards,
David
PS: using Play 2.1.3, Java
There were some issues in the SecureSocial code that prevented i18n from working properly.
This has been fixed and is currently available in the master-SNAPSHOT version because a stable version with those changes has not been released yet.
If I go into Google Webmaster Tools, and click Health->Crawl Errors, I noticed that our site has about 1,045 Not Found errors.
Each of these errors can be fixed manually by:
filtering through the list to find the specified error that has been
needs to be fixed, and clicking on it.
In the resulting dialog clicking the Fetch as Google link,
Clicking Fetch
And finally, clicking submit the index (provided there are enough fetches remaining to do so), and then marking it as fixed.
Since there are about 1,000 errors to fix, doing this manually seems a bit out of the question.
(Note: I didn't have anything to do with it but the site was migrated before the content causing the errors.)
I'm aware that it is possible to retrieve a list of site errors, but that's really only half the battle. I looked over the APIs and didn't really find a way to use the Webmaster Tools API to mark errors as fixed.
Marking errors as "fixed" is perfectly possible with this API call:
https://developers.google.com/webmaster-tools/search-console-api-original/v3/urlcrawlerrorssamples/markAsFixed
So you can easily automate this by e.g. …
fetching the crawl error sample (1000 max.)
checking the given URLs
marking working URLs as fixed via API
Keep in mind: Crawl error information is updated about once a day. So if there are more than 1000 errors and half of them get marked as fixed, new data that was not in the sample before will likely roll in after a day has passed.
I'm not sure what your question is, as I just successfully tested removing all errors (4 in my case) which was possible with just a few clicks. If the errors keep reappearing you might want to take a look at where the invalid URLs are linked from: if it's internal stuff, you should fix those links, and if it's external links you should either add redirects to the updated/moved pages, or ask the external web site(s) to update their links to your site.