Forum Replies Created

Viewing 11 replies - 1 through 11 (of 11 total)
  • The readme.html in my download, modified more than two days ago states MySQL version 4.1.2 or higher as a recommendation.

    Stuff’s kinda vague.

    The language in version.php is stronger and more specific:

    /**
    * Holds the required PHP version
    *
    * @global string $required_php_version
    */
    $required_php_version = ‘4.3’;

    /**
    * Holds the required MySQL version
    *
    * @global string $required_mysql_version
    */
    $required_mysql_version = ‘4.1.2’;

    cdharrison is quoting from https://codex.www.ads-software.com/Version_2.9 and I’m getting ready to try the upgrade myself, but… I would like to know what’s changed. The page there says “and see the Changelog for 2.9.” with a link to the changelog for 2.8, which doesn’t exist, oops! No text on the page for 2.9, looks empty. Anyone know where to find the changelog? All I can find is the list of new features.

    Thread Starter beasts

    (@beasts)

    I don’t have that second WordPress install anymore, as it was just a sandbox for another user, and their own public_html folder was where it was installed, aliased to be the folder in the second install.

    See: https://codex.www.ads-software.com/Changing_The_Site_URL

    The examples there show not to place a trailing slash, and it’s not possible to do so, even though it’s more accurate to do so. In fact, other sections of documentation suggest placing trailing slashes on URLs in configuration areas, even after the initial domain where only the root folder is the target.

    So why does the WordPress -> Dashboard -> Settings -> General: WordPress address (URL) & Blog address (URL) fields not allow a trailing slash?

    The lack of trailing slash in the WordPress configuration causes the WordPress #heading div link and index meta tag to not have the trailing slash, and the only work-around is to hard-code the heading and index so the link contains the trailing slash and the web server doesn’t potentially fail when trying to serve the correct page when serving an alias to a folder. It fails to be aliased and looks for a file that doesn’t exist in the document root.

    Best case, the lack of trailing slash causes the server to redirect, and for anyone installing into a sub folder, the redirect will keep happening. Look at your WordPress site’s page source in the head, meta tag link rel=’index’, you’ll see that the slash isn’t there.

    Thread Starter beasts

    (@beasts)

    Seems like it’s not just the link in the header section that’s sans-slash.

    The index meta link has the same annoying behavior, even for those sites that install WordPress in their document root:

    <link rel=’index’ title=’Ipstenu.Org’ href=’https://ipstenu.org&#8217; />
    Heading link: https://ipstenu.org/

    <link rel=’index’ title=’distractionware’ href=’https://distractionware.com/blog&#8217; />
    Heading link: https://distractionware.com/blog

    Notice the heading link in the first example correctly slashes after the domain name, to signal root folder. But its index meta link doesn’t.

    In the second case where WordPress is one folder in, it fails to slash after the folder name on both the index meta link and the heading link.

    Thread Starter beasts

    (@beasts)

    I guess I’m confused as to why you’d put your WP install in a non web-root folder…

    The sans-slashed link really occurs when installed into any location but root. Any second install of WordPress would not be in the same folder as the first, and let’s suppose the first is in the document root.

    The link (URL) in the #header section of WordPress will be sans-slashed. The URL appears to be constructed literally from the Wordlress settings Settings -> General: WordPress address (URL) & Blog address (URL), which does not allow the forward slash to be placed as the last character.

    I mean, why not just do /public_html/blog/ from the get go?

    When the second install is intended for a second user who shouldn’t have access to the files of the first, is a good example of when an alias is required.

    And from a quick glance at my site, it has the trailing / in there. So I’m confused what you’re trying to do and why it’s ‘failing.’

    It seems like your site has WordPress installed in the root document folder. What I’m trying to do is place a trailing / on the name of the folder (not the domain name) in the URL entered into the form in Wordlpress Dashboard -> Settings -> General: WordPress address (URL) & Blog address (URL)

    If you’re trying to replicate the conditions, you’ll need to install a second WordPress, or install the first somewhere else but web document root. But to see it fail to allow a trailing /, enter the more-correct trailing /’d URL and see what appears after pressing “Save Changes”.

    All I’m requesting is that the settings there should allow properly formed URLs with trailing / for folders, because under an edge case, it causes WordPress not to work. Best case, WordPress creates a link URL in the heading that requires a redirect.

    beasts

    (@beasts)

    That’s the best advice for the thread starter. The best answer would be to make WordPress updates agile, as currently it can cause data loss for no good reason, except perhaps to scare the user into making backups. While backups are always best practice, forcing the user to do so because the system proceeds with a reinstall instead of just an update isn’t the best system. As a system grows in complexity, it would be nice if that complexity saved its user from doing more mundane tasks.

    While it’s always best practice to make backups, imagine having to backup your user data, format and reinstall every time your computer’s operating system needed a security update. People tend to trust the computer to keep their changes safe without understanding exactly how the computer operates. That seems to be what happened here.

    beasts

    (@beasts)

    The Tools->Upgrade replaces all core files. If you modify core files, including wp-content/themes/default and wp-content/themes/classic, those changes will get overwritten.

    This is why the list of changed files is important to people who don’t want brute-force updates. Maybe in the future the auto-update method will be more agile, until then – manual update is the best answer for the person who started this thread.

    beasts

    (@beasts)

    That’s the one I’m talking about. The left-most button is the automatic update, the button to its right downloads the entire install instead of just the changed files.

    For those who can use the automatic update, maybe they are receiving a smart only-update-the-files-that-changed. I wouldn’t know, as I’m stuck doing it manually. I suspect that if the only a few files have changed and someone complains that “it completely stripped away all of my modifications that I had coded in” then either all the changes that person made was in the few files changed or all the files were refreshed on the automatic update.

    I haven’t made any core changes, however, since I suspect automatic updates are brute-force instead of incremental-based, the manual update would be safer for those who have made core change edits and want to preserve them, but a list of changed files makes the manual update go faster.

    We’ll see how it goes next update. If the list of changed files isn’t posted at the time of the update, I’ll be going through the same process of hunt-by-date.

    beasts

    (@beasts)

    Ha, the List_of_Files_Revised was a blank List last time I looked.

    Thanks for the confirm, though. Sorry if I sounded cranky, but incremental updates are much easier than drag and drop all files then scratch head and wonder what got over-written. Thanks for great support, security updates, and great product that saves me a lot of work.

    beasts

    (@beasts)

    Alright, hoping I got this right. Manual updates give more flexibility to avoid stomp-over of changes, saves uploading extra files for no good reason, so I only uploaded these files:
    readme.html
    wp-admin\press-this.php
    wp-includes\version.php
    wp-includes\functions.php
    wp-includes\formatting.php
    Please correct me if I’m wrong, missed some files, need to do something else to update, or you know where this info is posted so I don’t have to do all the extra work each time there’s an update.

    beasts

    (@beasts)

    The trouble I have with the upgrade is that I don’t know what files have changed since 2.8.5. Is there a way to have those listed somewhere?
    I’m having to pick through the file dates and compare them one by one.

    When given a list of which files have changed, updates have gone much smoother and faster. I guess I was spoiled by earlier releases that listed this information, and will have to get used to doing this the hard way vs. dumping every file into my wordpress folder just to update the few files that have changed.

Viewing 11 replies - 1 through 11 (of 11 total)