I have a problem with Wordpress, I changed my domain, but all media use the old domain.
For example :
I access my site with www.newdomain.fr
but in source code all src="" or media are with www.olddomaine.fr/wp-content/...
How can I change this ?
There are several options this can come from.
You probably have to migrate the whole database and it's serialized strings to the new domain name - for instance take a look at this Plugin Better Search Replace and replace the old domain name with the new one in your DB (don't forget to backup everything before you to this), this plugin should also handle the serialized data
If this doesn't resolve your issue you should take a look at your template code and even the css, there could be hard coded urls you have to replace (this should be considered as a bad practice and if this is the case you should build the template more dynamically)
Related
This is probably a dumb question, but I'm worried :
I have published a website on a server, then made some changes to a css file.
As the css file was already cached by my browser, it didn't display the changes.
deleting the cash allowed to display the changes.
Now my worry is that if some users have previously been to the website, and it is cached by their browser, if I make a change they wouldn't be able to see it.
How do you guys prevent this ? Do you just change the file names ?
Sorry for my noobness,
Thanks.
There are a number of solutions floating around the web, but as far as I can tell they all boil down to changing the CSS filenames whenever their content changes. That way you steer clear of user caches and server caches serving old content.
Variants:
Instead of changing the name of the file itself, create a symbolic link with a new name to the old file whenever content changes.
Instead of changing the name of the file, change the way it is referenced by the page. Replacing myfile.css?v=1 by myfile.css?v=2 circumvents people's caches.
Write code that automatically changes the name or the link name or the way the file is referenced
Use a framework that does one of the above.
And: remember that the same problem applies to any content that might be cached, like JS files.
Ive recently ported a wp site to a new host, i did this by exporting the db and then updating it to the new host, its all come across pretty easily but the main problem im having is the img src urls have added an extra / to them.
They should look like :
http://mydomain.com/wp-content/uploads/2012/04/0007_cloud.png
but instead are like :
http://mydomain.com//wp-content/uploads/2012/04/0007_cloud.png
is there a way i can mass fix these broken urls ?
Yes, you can use "Search and replace tool". It will safely replace all strings in database.
I'm pretty sure I've read somewhere that you can actually move the main plugin *.php file to somewhere else (I assume under your theme directory) to have it safe in case you made changes to it and your plugin updates. I tried Google but I can't find anything. Google page with good results will suffice.
I've just experienced a situation where my 2 plugins which had its layout changed and accommodated my needs and I want to make sure it doesn't happen again. Apart from having the main file in another location, is there a way to move along any CSS and JS files as well?
In Concrete5 CMS there is a nice way of doing this, by creating a new folder inside a block of an addon (may be regarded as a WP plugin), inside of which you can create copies of main file, any CSS and JS files and then you can simply edit them and choose that template for a page location you are using that block in.
I assume there is no such thing in Wordpress but how close can I get?
UPDATE: I found where I applied that advice on creating a new instance of the file then moving it to the theme directory.
The plugin in question was HL-Twitter. These are the plugin files:
admin.php
archive.php
functions.php
hl_twitter.php
hl_twitter_archive.php
hl_twitter_widget.php
import.php
widget.php
Now, this is the top contents (commented out) of the hl_twitter_widget.php:
Widget Theme for HL Twitter
To change this theme, copy hl_twitter_widget.php
to your current theme folder, do not edit this
file directly.
Available Properties:
$before_widget
$after_widget
$before_title
$after_title
$widget_title
$show_avatars
$show_powered_by
$num_tweets: how many tweets to show
$tweets: array of $tweet
$tweet: object representing a tweet
$tweet->twitter_tweet_id
$tweet->tweet
$tweet->lat
$tweet->lon
$tweet->created
$tweet->reply_tweet_id
$tweet->reply_screen_name
$tweet->source
$tweet->screen_name
$tweet->name
$tweet->avatar
$user: represents the Twitter user (ONLY SET IF SHOWING A SINGLE USERS TWEETS!)
$user->twitter_user_id
$user->screen_name
$user->name
$user->num_friends
$user->num_followers
$user->num_tweets
$user->registered
$user->url
$user->description
$user->location
$user->avatar
So I was wrong about copying the main file (in this case hl_twitter.php), but still - this enabled me to edit the file outside the plugin directory and the system somehow checks for its existence and picks it up if exists.
If this behavior something that is natively supported by Wordpress or it has been integrated in the plugin itself?
With themes, Wordpress has a concept of "child themes" which allows exactly that: to keep changes separate from main theme, in case it changes.
I haven't yet found a way to do this with plugins.
I'm using a few tactics myself:
I bump plugin version to a very high number like 99.9. This way Wordpress won't ever update the plugin.
Store my plugins in version control (i use git, but it doesnt matter), this allows you to update the plugin, run the 'diff' tool and see what changes happend. If you don't like you just revert like it would be a bad code you've written. But this approach requires a bit of skill.
Are you talking about running parts of a modified 3rd party plugin, and an updated version, at the same time?
That's not going to be possible. There is no magical method of "preserve my changes and transfer them into the new version automatically". The way to go here is doing a diff between the edited version and the update, and integrating the changes in the actual source files.
The bottom line is, if you manually edit a third party plugin, you're in for manual review (and possibly rework) once an update takes place. That's why it's usually not a good idea to extensively modify third party plugins.
Well in fact, yes! There is some kind of way.
You have to remove the to be modificated plugin's original actions/filters and then add your altereted actions/filters.
If the desired plugin is even coded in OOP you can just inherit the whole class and rewrite the wanted functions (oh sorry: "methods". we're talking about OOP ;) ). Instantiate your inherited class and rest as above.
Maybe there are better ways! I already search for a method so that the original class won't even get loaded but our altered one instead but I'm no John Carmack.
I'd like to get WordPress to write directly to a file. I know I can do this with PHP, but WordPress deals directly with the database, and doesn't do static publishing by default.
I also know there are many caching plugins available, so this may come down to a cache plugin recommendation.
Here's the deal: I'm trying to use WordPress to generate some XML files that I need for another project. So, basically for data entry. Right now, my solution is to have the template put everything I need into a textarea. That's easy enough, but then I have to copy from it and paste that into a text file and save it. I'd love to skip that step and have WordPress make the files for me.
Can you recommend a plugin that would let me do this easily? It's OK if it comes down to a caching plugin, but that seems like it might be overkill. Does something simpler exist?
get the content of the post and feed it to the fput:
$myFile = "myXML.xml";
$fh = fopen($myFile, 'w') or die("There was an error, accessing the requested file.");
fwrite($fh, get_the_content());
fclose($fh);
So I'm writing a Django based website that allows users select a color scheme through an administration interface.
I already have middleware/context processors that links the current request (based on domain) to the account.
My question is how to dynamically serve the CSS with the account's custom color scheme.
I see two options:
Add a CSS block to the base template that overrides the styles w/variables passed in through a context processors.
Use a custom URL (e.g. "/static/dynamic/css/< website_id >/styles.css") that gets routed to a view that grabs all the necessary values and creates the css file.
I'm content with either option, but was wondering if anyone else out there has dealt with similar problems and could give some insight as to "Best Practices".
Update : I'm leaning towards option number 2, as I think this will allow for better caching down the road. So it's dynamic the first time, gets stored in memcache (or whatever), and invalidated when a user updates their settings in the admin site.
Update: Firstly, I'd like to thank everyone for their suggestions thus far. All the answers thus far have focused around generating static files. Though this would work great in production, it feels like a tremendous burden during development. If I wanted to add a new element to be styled, or tweak existing styles I'd have to go through and recreate each and every css file. Sure, this could be done with a management command, but I just don't feel it's worth it. Doing it dynamically would add 1 maybe 2 queries to each page load, which is something I'm not worried about at this stage. All I need to know is that at some point I will be able to cache it without rewriting the whole thing.
I've used option #2 with success. There are 2 decent ways of updating the generated static files that I know of:
Use a version querystring like /special_path.css?v=11452354234 where the v parameter is generated from a database field, key in memcached, or some other persistent file. Version gets updated by admin, or for development you would just make the generation not save if the parameter was something special like v=-1. You'll need a process to clean up the old generations after some time.
Don't use a version querystring, but have it look first for the generated file, if it can't find it, it generates it. You can create a cron job or WSGI app that looks for filesystem changes for development, and have a hook from your admin panel that deletes generations after an update. Here's an example of the monitoring, which you would have to convert to be specific to your generations and not to Django. http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode#Monitoring%5FFor%5FCode%5FChanges
Could generate the css and store it in a textfield in the same model as the user profile/settings. Could then have a view to recreate them if you change a style. Then do your option 1 above.
Nice question.
I would suggest to pre-generate css file after colors scheme is saved. This would have positive impact on caching and overall page loading time. You can store your css files in directory /media/css/custom/<id or stometing>/styles.css or /media/css/custom/<id or sth>.css and in template add <link rel="stylesheet" href="/media/css/custom/{{some_var_pointing _to_file_name}}" />
You can also do the trick with some random number or date in css file name that could be changed each time file is saved. Thanks to this browser will load the file immediately in case of changes.
UPDATE: example of using model to improve this example
To make managing of those file easy you can create simple model (one per user):
class UserCSS(models.Model):
bg_color = models.CharField(..)
...
...
Fields (like bg_color) can represent parts of your css file. You can ovveride save method to add logic that creates css file for user (by rendering some template).
In case your file format change you can make changes in your's model definition (with some default values for new fields), make little changes in template and run save method for each exisintg instance of class. This would renew your css files.
That should work nicely.
I would create an md5 key with the theme elements, store this key in the user profile and create a ccs file named after this md5 key : you gain static file access and automatic theme change detection.