Hi Ben,

Why is the frequency set to so high? Why not setting it to just 60 seconds?

<Setting name="FileSystemDurabilityPlugin.SyncFrequencyInSeconds" value="7200" />

Thanks,

Houman

Houman,

Each time the sync is run it creates calls to the API. Each of those calls has a cost associated with it. To keep costs down the number is high. Since the new sync setup only syncs one file now the number can be safely lowered without incurring much cost.

Ben

Ben,

Ah it makes very much sense.  

The only reason I came across it was that I uploaded a plugin and was expecting to see it in the blob. But it wasn't there yet due late sync frequency.

Does it store it temporary on the VM until the sync has gone through?

Cheers,

Houman

Houman,

Yes, it is stored on the machine that the plugin is uploaded to. It is not recommended to use the sync plugin to keep your instances up to sync, however if you are doing so you should look at your ServiceConfiguration.cscfg file and make sure you are targeting the entire wp-content directory instead of just the single file that is required to be sync'd

Cheers,

Ben

Hi Ben,

Thanks for clarifying this.  Maybe I have misunderstood it, but I had the understanding that every upload through the WordPress dashboard would then automatically be landing (or at least synced) on the blob storage, once that plugin has been activated.

I have created last night a fresh scaffolding of WordPress 3.3 and RDP into the VM.  Well it all works great, but I realized the sync with Blob doesn't work at all.

I have chosen a new theme and added a couple of Plugins.  I can see them on E:\sitesroot\0\wp-content under theme and plugin folder respectively.

But I should also see them on the Blob, which I don't any longer.

The only file inside my blob -> wpsync is fields_map.parsed_types.php

I did that this morning and now in the evening, the 7200 seconds must have surely passed. :(

Do you think its no longer compatible with 3.3? I am using PHPAzure-4.0.5.  maybe the new 4.1.0 version would fix this problem?

Many Thanks,

Houman

Houman,

I see, our communication got crossed here. The sync plugin has nothing to do with uploading media files. Uploaded media is redirected to the Windows Azure storage account automagically with the storage plugin (http://wordpress.org/extend/plugins/windows-azure-storage/) while the sync tool keeps the SQL Azure specific database translation file sync'd between instances.

If you upload random files to wp-content, like a plugin, you bypass both the storage plugin and the sync plugin (when using scaffold defaults).

Does that clear it up a bit?

Ben

blobaugh wrote:

If you upload random files to wp-content, like a plugin, you bypass both the storage plugin and the sync plugin (when using scaffold defaults).

 

 

Morning Ben,

Thanks for your response.  

So do I understand it correctly that ONLY media files (such as images, document files, videos) that are uploaded through the dashboard will be synced on my Blob storage through the storage plugin (http://wordpress.org/extend/plugins/windows-azure-storage/)   But any other data uploaded through the dashboard (such as themes and plugins) are stored ONLY locally on the VM and won't be synced to the blob storage?

If my understanding from above is correct, it is reassuring to see that the media won't be lost, but its also a bit concerning, as if the VM crashes for any reason and gets restarted, I would loose all the plugins and theme settings.

I have tried to emulate this situation last night by logging into the Azure Dashboard, clicked on the WebRole containing the WordPress scaffolding and clicked on Reboot.

After the reboot; interesting enough my textfile on VM's desktop survived it. But the entire directory of my WordPress installation was deleted and reinstalled since none of the plugins and themes in the wp-content folder was available any longer.  I can also confirm this even further as I had received an email from my PowerShell script that runs as a StartUp task whenever the package gets re-populated.  

It seems that the only difference between Azure dashboard's 'Reimage' and 'Reboot' is that the former wipes everything off, while Reboot wipes only drive E: off where the sites are stored.

I will test again tonight with a new fresh installation, apply a custom theme and add some plugins, thereafter I will reboot the image to see if they are lost for good or not.  

UPDATE:

Ben, It seems I have found partially the answer to my question: http://social.msdn.microsoft.com/Forums/en-AU/windowsazuredevelopment/thread/3cd21ac6-aeb6-442b-af89-ae913946b3ba

In this case there is really no way around it but to sync the entire wp-content with my blob storage.  A WordPress installation grown with time, you add new plugins and features, and you don't want to loose them whenever the data center sees fir to reboot your instance (as its normal in cloud systems)  

You have mentioned previously I should be looking into  ServiceConfiguration.cscfg and target the entire wp-content.  I will check this out tonight.

UPDATE 2:

I have found the solution with a nice explanation: https://github.com/Interop-Bridges/Windows-Azure-File-System-Durability-Plugin # Readme

By the look of it if I comment out this line:

<Setting name="FileSystemDurabilityPlugin.FileNameIncludesToSync" value="" /> <!-- Optional: To sync specific files only -->


It won't just sync that specified file but would rather sync the entire folder specified in this line:

<Setting name="FileSystemDurabilityPlugin.LocalFolderToSync" value="*****" /> <!-- Relative path to approot -->

That site also warns about the possibility of higher costs incurred when doing this. But as it would only sync and copy the files over that have actually changed, traffic shouldn't be too bad.

Let see.. :)

Houman

Many Thanks
Houman

Houman,

You will not lose you theme settings, they will be stored in the database.

Yes you will lose any plugins or theme files that have been uploaded. This is the unavoidable nature of the cloud. That is why the documentation says to create and deploy a new package when you have new files you would like to add.

You are not understanding how the sync plugin works. What you are thinking is why only one file is targeted instead of the entire wp-content folder. EVERY time there is a sync ALL FILES in your wp-content folder will be checked against the storage blob. That means a ping to the server for each file. Each ping costs money, not a lot, but if you have a lot of files, several instances, and a low sync time it will add up quickly. Thus the proper way to do it is to install the new plugsin, themes, etc to your local development machine and create a new package that will update your running deployment. Then you avoid all the distaste of the sync plugin and possible extra costs inferred, and you can be assured that no matter what happens with your instances all the files will be available.

If you are installing a lot of new plugins or themes on a production WordPress site you may need to rethink your strategy. I have been running WordPress myself since 2007 and only made maybe a dozen plugin/theme changes after the initial setup. Changing a lot on the production site can lead to stability and consistency issues.

Ben

Ben,

Sorry, I know I am causing too much trouble and asking too many questions. :)  I really appreciate your patience with me.  

I am just going through the analysis phase if this is a reliable business solution, I imagined how risky it would be if a VM restarts and nothing looks as it used to be. :)

Thank you for your explanation.  So I wasn't too far off actually.  A VM can be restarted at any time through the data centre and therefore it shall be stateless.

Your proposal for solving this problem is to have everything up-front ready and making it part of the package (such as themes, plugins etc).  It makes sense for someone who is so experienced as you are, since I am still in the beginning and unsure about which plugins even to pick.

I need to repack the whole instance whenever I want a new plugin.  Its a painful process, I hope you agree, but its doable. I might then have to play around with the plugins on a local test machine to decide which ones to keep and make it then part of the final package.

One thing that makes PHP hard to maintain on the cloud is its state-fullness.   It writes too much locally, so I am glad you guys have figured out an intelligent way to store this on the blob/DB and the settings on the database.   I already knew that posts and pages etc are stored on the database, but wasn't sure about the plugin settings.  So if the plugin settings are also saved on the database, there shouldn't be any concern.  

I just have to rethink my strategy as you said.  Now would you update the scaffolding to support WP 3.3 any time soon? ;-p

Thank you Ben,

Houman

Houman,

Bet sure to note that in the new version of the WordPress scaffold the file sync plugin has been removed.

More details at http://azurephp.interoperabilitybridges.com/articles/how-to-deploy-wordpress-using-the-windows-azure-sdk-for-php-wordpress-scaffold#h2Section12

Cheers,
Ben

Hi Ben,

Many Thanks for letting me know about this.  This is fantastic news as it would cause less confusion and simplify things.  I have just got a fresh copy of everything and am building a new VM and will let you know soon how it went.

Thanks,

Houman