I'm going to migrate the site http://www.thetrekkr.com (from a friend) to another server. The current server does have problems, until I migrate the domain I made a subdomain which is http://www.thetrekkr.pd-design.at. Everything works except the themes (Avada) icons - this must be font-awesome-icons. The icons are working in Edge but not in FF, Chrome, Opera.
I tried the following ways to fix the problems:
Change the links in the database to the new subdomain (plugin better search replace)
adding a .htaccess file to load the icons (https://theme-fusion.com/knowledgebase/are-your-font-awesome-icons-or-custom-fonts-not-showing-up/)
adding the following code in the functions.php to load stylesheets or scripts (WordPress site migration - icons missing)
changing many times from www without www etc.
deleting browser cache, trying on more devices
Unfortunately nothing helps.
Update
I notice I am getting these errors in my network tab. Are they a problem?
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://www.thetrekkr.com/wp-content/themes/Avada/includes/lib/assets/fonts/icomoon/icomoon.woff. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://www.thetrekkr.com/wp-content/themes/Avada/includes/lib/assets/fonts/icomoon/icomoon.ttf. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
I had the same problem but the solution I found was simple in the end.
Go to theme options -> advanced -> dynamic css/js and then disable file caching, that worked for me. You can also reset the cache on this page.
Thanks
Jamie
I had a similar problem, This is How I fixed missing awesome fonts after migration
I migrated my client's website from MAMP to hostgator using all in one migration but after the migration, all of the avada awesome font wouldn't show (front end and back end) after hours of trying to fix I finally found a solution.
Within the wordpress theme dashboard navigated to > Theme options > Advanced > Theme features > FontAwesome then re-selected every font awesome option then hit save.
I could now select all the font again :)
It looks like you have a hardwired domain in your temporary site. The errors are an attempt to load assets from one site into another, and unless the remote site permits that explicitly, the browser will disallow it for security reasons. As the error indicates, if you wanted this configuration long-term, you can get the remote to allow it using the Access-Control-Allow-Origin header.
However, since this configuration is an accident of using two domains, it would be better to modify your site code to get these fonts to load from a relative path starting from /, rather than referencing the domain explicitly.
Go to Avada > Options > Advanced > Theme Features and check if the Font Awesome v4 Compatibility option is turned On. If not, turn it on and click Save Changes. And If it's already on then turn it off and turn it on again then click save changes.
Related
I am rather new to TYPO3. Recently I noticed some very weird behavior in my installation: Some CSS-files in the directory typo3temp/assets/compressed got the MIME-type text/html instead of the expected text/css. Therefore my browser received a 403 Forbidden status code from the webserver for these resources. That resulted in some parts of the backend being shown without styling.
I tried clearing all caches and deleting the typo3temp/assets/compressed directory, however now all the stuff in there (CSS and JS) is served with MIME-type text/html. Getting the backend without JavaScript means, that I am now basically locked out of the backend. I can however still reach and use the install tool.
Do you have any ideas how this might happen and how to fix it?
Some details of my setup:
TYPO3 v10.4.13 (recently updated from 10.4.9)
Apache web server (I don't have access to its config and have to rely on .htaccess files)
I suggest to set
TYPO3_CONF_VARS/FE/compressionLevel=0
TYPO3_CONF_VARS/BE/compressionLevel=0
in order not have these kind of problems. The problem is that this compression creates compressed files but relies on webserver configuration in order to deliver them as text/css and NOT applying the default webserver's transport compression to them (or they could end up double-compressed and you might not even easily notice - some browsers can deal with that, others not).
It is a kind of micro-optimization that sounded useful in times when we avoided https:// because of the processing overhead...
Here's some docs (the first statement is outdated in my oppinion): https://docs.typo3.org/m/typo3/reference-skinning/master/en-us/BackendCssApi/CssCompression/Index.html
After an installing a new SSL certificate and changing the PHP version from 5.x to 7.1.28 product images are not shown in the frontend anymore, Chrome dev tools show a 404 error for the image files.
They are visible in the backend under product catalog.
It looks like if the image directory is missing, i.e. something like /home-default/ because in the HTML code the image file is supposed to be directly on the document root directory, which obviously is wrong.
When I switch off "Friendly URL" the images are shown.
What I tried so far:
Deleted .htaccess, switched Friendly URL to on to regenerate the .htaccess
Emptied cache and regenerated the image thumbnails
Switched back to PHP 5.4
Added AllowOverride All to the vhost config
Nothing helps. On the server is another PrestaShop installation, running same PrestaShop version 1.6.18 also under PHP 7.1.28, there the "Friendly URL" works fine.
I must say I have no clue where to look after this problem.
After spending some time with #Harry, debugging his configuration, we found the solution and I'm sure this will help many others.
#Harry was using a combo with Nginx + Apache.
We checked his PrestaShop .htaccess file and made sure RewriteEngine was on and triggered properly (e.g. the pages were properly rewrited, only the images were not) - everything was OK.
We tried to write ourselves a basic RewriteRule to redirect a .jpg and it did not work, showing an Nginx 404 page.
We came to the conclusion Nginx was handling all the static content (JS, CSS, JPEG, etc.) and not forwarding it to Apache.
Solution
We removed this part from the Nginx configuration:
location ~ ^/(.*\.(ac3|avi|bmp|bz2|cue|dat|doc|docx|dts|eot|exe|flv|gz|htm|html|img|iso|jpeg|mkv|mp3|mp4|mpeg|mpg|ogg|ppt|pptx|qt|rar|rm|swf|tar|tgz|ttf|txt|wav|xls|xlsx|zip))$ {
try_files $uri #fallback;
}
As a general advice, I would suggest not using Apache+Nginx, PrestaShop works very well with Nginx+PHP-FPM already and you will get great performances.
If you choose this solution, don't forget to set your PrestaShop rewrite rules directly in Nginx (Example).
I've got to transfer a website from an hoster to another (MelbourneIT).
So I've done as usual with my favorite FileZilla, just copy the html website (without DB) to the other url.
So this one work for the first page ( http://www.lmhceramics.com/) because it's an html one but all my other pages doesn't work!
I've check the folders of my website and I found that this one worked with "Smarty" who is apparently a third party application.
I tried for 5 hours different things as : create an .htaccess to launch index.php instead of index.html, change the configuration on my site_globals.php but it didn't work. It looks like only the first page : index.html is loading.
I can give the access to the ftp if anyone could help it will be sweet as it's one website of my company!
Thanks guys.
Cheers
Initially I tested whether PHP was working, then when I was sure I looked at the error log. The overriding issue was a required library not being found because of a broken path, and PHP's display_errors setting was disabled so it resulted in a white screen.
The site main pages now function.
In site_globals.php, there were two paths that begun with a forward slash. This results in the code looking in the root directory of the server for a particular folder of files (the Smarty library, and the Smarty templates), which likely worked on the old server but not on the new shared hosting environment. New code italicised:
define( "SMARTYPATH", _$_SERVER['DOCUMENT_ROOT'] ._ "/deldridge_smarty/" );
define( "TEMPLATEPATH", _$_SERVER['DOCUMENT_ROOT'] ._ '/smarty/' );
Once that was fixed the code library and templates could be loaded and the rest of the configuration file continued to load. It then dies on:
$db_interface = new DBInterface;
$db_interface->connect( '172.20.254.1' , 'ampnet', 'cable05' );
This is an attempt to connect to a database. I haven't investigated what the database was for yet (that'd require looking through the PHP files in depth) but I'm assuming it was the login system or some such. Almost all of the pages in the site function with those two lines commented out, which I've done for now so that the majority of the content is available again. There's another reference to database connection details further down but they were already commented out.
One other area of particular interest is this:
// different dir structure on secure domain, make ammends
// ensure trailing slash if directory present
define( "SECURE_DIR", 'buildersbollards/' );
if ( $_SERVER['DOCUMENT_ROOT'] == '/home/deldridge/secure.4mation.com.au' )
{
$site_path = '/' . SECURE_DIR;
}
Hop that helps!
It's difficult to know with so little information. Enable error reporting in php or just look at the php error log in your server. One probable cause for the error 500 may be that some key folders don't have CHMOD permission to write; In smarty, for example, templates_c must be writable
At moving from local to a server my prestashop web, appears all the text (I think it connects correctly to the database), but it doesn´t visualizing any images,CSS,etc... I´ve modified config/settings.inc.php file
and modified PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL and SHOP_URL from the database and also deleted the .htaccess file.
Thanks!
The same is with the backoffice:
you can do it by two ways:
navigate into backoffice to SEO&URL link, set correct values for Shop domain & SSL domain & Base URI fields. Save & update page.
or
in DB find tables:
ps_configuration, set correct values for PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL
ps_shop_url set correct values for domain, domain_ssl, physical_uri
Some Prestashop installs, sometimes have SSL ON (don't know why).
If you are installing it on a server with no SSL certificate, all images and styles will not be loaded and the PHP scripts display barebones HTML pages.
To solve this:
In your Prestashop directory, delete all install directories and files to get the platform running.
Type your admin URL, example: http://yourstore.me/psadmin, log in with a registered valid admin user, and go to to PREFERENCES->CONFIGURATION and turn all SSL parameters to off.
I have a folder for customer avatar upload and I set up an apache server pointing to this folder to get customer avatar images.
It seem to be a very strange symptom my system get right now as following:
I update an avatar image in the folder
I access to the image by browser, but I see it displays the old one on browser though I refresh (Ctrl+F5) many times.
After a time duration (nearly 1 min), I refresh the above url, and I got the lastest image dislayed.
Is this symptom relating to my Apache configuration? Could anyone help me to figure out which setting affects? Thank you!
First of all I am guessing that you have not enabled any of the apache caching modules. If this is the case then this behavior is due to browser's caching on the client side. You can verify this by opening the url in a browser's private session after updating the image. You can also verify by looking into apache's access.log file and check if you can see any request entry for accessing the image or not. If it's not then it is being directly served from browser's cache.