The plugin can execute php string in posts/pages, and display the output as the contents of posts/pages. Just quote what you want to execute in <exec>...</exec> or [exec]...[/exec] tag.
You can put the php code in post following way.
$filestr = file_get_contents('http://www.seocompany.ca/pagerank/page-rank-update-list.html');
if (preg_match('/</pre>
.*<\/p>/ums', $filestr, $matches)){
echo str_replace("
<a href="\"#page-rank-update-list-history\"">Top of Page Rank Update List History</a>
<pre>", "", str_replace("", "", $matches[0]));
}
Keeping your wordpress database is very important for wordpress database. In this article we explained, How to clean up and optimize wordpress database. This will improve your site speed aslo. Many times you install the wordpress plugins and some time you dont want that plugins and you delete that plugins.
How to clean up and optimize wordpress database
There is very nice wordpress plugin is avilable for database backup.
WP-DB-Backup allows you easily to backup your core WordPress database tables. You may also backup other tables in the same database.
But that plugins create some tables in your wordpress database. You need to remove that tables from your wordpress database.
Imp note: when ever you are cleaning the database or deleting the unwanted tables from wordpress database. Please consult with your web administrator.
Dont forget to take a full backup of your database.
This tutorial should be forward-compatible with WordPress 3.0
Install WP-DB-Backup by Austin Matzko
Mouse over Tools so that the down arrow appears
Click the down arrow
Click Backup
You’ll see something like this:
How to clean up and optimize wordpress database
On the left are the default database tables included with WordPress. All of these are included every time you backup. The only thing you have to decide here is whether to exclude spam comments from being backed up (I recommend this) and whether to exclude post revisions (I recommend excluding these too, unless you have a specific reason for keeping revisions).
On the right is a list of additional database tables, most of which were probably created by plugins. There’s also a table called that will end with the name “commentmeta” – this can be used by plugins.
If your plugins have created a lot of data that you would like to save, or you’ve spent a lot of time configuring particular plugins, you’ll want to backup these tables. Otherwise, you can keep your database backups smaller by not checking them.
Next we see the Backup Option. There are three choices here:
A. Save to the server
This will save a backup of your database as a file on your web server. I don’t recommend this.
B. Download to your computer.
This will create a database backup file that you can save to your local computer.
C. Email backup to:
This allows you to send a copy of the backup to any e-mail address you’d like.
Let’s go ahead and download a copy to our hard drives now.
Check options you want in the Tables section then click “Backup now!”
You should see a progress bar, and when that’s done your browser will prompt you to save the file. You can save this file wherever you’d like.
There’s another section called “Scheduled Backup.” This is where this program gets really great.
Here we can schedule a backup to be e-mailed to a particular e-mail address however often we’d like. I recommend checking selecting “Once Daily.”
On the right, you’ll see that list of optional tables again. Check the ones you want to backup every time the backup runs.
Enter the e-mail address you want the backups delivered to in the “Email backup to:” field.
Click “Schedule backup.”
You should now get a backup file as an e-mail attachment every day. You should save these attachments to your local computer. If you’re using Gmail or another web mail host that has a lot of storage space, you might want to leave your databases on their server as an additional off-site backup. Be aware that that’s an additional security risk – if your e-mail account is ever compromised, the would have access to all of your database backups.
WordPress has just announced the 100th million plugin has now been downloaded. It’s a smaller milestone but just as impressive if not even more so, since blogging tools are not going to have the same mainstream audience or appeal as a web browser. WordPress is also celebrating a smaller milestone, the newly launched WordPress 3.0 has just passed three million downloads.
WordPress completed 100th Million Plugin Download
WordPress completed 100th Million Plugin Download
What wordpress is saying?
WordPress 3.0 Thelonious passed 3 million downloads yesterday, and today the plugin directory followed suit with a milestone of its own: 100 million downloads.
The WordPress community’s growth over the years has been tremendous, and we want to reinvest in it. So we’re taking the next two months to concentrate on improving WordPress.org. A major part of that will be improving the infrastructure of the plugins directory. More than 10,000 plugins are in the directory, every one of them GPL compatible and free as in both beer and speech. Here’s what we have in mind:
We want to provide developers the tools they need to build the best possible plugins. We’re going to provide better integration with the forums so you can support your users. We’ll make more statistics available to you so you can analyze your user base, and over time we hope to make it easier for you to manage, build, and release localized plugins.
We want to improve how the core software works with your plugin and the plugin directory. We’re going to focus on ensuring seamless upgrades by making the best possible determinations about compatibility, and offer continual improvements to the plugin installer. And we also want to give you a better developer tool set like SVN notifications and improvements to the bug tracker.
We’re also going to experiment with other great ideas to help the community help plugin authors. We want it to be easy for you to offer comments to plugin authors and the community, including user reviews and better feedback. We may experiment with an adoption process for abandoned plugins as a way to revitalize hidden gems in the directory. I’m not sure there is a better way to show how extendable WordPress is and how awesome this community is at the same time.
As Matt said in the 3.0 release announcement, our goal isn’t to make everything perfect all at once. But we think incremental improvements can provide us with a great base for 3.1 and beyond, and for the tens of millions of users, and hundreds of millions of plugin downloads to come.
There are now a little over 10,000 plugins in the WordPress directory which really puts the 100 million downloads number in perspective. Of course, some plugins are more popular than others, but it does indicate that bloggers are very interested in the added functionality these plugins provide.
The most popular plugin is the antispam tool Akismet with over 8.5 million downloads to date. The tool comes pre-installed with WordPress, so that may explain its popularity, although, these installs may not be counted as downloads. However, later updates are probably counted. Other popular plugins are the All in One SEO Pack with five million downloads and Google XML Sitemaps with close to four million.
Given the popularity of WordPress plugins, it’s no surprise that they are now getting some attention from the development team. Having wrapped up WordPress 3.0, the team decided to focus on some of the things surrounding WordPress rather than the software itself.
“The WordPress community’s growth over the years has been tremendous, and we want to reinvest in it. So we’re taking the next two months to concentrate on improving WordPress.org. A major part of that will be improving the infrastructure of the plugins directory,” Andrew Nacin, a WordPress developer, announced.
“We’re going to provide better integration with the forums so you can support your users. We’ll make more statistics available to you so you can analyze your user base, and over time we hope to make it easier for you to manage, build, and release localized plugins,” he explained.
Here in wordpress tutorial, we explained, how to do persistent database connection in wordpress. Persistent connections are links that do not close when the execution of your script ends.
What is persistent database connection?
Persistent connections are links that do not close when the execution of your script ends. When a persistent connection is requested, PHP checks if there’s already an identical persistent connection (that remained open from earlier) – and if it exists, it uses it. If it does not exist, it creates the link. An ‘identical’ connection is a connection that was opened to the same host, with the same username and the same password (where applicable).
how to do persistent database connection in wordpress
If you want to use the persistent database connection then you should follow my steps:
how to do persistent database connection in wordpress
First Open the wp-db.php file from wp-includes folder. In that file find following words:
// @mysql_connect( $dbhost, $dbuser, $dbpassword, true );
//Change that to
@mysql_pconnect( $dbhost, $dbuser, $dbpassword, true );
comment the mysql_connect line. This line you will find two times in that file. You need to change the line both the times. Then upload this file to your wordpress installation.
Persistent database connection will open only one connection and for every query that will check for connection is present or not. If connection is already present then your query will execute using that persistent database connection.
There are couple of issues with persistent database connection, When you are using the persistent connection you should keep following things in mind.
Imp: There are a couple of additional caveats to keep in mind when using persistent connections. One is that when using table locking on a persistent connection, if the script for whatever reason cannot release the lock, then subsequent scripts using the same connection will block indefinitely and may require that you either restart the httpd server or the database server. Another is that when using transactions, a transaction block will also carry over to the next script which uses that connection if script execution ends before the transaction block does. In either case, you can use register_shutdown_function() to register a simple cleanup function to unlock your tables or roll back your transactions. Better yet, avoid the problem entirely by not using persistent connections in scripts which use table locks or transactions (you can still use them elsewhere).
