I'm running the latest version of WordPress (3.5.1), hostet with Strato and since yesterday some of my plugins are not getting the correct path to their files.
UPDATE: It's not a Multisite!
All files are still on the server and haven't been changed or updated since friday (at this point the site was live without issues). The problem is that the plugins are looking at some kind of internal path which looks something like this: website/wp-content/plugins/xxx/xxx/xx/xx/123456789/htdocs/website/wp-content/plugins/akismet/akismet.css so all I get is an error 404 (Not Found)
I cannot locate the problem and I'm not getting any PHP errors or anything like that; only the paths are broken... the plugins are even working, but without images, css and scripts!
Therefore I've deactivated all of the plugins but as soon as I activate them again, I'm running into the same problem.
And finally I've already contacted the provider, but they cannot help at all because it seems to be a problem within WordPress.
UPDATE: I've completely removed all of the plugins, but even if I now download and activate a new plugin the path is broken as mentioned above...
UPDATE2: The wrong path looks like this:
domain.com/wp-content/plugins/mnt/web1/a1/12/123456789/htdocs/
/website/wp-content/plugins/akismet/akismet.css
instead of domain.com/wp-content/plugins/akismet/akismet.css
(actually the second version of the path is working, but all of the plugins are calling the first version, even if completely new installed)
UPDATE3: Sorry, I'm not able to go more into detail, because I've no clue what's going wrong, so I'm giving it a try from another perspective: everything is working fine, with the exception of the plugins. The plugins are even displayed in the frontend, but without any CSS, JavaScript or images. The same thing happens in the backend. I can see all of the plugins and manage (install, edit, configure,...) them, but there is no styling. Everything in case of the design seems to call a wrong path. In doing so the first part of the path is okay, and also the last part, but in the middle there are numbers which should normally not be displayed within a frontend path because they are a part of the Strato server root directory.
It seems your the WP_CONTENT_URL is not correct.
This is defined as in ./wp-includes/default-constants.php:
define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');
So check your settings > general > WordPress Address (URL)
You can also try to define the correct WP_CONTENT_URL in your wp-config.php:
define( 'WP_CONTENT_URL', 'http://www.yourdomain.com/wp-content');
When the above don't help check your .htaccess. Maybe wp-content/ is rewrite to the fullpath.
Related
I hope this is a quick fix, but I've been searching for a solution and haven't found one.
Quick background:
I've been developing my Wordpress website locally using WAMP. I'm getting the site ready to deploy to a production server, and before deploying it I wanted to simply rename my theme folder from "naked-wordpress-master" to "My Portfolio" or something different.
First, I went to my theme folder and changed the name. I refreshed the Appearance > Themes page in the wp-admin site and got an error that the stylesheet could not be found.
I got a bit worried, so what I did next was rename the theme folder back to "naked-wordpress-master" and refresh the page. Same error.
I then tried deleting the theme from the wp-admin site and re-uploading it. I got an error the upload failed because the stylesheet couldn't be found.
FYI I'm using SCSS that outputs a style.min.css, but that shouldn't matter. I didn't change anything else from the header, functions.php, or stylesheet linking and it was all working just fine before.
Any ideas on what's going wrong and why my stlyesheet is failing to get recognized?
Thanks a bunch.
--Update--
I'm noticing my index.php loads fine, but sub-pages look like this
In your database find the "_options table (table prefix could be what ever you have set while installing wordpress). In options table, find the entries for "template" and "stylesheet" (both are different entries) and check their corresponding values. If that is not your theme name, change it manually to your theme name.
Also, make sure your theme has style.css at its root location. That's a technical requirement for enabling the theme.
After Update
Seems like its a rewrite issue. Check if the .htaccess file exists.
If it doesn't, in admin are, go to settings->permalinks, change the permalinks settings to something different, save the settings and revert back to what ever you had set before. (Ideally you should select the "post name" setting, which generates pretty permalinks which are also SEO friendly)
This will flush the permalink rules and also create the .htaccess file if its missing.
Hope this helps.
I've a problem with my wordpress website. When I insert some url for being embedded, it's not working fine.
Here is the issue URL : https://www.duosia.id/windows/cara-mengekstrak-files-menggunakan-winrar-dengan-mudah
And here is the Screenshot :
When I try to visit the embedded url. It's return 404 not found. You can check the embedded url here, https://www.duosia.id/windows/cara-mengekstrak-files-menggunakan-winrar-dengan-mudah/embed/
I've try these common solutions.
Update everything including WordPress, the theme and plugins. Available updates appear in Dashboard > Updates.
Deactivate all plugins in case there is a conflict. If the problem goes away while all plugins are inactive, then reactivate them one by one to determine which is causing the problem.
Switch to the default theme (such as Twenty Thirteen) then try to do what was not working. If the problem remains, it is a general WordPress or hosting issue. If it happens only while using our theme, please let us know.
Clear cache in both your browser and in any caching plugins that you are using (also disable services like CloudFlare, if used with your website).
Revert code changes if you have modified the theme’s code. If using a child theme, reactivate the parent theme.
But, seems no one work.
The WordPress post embeds don't seem to be working on your site.
This URL shows a live example of the problem:
https://www.duosia.id/windows/whatsapp-for-pc/
The two embeds present in that URL are returning a 404, therefore, oEmbeds are not loading properly and showing the 404 page:
https://www.duosia.id/windows/facebook-messenger-for-pc/embed/#?secret=kMPv636bx1
https://www.duosia.id/windows/line-for-pc/embed/#?secret=65m4VpxiYi
Have you tried testing those URLs in the plugin "Rewrite Rules Inspector"?
You should see something like this for any of the "embed" URLs:
index.php?name=$matches[1]&embed=true
Also, have you tried flushing the rewrite rules in WordPress or maybe setting the permalink structure to a different/default one (right now you seem to be using a structure of "category/post-name") to see if it changes anything?
For the file that you are embedding, are you uploading it to the Media Library or some other plugin?
First I would check on the server to verify that the file you are looking to access does exist.
Once you know that the file does exist, then repeat the steps you have listed again.
i just:
moved a remote wp network installation to local (mamp). everything fine.
installed a new theme. everything fine.
activated the new theme. doh!
i started going through the code and i found that it doesn't fix it, but at least i got a nice-relaxing-blank-white-page, if i remove the *do_action( 'init' );* from wp-settings.php.
i googled a while and i found that "*Your problem is probably wp_cron being called by init. In 2.1 and up, the cron process is called externally, so one thing that could be your problem is the DNS resolution not working on your webserver to find its own address.*"… i don't know if this could be the right answer to my issue, what am i supposed to do to fix it all?
ty!
To determine what the actual error is, you will want to turn on debugging. To do this, add the following line to your wp-config.php file:
define('WP_DEBUG', true);
It should then start spitting out lots of textual data as to what the error is. In all likelihood, it is a PHP error due to a coding issue (bad function call, missing end tag, etc.) in the new theme, or a difference in configuration between your live site and MAMP setup.
For more info on WordPress debugging, see http://codex.wordpress.org/Debugging_in_WordPress.
This is a weird one. I googled for hours but seems to me not a single person has this same issue.
I moved my website from http://www.domain1.com/wpfolder to http://www.domain2.com . Everything works fine except I cannot get the "wp-login.php?redirect_to" path to point to the correct url.
WordPress keeps setting it to:
"wp-login.php?redirect_to=http://www.domain2.com/wpfolder/wp-admin&reauth=1"
It should be setting it to:
"wp-login.php?redirect_to=http://www.domain2.com/wp-admin&reauth=1"
The "wpfolder" doesn't exist anymore..
I followed the instructions exactly on how to move a WordPress website, but the darn URL won't change...
Some forum mentioned changing the "site_url" and "home" from "http://www.domain2.com" to "http://domain2.com". Now I can finally get to the admin panel, but I don't get why it needs to be that way?
I cleaned my browser cookies and checked the wp-content folder for cache already. Nada..
Also the rest of the site is functional.
I would appreciate if anyone can help.
I moved the WordPress website from GoDaddy to Bluehost by copying the files and the database and the problem went away. I am not sure why this fixed it, but assuming it has something do with the cache.
If anybody has more information, I would love to read about it.
Thanks
I was facing the same issue, with same redirection to one of the sub-directory in which wordpress was installed.
Resolved this issue, by clearing the cache, if some cache plugin is active.
Or by deleting the cache plugin if any present and is currently not yet active.
As some entries made by cache plugin inside wp-config.php file creates the above mentioned problem.
After removing the cache plugin, it resolves the WP-admin URL issues.
wordprees print_thumbnail function is working correctly on testing server but it's not working on online server and giving wrong image path such as */var/www/vhosts/vinehospitality.co.za/httpdocs//wp-content/uploads/2011/12/slide-10-108048_56x56.jpg*.
So kindly help me to get proper url.
Link of website: http://vinehospitality.co.za.plesk15.wadns.net
Same problem is found in hosted on this server.
Regards
Neeraj
Not only did it work, it was SO MUCH easier for me.
Simply, delete whatever custom link you have in Media Settings. If you don't have one just put anything there..
Then save, again, put back the original path you have before, save.
Worked!
Somehow it seems wordpress reads the wrong values when you move servers and you don't resave media settings.
POSSIBLE FIX 2
Look, I've seen this problem on other threads and on other websites and no one gave information that helped most of the people with this issue, so since I somehow got my broken site to work, perhaps it will help the others who did not get their problem solved.
Here's a little background... I needed to move a wordpress site located on a dev server to the live server. They were different domain names of course. First of all, I should have followed Moving Wordpress instructions and updated the site url before I exported the database, but... I didn't because I'm obviously too cool for instructions.
In order to transfer the site, I zipped up the files and transferred them to the new server and unzipped them. Then I edited wp-config and pointed it to the new database.
I used phpmyadmin to export the old database and I imported it to the new database.
Then I ran a query on the wp_posts table to do a string replace on the guid field and replace all instances of the old domain name with the new domain name.
Then I checked in wp_options and changed 2 records to replace the old domain name with the new one. I think they were something like siteurl and home.
Everything seemed to be working fine except the theme was mangling the img urls, prefixing them with the absolute filepath.
I figured I must have missed some records in the database that give the print_thumbnail function whatever information it needs to output the right url for the img's src attribute.
I thought if I could change a setting somewhere and change it back, maybe wordpress would automatically fix the issue for me, and I was lucky.
I played around with several settings and what finally worked was:
I went to Media Settings and I unchecked Organize my uploads into month- and year-based folders -- I don't know if this had much to do with the fix.
I also changed the Store uploads in this folder to something like wp-content/uploads2. I never created that folder, but I just wanted to get it to overwrite whatever was controlling that value.
I checked the site again and there was a change to the html source... now, it didn't even give the img tags a src value... it was just like <img src title="blah blah" />, so I figured I was on the right track.
So then I went back and changed Store uploads in this folder setting and left it blank as it was originally.
After I did that, the img src values were correct.
Hope this saves someone some time.
Also, I should note, I played around with altering the file permissions for the wp-content directory. I wish I hadn't. I get the gist of file permissions, but I tend to try not to fool with them if I don't have to. Using Filezilla is a pain to change the file permissions because it takes forever. Unfortunately, as most clients, this one had a prior affiliation with their web host and refused to take my advice and host their site on a VPS that would be cheaper and allow me to use SSH and get work done much easier. I wonder if there's a fast way to chmod multiple files without ssh, I should look into that.
Cheers,
Will
Will's approach fixed the error for me, and was in fact the only answer that worked. This question is posted hundreds of times, so I figured I'd summarize the answer in short. I'll post the answer first and the research details after.
Login to WordPress
Goto Settings > Media
In "Uploading Files", modify the "Store uploads in this folder" to "http://www.yourdomain.com/wp-content/uploads2"
Notice the "2" added to the folder-name
Delete any entries in "Full URL path to files"
Save changes
Now your site should already show some images again
Do all this again but now change it back to "http://www.yourdomain.com/wp-content/uploads"
Save changes
This finally worked for me.
Gathering from other sources, this occurs mostly after moving a website from one location to another. Other fixes I did prior to this:
Within MySQL, replace the old URL in the GUID values in "wp_posts" to the new URL
Change "chmod" settings (it you never had any prior issues, don't)
Many other answers to this issue included changing chmod to give access to the files, which didn't do anything but crash the website. Other solutions would've been to change the code entirely to use a different function. I figured it's not broken, just missing a setting. Turns out that was the fact.
It worked for the domain http://www.in1week.nl, which runs on a modded DeepFocus template by ElegantThemes.com. The theme uses "timthumb" in the function "print_thumbnail()", which may have caused the issue. This reset the value needed to use the function.
I faced the same problem and had to look around a lot in search of an answer. After my host moved servers, thumbnails weren't appearing on the home page and category pages. Looking up the source showed me that the path generated for the thumbnails was incorrect. Instead of http://.. in the image paths, I was seeing absolute file paths in the server, such as /home/..
Couple of solutions that seemed to have worked for others did not work for me.
What did not work:
Changing permissions of wp-content/uploads and all the directories under it.
Changing media settings and again reverting back to original settings.
Using 'the_post_thumbnail' instead of 'print_thumbnail' function helped the thumbnails come back, but I am no programmer and could not figure out how to make the_post_thumbnail function work exactly as it was working with print_thumbnail
What worked:
In my many searches, I read someone saying that the problem was fixed by correcting the path for 'et_images_temp_folder' in the database. I ignored this for a while since I did not understand what it meant. Later, I searched wp_options table and found that it had the following entry.
option_name: et_images_temp_folder
option_value: /home/painteds/public_html/darter/wp-content/uploads/et_temp
When the servers were moved my home dir was changed from /home to /home3 Perhaps print_thumbnail was searching for /home folder, and was malfunctioning when it could not find it. Updating the database with the new value fixed the problem for me.