TonyR63

Hi Tom

You are probably correct as I was not aware that there was another solution named so similar.

Previously I have logged support queries here:

https://ww.wp.xz.cn/support/topic/backup-stops-at-64?replies=4#post-5413999

What would you recommend to backup WordPress as I need to ditch BackupWp.

Many Thanks

Anthony

Hello

Thanks to everyone who have provided assistance which was very helpful and most appreciated.

I manually upgraded from 3.5.1 to 3.7.1 and then again from 3.7.1 to 3.9.1 by downloading and copying files which appears to have worked, thankfully. I had no confidence that I would not have to back out and restore my data due to imbiguities in the documents I was referred to
For example, and for the benefit of others, I found I did NOT have the file structure exactly as depicted in the manual upgrade document that can be reviewed here:

http://codex.ww.wp.xz.cn/Upgrading_WordPress_Extended

Here is what the document states:

Delete the old WordPress files on your site, but DO NOT DELETE

wp-config.php file;
wp-content folder; Special Exception: the wp-content/cache and the wp-content/plugins/widgets folders should be deleted.
wp-images folder;
wp-includes/languages/ folder–if you are using a language file do not delete that folder;
.htaccess file–if you have added custom rules to your .htaccess, do not delete it;
robots.txt file–if your blog lives in the root of your site (ie. the blog is the site) and you have created such a file, do not delete it.

I did not have a /wp-content/cache nor did I have a /wp-content/plugins/widgets in fact just checking I see the upgraded site still does not have this structure so the docunment I was to relay on is not applicapable to my installation so you could imagine how I felt about deleting and copying over folders not being certain about what i needed to retain.

Is the document inaccurate as it must be becuase my installation has never been altered?

Also the instruction to not delete the wp-images folder could be be understood as there is no wp-images folder in my installation or the original 3.5.1 archive downloaded from Codex so where did they get this instruction from?

In a previous post I feedback the importance in providing full paths to files that are to be over written or deleted however I got a rsponse that it depends on the location of installation however that does not prevent the documents have an example of a typical path that one could compare to their own installation and workout the contextual varience?

In addition regardles of where the root of your site resides the structure of the /WordPress/.. could be fully qualified makeing it more likely that users will not accidentally copy files to the wrong location? Surely this would enhance the documentation greatly with very little effort?

The WordPress platform is excellent however the documentation is very poor and it should be possible provide installation programes that can conduct accumulatory updates. Restricting people to copying over files manually does not do the excellent platform justice and should be avoided.

Hello ESMI

Thank you for your response and I have reviewed the document you have referenced. I was quite surprised to read your discription of my WordPress version as “old” installed 13 months ago and that it could be such a protracted task list to upgrade considering WordPress is noted for the 20 minute initial install. It would appear that the upgrade will take quite a bit longer than 20 minutes.
Another major surprise was to learn that the update process which is supposed to be a single click process does not work if you go beyond 2 version increments so perhaps the option shold be grayed out once the update downloaded is checked against the existing version or at least an error trap written for the upgrade process so that it cross checks the versions and if more than 2 provides the user trying to upgrade a more meaningful notice of what is causing the problem. In general WordPress should more explicitly advise the consequences of falling behind in upgrades if the process of steping over 2 increments is so fraught with risk.

I have the following queries from the instruction list you referenced.

Step 9 of the overview says “run the upgrade program” but does not say how or where this is launched?

The section suggesting upgrading incrementally is confusing saying U/G 2.5 to 2.7, then 2.9 and finally 3.9.1, I presume two steps each in between and not jumping from 2.9 to 3.9.1. If this is the case I presume I must upgrade from 3.5.1 to 1st 3.7.1 and then 3.9.1 Is this correct?

In Step 3 – what .SQL files editor should I use as none is mentioned and I have no idea what way I can review .SQL files from the instruction as written.

Finally when I installed WordPress initially on my own LAMP server I found it did not set the file permissions on the folders properly possibly because I extracted the files from the zip and moved them to the www/WordPress folder rather than unzipping them directly to their final destination. I did it this way because I had other web sites in the www folder that I did not want over written. The lose way the installation document was written meant I could not decypher for sure whether the WordPress folder was contained within the zip structure or I had to extract into a pre created WordPress folder. The consequence was, following the file copy I was unabe to run the installation or it would fail due to permissions problem (not at all obvious from the error shown) so my process was many hours / days longer than the 20 minute install much touted. This was all caused because the installation instructions did not list a simple explicit path to its expected installation destination but instead has a reference to Web Server Root or something to that effect from memory

As these is nothing in the instruction set that warns against copying files rather than zipping the archive contents, which seems to preserve permission on folder within the archive folder structure, Am I open to the same problem coming back when following copying the files I am unable to run the install?

Can you please clarify as I do not want to break my sites due to permissions problems again. Again the instruction sheet is somewhat vague about where you should run the unzip from. I have read “parallel to your current WordPres directory” but once again no complete PATH example? What is “parallel” to /var/www/Wordpress?

Hello Stefan

Sorry for the delay getting back to you and thank you for taking the time to respond. Delighted to hear you have implemented the auto save feature and hopefully it will be approved and perhaps benefit other users. I will send a further donation to help keep you guys going.

Concerning improvement in ordering of slides here are some suggestions.

1. Could there be a Sort function where users are asked it they would like slides ordered according to their existing alphabetical name or numerical order in the file names the way a folder would order inserted after selecting images for import? Could option be existing folder list order or prompt for ascending or descending or other variable?

2. I think I once put a number in the image file name in the source folder trying to force an order but found when I had imported they ended up the exact opposite to what I wanted. Could there be a button to just exactly reverse order to resolve such an occurrence?

3. Another possible feature would be to have an option to select “Reduce to story board line” where the interface switches to a small image slide strip horizontally left to right where you can drag images around that includes a zoom feature in case you cannot tell some images apart. I guess you need to think of ways of helping order before import and how to help adjust order after import if the order ends up not as expected.

4. A default of the description text duplicating the image name text might help start to fill out some of the text that people might want to put in description field rather than starting with a blank entry every time-could be another idea to take some of the labour out of the process.

5. Another possible future feature is to have your plugin pick up tag data from the image files.

I think if you can have some image ordering features your plugin will stand out because image order is very important in most cases.

I hope some of what I suggested will make some sense and might trigger other ideas within your team.

Kind Regards

TonyR

Thanks for your suggestions.

I host my own WordPress LAMP environment and I was updating content to a Web server on the same sub net. I would have contacted support had I remembered to capture the cryptic screen that was displayed without warning when I was updating the 2nd last slide in a 117 slide set. I have been using the slideshow plugin for more than 8 months with the same Mantra Theme and had only one other crash however it did not show the unusual screen I saw last night. The main WordPress editing interface occasionally falls off the perch however when you recover you only have to go back a few words but in the case of the Slideshow I lost all 70 minutes of manual editing having to start from scratch. This would be the greatest data loss I’ve had for many years that could not be accounted for by a power cut or hardware failure. Applications simply should not dump you out without any recovery option.

I have researched and learned about the excellent WordPress template hierarchy and practiced PHP scripting alterations of the Twenty Ten Theme on a sandbox environment and I do not understand what would cause this plugin to crash citing loss of connectivity to the server when I was just editing text in a form on the browser. Why would it be writing back to the server and why is it not hooking into the existing WordPress autosave functionality? I’m surprised that no one else has encountered this issue as it obviously does not autosave. o I will take a backup snapshot of my site and upgrade all components to the most recent release. I will test alternative slideshow options to see how they go before i commit to further content additions involving large numbers of pictures.

Update

I reviewed the advise at http://www.chrisabernethy.com/why-wordpress-asks-connection-info/ as well as the feedback from many others experiencing the same problem who responded to the thread and found that I was still not able to install plugins even with the correct ownership set on the relevant folders.

I run the chown -R command against wp-admin; wp-content/plugins and chmod -R 755 on wp-content/plugins and chmod -R a-w on wp-admin. It was only I edited the wp-config.php to include: – define(‘FS_METHOD’, ‘direct’) that the install proceeded but again with some errors – “could not create directory /var/www/wordpress/wp-content/upgrade” which I manually created and assigned www-data owner and also had to create an importers folder.

This allowed the import tool installation to complete and I was able to import the xml from the recent remote wordpress export. However not all the content was properly imported with much of the multimedia content corrupt. When I have worked with the content owner and determined what has not imported properly I will open a new thread to examine possible deficiencies with the import tool.

I believe the installation instructions for wordpress need to be reviewed because often on linux systems there is a difference between extracting a downloaded archive to its final intended destination on a server and extracting to an intermediate folder and subsequently copying it to its final destination in terms of the ownership and permissions that are set. The wordpress installation program should check and if required reassign ownership and permissions so that the admin features function as intended post installation. In Linux folder permissions are not inherited like ACL type permissions are in Windows.

The core requirement of any installation script is always to make such environmental preparations for intended application function and in the case of wordpress it is significantly deficient. I think it is very misleading to reference the 5 minute install in the manner it does and for many quite unhelpful.

Hello CJ

Thanks again for your suggestions and insights.

I checked the permissions on the wordpress folder and the owner was root not www-data as expected. I checked the other virtual hosts and they all too had root as owner. None had www-data. Should I checge the wordpress folder to have www-data as owner for increased security?

The permissions doco I reviewed stated that I should use the same permission that the web server is running under. What is the best way to tell what user my Apache2 server is running under. Is their a command to show this and where should it be run?

I manually copied all the 3.5.2 files over the old WordPress folder and copied back the moved out WP_Config.php. When I restarted I was able to complete the upgrade and then I was able to see the Network setting in the tools section and I was able to proceed with Network setup although I was not given the expected option of Host Name V’s File system configuration. Instead I go the message “the main site is a sub directory install..so I’m note sure how this will mix with my existing virtual hosts configured in the HTTPD.conf file. I was not using .htaccess files just directory section in HTTPD.config as recommended by Apache2 for those that have complete access to the whole server.

No change was made to the WP_Config.php file that would not work with 3.5.1 so I guess i will never know what was the issue with the PHP file. I did find a number of other users that seemed to have the same problem so there must be something unusual about how this file is Parsed. It might be an idea to have that entry in the sample config file but commented out reducing the possibility of syntax errors.

This issue can be closed and thanks for the assistance.