I have been trying to get my Magento site to take some changes but it is still not refreshing the changes. I have disabled caching and flushed all of them on every single occasion I have also cleared my browser cache and it still does not take changes. I have gone as far to delete several files from the server that the theme relies on but it still functions like nothing was ever removed! What could be my issue?
You keep editing those files. I do not think those files are the files you think they are.
You question is pretty short on details, but my first guess if your system is running with the compiler enabled, which means it's loading its class files from
includes/src
Googling around to learn about the compiler would be a good idea.
I'd try adding the following to the end of your index.php file
echo '<--';
print_r(get_included_files());
echo '-->';
This will list every file PHP used during the request. Compare the full paths with the ones you're editing, and I bet you'll find a discrepancy.
Related
I don't know exactly why my drupal 7 website became suddenly slow last week, after few days in production.
With xhprof, i see that at each page load,the system_list_reset() function triggers a call to cache_clear_all() function.
I deactivated all cache features.
I've read that it may due to missing files in modules and/or themes, but I didn't find missing files (except a wrong issue in 'missing module message fixer' module that indicates a missing module in view_export sub-module of view module).
I manually searched them , I didn't find where drupal can list these missing files.
Or maybe it's due to another problem.
Regards,
Open page inspector of your browser and in network tab check what files have unusually long loading time. It maybe be that some external service is causing this. Also it can be that your site is hacked...
Check most banal reason, the storage space - maybe disc of your server is full?
Check if file paths drupal is using are writable. Go to Configuration -> Median -> File system and just click Save. If some path is not writable it will get red outline.
Go to Reports -> Recent log message and check if some issue is maybe logged there. Also check for web server/php logs.
Try updating modules and drupal core - maybe some bug caused that and it's hopefully fixed in module update.
If not, try disabling modules one by one and see will that still happen. If you don't find problematic module try the same method with your theme. Would be good not to try this in production development and/or make backup before doing this.
thanks a lot,
by disabling module one by one, and by "datamining" in drupal DB, i've found that ADVAGG module was guilty.
The clean was difficult, because some entires remains in some tables of Drupal DB afther the module removing, but I hope it Ok.
BEWARE OF ADVAGG MODULE !
Funny :-/ with 'top', I've found a mining soft in /var/tmp/
systemd-private-a5422b1e6694466bbb0b63203573cad1-apache2.service-jMBN4U : nullcrew (from https://github.com/xmrig/xmrig)
I will investigate how it could land on my webserver
Best regards,
A relative asked me to fixed a Joomla website (v2.5.16) who has been hacked last year, probably due to lack of update (is up to date now), unfortunately I have no information about this. The issue is that the front end take 2~ min to load. The administration is loading normally so whatever the issue is, it depend of the front end. I already disabled all modules one by one and switched the template with another one to make sure that thebug is not in template or plugins folders, without success.
I must add that the problem is "probably" more recent than the hack, according to this person. So maybe there was a script somewhere reaching a random server which may not work anymore.
PS : the website is on a shared hosting. I have the FTP access but no ssh.
I know that I don't give any details which can lead to resolve this, but I need more a method to track what can go wrong and where than a solution.
Thanks in advance,
We have written a lengthy post explaining why a website might be slow: http://www.itoctopus.com/20-questions-you-should-be-asking-yourself-if-your-joomla-website-is-slow
From the looks of it, it might that the website is still hacked. Try overwriting the Joomla files with a fresh Joomla install and see if that addresses the problem.
Solving this issue will probably involve some or all of the following:
updating Joomla and all third party extensions to the latest versions
checking for and fixing malicious files using http://myjoomla.com or
https://sucuri.net or similar
analysing the performance of the website using http://gtmetrix.com
(it's free) or similar to pinpoint and fix what is taking the most time to
load
If the website has been hacked, you may need to reset passwords etc once the malicious files have been removed. See https://joomla.stackexchange.com/a/180/120 for more information about securing the website once it is fixed.
I'm very new to Typo3 and am struggling with a few cached images that refuse to update.
There has to be a option to deactivate all caching somewhere, and to flush everything. I need to know how.
What I have been expecting to find was one button that fixes it all. What I actually found was the following:
The directory /fileadmin/_processed_ contains resized images that the website creates and stores for later reuse, deleting the folder's content prompts the website to recreate everything from scratch, thus reflecting any changes to the original images that are stored elsewhere.
The directory /typo3temp/ runs a similar role like the one mentioned above, it contains semitemporary data from some installed extensions (unlike above not limited to image files). If a particular extension is causing trouble you might find (and empty) it's cache in this directory
/typo3temp/Cache appears to be of interest.
The Install tool accesible from the backend provides a few useful functions, most notably the clear all cache found under the tab important functions.
Furthermore there is a tab clean up which allow clearing cache_imagesizes, cache_md5params, cache_typo3temp_log amongst some other things that don't seem to be of greater interest.
I had the same problem when I switched to TYPO3 6.0
It was caused by the FAL (file abstraction layer).
The only way, displaying a newer verion of the picture was to rename it such like:
oldpicture = _picture
newpicture = oldpicture
Can any one know what this file is about? http://www.symbios.pk/x.dep.PIE.htc? Is it safe to keep on server? I've never seen such before and this is one of highest accesses pages on my site.
At a fast glance, this looks safe and appears to stem from a CSS3 compatibility layer: CSS3 PIE. If you are worried, you can always re-download the file from the website and re-add it, but I would keep a backup first in case of any version incompatibilities.
The file on your web server doesn't match Beta 1.0.0's PIE.htc exactly but it is rather similar and it also already good to know that a .htc file does indeed come from CSS3 PIE. The extension of a file obviously doesn't say much about its contents but it's still reassuring to see that it is an expected file ending. (I've never encountered an .htc file before, so this raised some concerns for me.)
As for it being visited a lot, this doesn't have to mean anything. Possibly the file is being checked out by bots or someone is hotlinking your JS file; it's hard to say without context but if it's a JavaScript file from some framework you should be fine. The good news here is that this is JavaScript, so it can't compromise your server (but it could attack a browser loading the file).
If all else fails and you know where your pages use this file, you could try renaming the file so anyone hotlinking or just guessing for the existence of the file would have a tougher time. I don't really understand why someone would take interest in a small JavaScript file, though.
Interestingly, visiting your main page at symbios.pk doesn't load the file, though. Maybe some back-end module? If multiple people are working on the website, I would suggest asking all of the developers if they know about this file. It would be interesting to compare the creation date with that of similar files.
I have a bit of bad habbit, I install joomla on xampp and test all extensions and things im planning to add on the website there. Then I go to live website and try to start it from scratch, but it get very confusing and stressing this way..
I am thinking of just uploading the xampp joomla site to a live server but I am worried about these things:
I have installed/uninstalled some extensions (10+) do these leave behind any corrupted files in general or cause any problems?
Any tips cause im really worried now, the website has grown a lot and I cant start it from start even looking at the notes I took while making it. Uninstalled extensions do they leave any files behind or cause any problems? Right now the website works good on XAMPP.
Any tips or suggestions greatly appreciated,
Ammy
Most extensions uninstall fairly cleanly. You can be sure by using an FTP client and looking under /components, /plugins, and /modules (and/or their counterparts under /administrator) for leftover directories with the extension's name. You can also use PHPMyAdmin or somesuch to look for leftover database tables with similar names.
Even if files and tables are left behind, they're unlikely to cause problems with the site. I understand the desire to keep a tidy codebase, but that's not a good reason to build a site twice.
Most extensions delete their files on an uninstall. This is because Joomla does this job itself, the extension doesn't have to do anything for this to work.
However the tables are a different beast. While it would be very easy for extensions to delete their tables on uninstall, there are different ideas about this. Some argue that they don't want to be responsible for deleted data and thus leave the tables behind.
Also entries in the assets, categories, tags mappings and menu tables are likely to be lying around after an uninstall. Most extensions will not clean those tables up during uninstall.
There may also be leftovers in files, if the extension used some library like fof or similar. There is no ckeck if the uninstalled extension was the last one that used that library. So you need to uninstall those manually, but you need to know if it's used or not.
The leftover tables and entries don't generate any problems except for a bit more memory usage. However a leftover library may be a huge security issue as it may contain a bug which could be abused. Since no extension is using it anymore, it will never get updated and the bug doesn't get fixed.