Extended OOB Onepage Link Block and link.phtml to disable the button based on customer group id, the changes are working but the button is disabled for all the customers, not just for the customers that are in specified group. I cleared cache many times but still no luck. I have correct entries in checkout_cart_index.xml and I do see it working but not the way it's supposed to do. Is there anything else that needs to be done to fix this issue since it prevent checkout for all the customers?
Found out hard way that it was a simple typo in the Block class name, I was using wrong Session class, where required method wasn't available. Took sometime to find this out and but it's working now. Please make sure that vendor/module, and/or other names are correct with case, otherwise it's hard to debug since we don't get meaningful errors unlike Java. I couldn't enable developer mode due to other issues which also complicated the problem.
Suddenly all the changes I've done on a joomla(2.5) site has been lost. reseted to the original state. How can this be anyone?
How this can be, is a mistery to all of us (without the log files). How this can be undone, however, is a question worth answering.
One way is to set back your database back-up. That is, obviously, if you have made one.
Another way is to set back any export you would've made that holds the data you are now missing. That is, obviously... you get the point.
If there is no way you have secured your data, it is probably gone. You could contact your server administrator to see if he has any backup data, but other then that your data is gone.
I have a Magento site using version 1.6.2.0 with which I'm experiencing problems with duplicate orders.
Having researched the subject I have found mostly forum threads explaining that 1.4.x had problems with duplicate orders and the solutions mentioned (even those on SO which I have found) merely suggest the user updates Magento to >1.4.
I have also found a proposed solution here but am reluctant to delete observers which will prevent downloadable purchases working.
I've also spotted the Array Of Death fix mentioned a few times (e.g. here) but this problem isn't present in 1.6.x, Zend appears to have resolved it.
There are a couple of Javascript hacks suggested whereby the Confirm Order button is hidden upon submission but Magento 1.6.x already does this.
I have increased the payment gateway timeout configuration variable to 120 seconds and am as yet to see if it yields results. I can't test it as the problem is intermittent (and probably therefore caused by communication or lack thereof between the payment gateway and Magento).
I am using Sagepay as the payment gateway.
How might I further debug this?
The link you posted is correct, but I wouldn't use their fix, I would just disable the Mage_Rss module.
Mage_Rss has several observers in it that call Mage::app()->cleanCache(...) in the checkout process, which is extremely expensive if your installation is using the default filesystem cache and it's gotten large.
I found the best thing for troubleshooting Magento performance problems is to wire up Xhgui and do some profiling. Reading call stacks will help your understanding of Magento immensely also.
Oh, and I don't know if this is true for Sagepay, but I went and fixed this problem completely for PayflowPro by rewriting the method that generates transaction IDs to use the quoteID instead of generating unique IDs on every invocation. I started down the path of committing this back, but I'm on 1.4.2 still and don't have time to test in later versions and it's a pretty significant rewrite. Guess I could just put it out there for someone else to run pass Moses...
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
on larger projects i use a simple bug tracking system that's designed to be used by clients
i have a lot of trouble convincing clients to use it (they send bug reports via email)
does anyone have any strategies they can suggested?
also, i have been playing around with a theory as to why this is the case; it goes like this:
asking a client to log a bug is like taking your car to a mechanic for a service, and the mechanic hands you the engine oil and says "here, pop that in". basically, the client has paid you to do the work, logging a bug sounds too much like work, so they want you to do it
thoughts?
A clear, concise bug report, not attached to a refund request, is about the best thing that can happen to your development effort, no matter what format it arrives in. Free QA, dude! Why would you want to hinder that process by making the customer jump through hoops to learn your bug tracking interface? Even if they're also in the software industry, maybe they come from a Bugzilla shop instead of a Fogbugz shop...
First, make sure your tracking system is very user friendly.
It has to be easy to access. Does your client have to go to a web page to file a bug? Is the application buried deep in the sitemap? Nobody is going to open a browser, find your site and go through numerous links just to file a bug. This can be solved by putting a link in your application (again, it has to be easy to find; like Help > Report a bug). If your client has more then one application, make sure he is directed to correct page (or pre-fill the needed fields).
Next, do not require of your client to classify the bug (like severity and whether it is in fact a bug or a feature request). Also keep number of fields low. Description and a screenshot is plenty.
Make your controls easy to use. Nothing is more frustrating like having to wrestle a datetime picker with three drop-downs when you are trying to get some work done (and of course if you select day 31 and then April, day gets reset to blank value).
If you expect a screenshot, give your client a nice silverlight control, where he can just drop the file instead of searching it all over his disk.
When your bug filler is customized so your own mother can use it, you'll still have to push a bit. Try to "forget" about the email sometime and when the call comes act surprised and ensure your client that you received no bug report from him. Of course when he insists that he did send it to your email, have an "ah" moment and inform him your email is acting "strange" lately, then ask him to resend the email. Next bug report will be filled right.
Fogbugz... I asked my clients to open a case about their bug and i then worked on it... Its really worth a try..
I second the recommendation of FogBugz. Most bug tracking software is a nuisance (I'm looking at you Bugzilla). It's just too perceived as too difficult to learn / navigate by my clients.
FB lets you have a public submission page for submitting new bugs. This is a very simple page that your clients could learn easily.
FB also lets you receive e-mails directly into the bug tracking system. As the admin, you categorize / assign incoming e-mail. Then, your client could optionally be notified when the bug is fixed.
One last plug for FB: There is a bug submission tool which lets you send a screen shot from a machine along with a bug description. This has been handy for my clients as well.
The final advise is this: Stop fixing any bugs that are not in the bug tracker. Of course you will get push-back, but not as much as you might think. If you are responsive to bugs / feature requests that are entered in to the tracking system, your clients will begin to see value. But, like little kids, they will not change if they can still get what they want by just fussing a little.
IMHO I think it depends on what type of client it is, if you work as a freelancer for small companies then I think a excel spreadsheet filled by yourself is enough to use as a bug tracking system.
You probably need to point out the advantages of the bug tracking system for the customer like easier for them to see the status of the bug, prompts for mandatory information like version number etc.
Above all the argument that if they use the system their bugs will be processed faster usually does the trick.
Set up your email server to bounce emails with the word 'bug' in it. Have the bounce report contain a link to your logging site.
(Or in reality, get a bug tracking software that allows bugs to be 'emailed' in).
You assert that your bug-tracking system is designed to be used by clients, yet clients won't use it. Could be something wrong with the clients, could be something wrong with the bug-tracking system.
I've always liked rt because it does have about the simplest, email-based user interface for clients.
However, I'm not suggesting that you change your bug-tracking system. What I would suggest is that you discuss the situation with some of your more friendly clients and see if you can figure out why they don't use it -- sure you've got a theory (some thoughts in your head) but do you have any data (some of the thoughts in their heads) ?
Then change to rt :-)
That last bit was a joke, what I should have written was -- then when you know what the problem really is, you can think about fixing it. Changing from system X to system Y without discussing the situation with your clients would be folly.
Even more foolish would be to start getting all snotty with your clients and bouncing back their bugs because they haven't filled out the right forms (as some have suggested). Unless that is, you are working in a secret orchard where paying clients are waiting to be plucked ripe from the tree.
If they're sending their bug reports to you by email instead of using the bug tracking system, give them the email address of the bug tracking system! Of course you would have to implement the feature but it would be novel to parse the email for inclusion.
If the email is in the wrong format the bug tracker will email them back with a template that contains the correct layout for them to fill in along with the original text they sent to cut and paste accordingly.
If they still send the email to you, forward it to the bug tracking system and when you get the reply with a template, forward that info back to the client and tell them the system won't accept it. This is still a bit of a manual process but you will be training the client at the same time on the medium they prefer and they're still doing the majority of the work.
Automated Return email might look like:
From: Bug Tracker
Date: 25/3/2010
Subject:
Please
reformat your bug report: [original
subject line]
Name: {Your Name here}
Priority: {Number here from 1 to 3}
Report below
this line (when done, email to bugtacker#example.com. Thanks!
{ your original text }
Go for a House M.D. style approach:tell them straight on that you're not reading any emails concerning bug reports, they go straight to Spam folder. You've got, however, this nifty interface for logging bugs, and by using that they're making sure that you'll get to see them.
Situation: Google has indexed a page in a forum. The thread is now deleted. How/whether can I make Google and other search engines to delete the cached copy? I doubt they would have anything against that since the linked page does not exist anymore and keeping the index updated and valid should be in their best interests.
Is this possible or do I have to wait months for an index update? Or will the page now stay there forever?
I am not the owner of the respective site so I can't change robots.txt for example. I would like to force the update as the "third party".
I also noticed that a new page on that resource I created two days ago is already in the cache. Given that can I make an estimate how long will it take for a non valid page on this domain to be dropped?
EDIT: So I did the test. It took google shortly under 2 months to drop the page. Quite a long time...
It's damn near impossible to get it removed - however replacing the page with entirely blank content will ensure that you nuke the ranking of the page when it is respidered.
You can't really make Google delete anything, except perhaps in extreme circumstances. You can adjust your robots.txt file to promote a revisit interval that might update things sooner, but if it is a low traffic site, you might not get a revisit very soon.
EDIT:
Since you are not the site-owner, you can modify the meta tags on the page with "revisit-after" tags as discussed here.
You cant make search engines to remove the link but don't worry soon the link will be removed as the link will not longer be active. You need not wait for months for this to happen.
If your site is registered with Google Webmaster, you can request to remove pages from the index. It works, I tried and used it in the past.
EDIT: Since you are not the owner, I am afraid that this solution would not work.