magento 1.7
onepage checkout stuck after choosing a payment method. I have found a few solutions but none work. I don't really want to mess with the .js files unless it's a proper fix. seemed to work fine a few days back. No extensions installed since then.
Weinwerk Klimascout: Click here to view the site. Thanks in advance!!!
So I encountered the same problem (also with 1.7.0.2). It sneaked in after I added a number of custom modules.
After a day or so of trying just about everything I could think of, I found a rather simple solution: I had accidentally deleted some of the directories from the "skin\frontend\base\default" directory
In particular, check to make sure there are no issues with the files in the "default\js" directory. The "opcheckout.js" file controls the advance process in onepage checkout.
I ended up reinstalling all the subdirectories "skin\frontend \base\default" and this did the trick.
(Just to confirm, once fixed, rename the file to opcheckout.js.bak and the continue button will revert to no- working state).
I’m sure there are many other possible reasons for this bug. jquery.noconflict() and billing.phtml and are worth a look. For others who might be new to magento, the debugging steps here are a lifesaver.
https://magento.stackexchange.com/questions/428/fundamentals-for-debugging-a-magento-store
Related
Every time I look for a file using the files finder console the file does not show up as a result of the search despite its existence in the project.
At certain point this feature was working but I may have change some configuration in Rubymine involuntary. Any help it's welcome!
That's a known issue already fixed: https://youtrack.jetbrains.com/issue/IDEA-266391
Builds with the fix will be added to that issue so you can follow it.
As a workaround, please try invoking File - Invalidate Caches (still the issue might come back).
I have had this problem as seen in the title in the past and I always resolved this issue by adding the psr-4 autoloader in the emconf and simply reactivate my extensions.
Now I'm facing the same problem:
Could not analyse class: maybe not loaded or no autoloader?
but I have set the autoloader correctly as always. This also happens in more than one Extension right now.. After deleting the php cache in the install tool und dump autoload and reactivating my extension, the error was gone for some time, a couple hours later its back again.. Therefore I think it must have something to do with temp files, but I can't figure out what it is exactly..
Does anyone have a solution? I have seen plenty of topics about this issue on stackoverflow, I used them in the past, but unfortunately none is working for me right now.
Important fact: This error is happening on my new server now. On my old server (with the same code in the extensions) this didn't occur and they worked fine.
Thanks in advance.
Edit: Vendornames etc. are set correctly and there are no errors in the syntax whatsoever. As I said, the extensions worked fine.
Edit2: I just found this changelog of Typo3:
https://docs.typo3.org/typo3cms/extensions/core/Changelog/8.4/Breaking-78222-ExtensionAutoloadInformationIsNowInTypo3confautoload.html
But there is no solution for the impact for none composer installations. Can someone provide one for me?
When you use composer installation and you use extensions which are not installed via composer, you need to add the autoload information in the root composer.json of your project and then run composer dump-autoload. (ext_emconf.php dont works in composer mode?)
{
...
"autoload": {
"psr-4": {
"Vendor\\ExtensionNameA\\": "public/typo3conf/ext/extension_name_a/Classes",
"Vendor\\ExtensionNameB\\": "public/typo3conf/ext/extension_name_b/Classes"
}
}
}
A possible explanation for strange timing thing "works and later not". Maybe it has something to do with the red clear cache button in the TYPO3 backend (Clear all caches). Maybe it start not working when u hit this button and cache files get cleared. Then you need to reinstall extensions to get the autoloader "temporarly" working, till the point you hit the clear all caches button again. With the solution i mentioned above, it works permanet.
Have you left any configuration in your ext_tables.php?
As the TCA configuration, which is cached, is expected in Configuration/TCA/[Override/] any code in ext_tables.php might get lost.
If you want some configuration to be executed for each run you need to put it in ext_localconf.php
Thanks for all the help, I found the solution myself now.
Actually it was not really caused by any autoloader configuration, but and old version of fpdf which apparently caused two extensions to not load their classes properly. The exception thrown was simply misleading. I have upgraded the version of fpdf and now it works properly. It is not clear to me why the same code worked a week ago and now it failed, but atleast I have found the solution to my problem.
I have a selfmade T3-plugin that actually works fine.
Unless I try to look at it in the draft-workspace - then I get an error saying «Template could not be found at "typo3/sysext/workspaces/Resources/Private/Templates/Preview/Preview.html"» (of course, the template is there).
We're working with T3 6.1.8
There were some rollbacks made recently that might have caused this, but that's just a wild guess...
Any ideas what could cause this?
The solution to this was actually quite trivial.
The person who wrote the extension used chdir() in the extension's header to write a PDF file. This confused the workspaces plugin so it didn't find it's own directory anymore.
My site eighttwentydesign is running Joomla 3.0. I have SEF URLs on, and have done for sometime without issue. But today when you go to the site, and click on anything, say portfolio you get the home page under the portfolio's URL, but if you add a leading slash at the end, the right article (portfolio) shows. Additionally, if you click on say "Web Design" it sends you to the Portfolio page. I might add this menu is a menu within Joomla - not be adding internal links manually
Doesn't work: http://www.eighttwentydesign.com/portfolio
Does work: http://www.eighttwentydesign.com/portfolio/
I have checked the .htaccess, and actually reverted it to the original with no luck, I have check Global Config but I can't see anything which may cause this. It was working nicely yesterday. I haven't adapted with any PHP source or anything in the past few weeks, the only notifiable thing I have done is yesterday enabling the Cache - have others experienced problems after doing this? I have disabled it under global config, with no avail.
Exact Joomla Version is 3.0.2 with very few plugins
I do have daily backups, but would rather a solution and be able to figure out a prevention from that, rather than just putting on a band aid.
I've search for a good couple of hours, and aside from just not being able to fix it, it appears no one else is experiencing this, so I am starting to think it may be a bug.
Just as I was about to post this I discovered my solution.
If you are having your SEF URLs display the wrong content then solve it by disabling the Cache plugin. You can do this by doing the following steps
Login to Joomla backend
Navigate to Extensions > Plugins
Go to "System Cache"
Disable system cache
I hope this helps someone in the future as I really struggled to find any answers on this.
When I update my local working copy of an SVN repository in Eclipse using the Subversive plugin it isnt bringing any new files which have been added to the SVN repository. It thinks that the local working copy is up to date and if I ask Eclipse to update it it just says no further changes.
Anyone got any ideas why this is happening?
I just discovered this nasty problem too. It might be related to this bug report.
Deleting the entire tree worked for me too, but that hardly seems like a satisfactory solution. What scares me more is wondering how I will notice that a certain file didn't get updated, if this happens again.
Thanks to the above bug report, this worked for me (eclipse 3.7):
Team/Update to Version...
v Update to HEAD revision (=default)
Depth: Full recursive (default is Working copy)
v Change working copy to specified depth (default is un-checked)
O Ignore externals (=default)
v Allow unversioned obstructs (=default)
I do not know if that fixes the problem permanently. At least it seems a faster solution rather than full checkout.
Sorry I don't have a solution to this problem, but I have it as well, and I don't have enough cred to comment.
Here is a thread describing the same issue:
http://www.eclipse.org/forums/index.php?t=msg&th=14710&start=0&
A "workaround" I found to be successful is deleting the relevant tree (of course, backing it up first) and performing an "update". I am prompted to recreate missing files, which bring the un-added files from the repo as well. Obviously this is a terrible solution, but it does work.
Another interesting effect to note is that it is one-sided. The other machine on the repo is perfectly fine with updating new files.
I have noticed Subversive to be a bit problematic. While this isn't a direct solution to your problem, may I recommend using TortoiseSVN (assuming you're in Windows). It works excellently, has more power than Subversive, and is integrated with your shell making it a smooth transition.