Forum Replies Created

Viewing 15 replies - 1 through 15 (of 47 total)
  • There is no difference. A page is a special kind of post.
    'post_type' => 'page'

    Looks like the WordPress theme you’re using was made a long time ago, and needs to be updated. Many of the errors you see come from your theme calling WordPress functions with deprecated arguments.

    Look up each function you have trouble with in the Codex.

    For get_bloginfo, you can look up the Codex for it, but in this case the answer is right in the error code: wherever you have get_bloginfo(‘siteurl’) appearing in your theme, replace that with get_bloginfo(‘url’) or simply home_url().

    Long-needed upgrades can be tricky, WordPress has changed quite a bit since 2.2.

    If you get too many errors all over your theme, you might want to consider re-building it from a copy of an existing WP3-compatible design.

    The first thing to make sure you have no newline characters before or after the PHP tags in wp-config; the <?php tag should be on line 1, and ?> should be the very last characters of the file. If you’re in luck, that will fix it. If not, there may be a plugin conflict.

    See here.

    DocumentRoot can point anywhere in your system. Filesystem name and base URL don’t need to match either, you’re free to organize things as you like.

    I’m not very conversant with WAMP, but I’m curious as to what didn’t work with XAMPP. I have it working perfectly on my system, but the trick is to create virtual hosts in the /apache/conf/extra/httpd.vhosts, not in the general httpd.conf settings file.

    This is the structure I have in mine:

    <VirtualHost 192.168.1.3:80>
    	DocumentRoot "C:\Users\Me\Documents\Project1\website"
    	ServerName project1.tld
    	ServerAdmin admin@project1.tld
    	<Directory "C:\Users\Me\Documents\Project1\website">
    		Options Indexes FollowSymLinks
    		AllowOverride All
    		Order allow,deny
    		Allow from all
    	</Directory>
    	ErrorLog logs/project1.tld-error-log
    	CustomLog logs/project1.tld-log common
    </VirtualHost>

    Then you need to edit your HOSTS file (e.g. C:\Windows\System32\drivers\etc\HOSTS) to link your local IP to the newly created local domain. In my case, I’d add:

    192.168.1.3		project1.tld

    Only make configuration file changes when Apache is shut down.

    Do I simply put that RewriteRule at the very top of my .htacess file? Or does something need to be above it (like RewriteBase and/or RewriteEngine On, etc.)?

    Well, after RewriteEngine and RewriteBase, which set up the redirection module in Apache. If you modify the permalink structure in WordPress, which you undoubtedly will if you haven’t already, then place that line just above the WordPress block.

    From reading a few articles on how to migrate from Joomla to WP I was made aware of the 301 plugins, but from what I gathered they required me to set up a rule for every unique page request

    No, some of them let you use regex as well.

    Regular expressions are not that complex conceptually. It’s just that there’s several ways to get the same result, alternate separators for conflicts or clarity, and the need to escape sequences sometimes make it hard to read. Then there’s the backward matching and such options, which can be rather involved. Tools like the Regulator can help a great deal when learning or designing complex regex.

    ### = the unique identifier. As I write this I am getting the sense it’s darn lucky I’d left that in there

    Yes indeed. Might want to put it in your WordPress URLs too, although I bet you’ll be staying with WP a while.

    On Joomla I had SEO type permalinks. In the format:
    YYYYMMDD###/sectionname/categoryname/title.html

    This should work:

    RewriteRule ^[0-9]{8}([0-9]*)\/ /?p=$1 [R=301,L]

    Takes practice to get used to regular expressions. See regular-expressions.info and perhaps this cheat sheet for pointers if you need to make up more rules.

    Do I need to do anything other than provide the redirection rule in order for Google to treat it as a 301? Or does it just assume that to be the case when it sees it has been redirected?

    The R=301 flag is what search engines expect (301 redirects).

    You can also search plugins for 301.

    The module provides a function for that: j2wp_do_wp_connect(). It’s called just before the loop, so you don’t need to worry about selecting the database. Then it’s only a question of running the query (around line 408):

    foreach ( $j2wp_pages as $j2wp_page )
    {
            /* BEGIN Force post id for SEO */
            $current_post_id = $j2wp_page['ID'];
            $query = "INSERT INTO {$j2wp_wp_tb_prefix}post(id) VALUES('$current_post_id')";
            $result = mysql_query($query, $CON);
            if (!$result) {
                    echo "Could not create post #$current_post_id<br />";
                    echo mysql_error();
            } else {
                    echo "Created post #$current_post_id<br />";
            }
            /* END Force post id for SEO */
            $id = wp_insert_post( $j2wp_page );

    Not forgetting to add the ID to each page (around line 377):

    $j2wp_pages[] = array(
            'ID' => $R->id, /* Force post id for SEO */
            'post_author' => $user_id,
            'post_content' => $post_content,
            'post_date' => $R->created,
            'post_date_gmt' => $R->created,
            'post_modified' => $R->modified,
            'post_modified_gmt' => $R->modified,
            'post_title' => $R->title,
            'post_status' => 'publish',
            'comment_status' => 'open',
            'ping_status' => 'open',
            'post_name' => $R->alias,
            'tags_input' => $R->metakey,
            'post_type' => 'page'
          );

    Hopefully that’ll do it.

    By the way, this question was asked 3 months ago and was left unresolved. When you do get it to work as required, might want to notify the developer(s) in the appropriate plugin section of these forums.

    Crossed posts again.

    Well, the INSERT statement happens in function j2wp_process_posts_by_steps, which is only called around line 684 in function j2wp_joomla_wp_posts_by_cat, in turn invoked in function j2wp_do_mig on line 178. The INSERT is called conditionally when a post is part of one of the categories the plugin script identifies in lines 86 and following. It’s not called for every single post. How many categories does the plugin report when doing its migration?

    Anyways, I guess in the end, the simplest is to use the first method I mentioned (adding ‘ID’ => $R->id around line 376), and force an INSERT just before wp_insert_post on line 408. Connect to database, then run a query like:

    $query = "INSERT INTO" . $j2wp_wp_tb_prefix . "post(id) VALUES('" . $j2wp_page['ID'] . "')";

    Hopefully that will make wp_insert_post happy.

    Answers crossed.

    You are correct. Actual inserts are occuring circa line 1097.

    So, in the list starting at line 1049, add:

    'ID' => $R->id,

    Then in the list starting on line 1081:

    "ID" => $item['ID']

    Give that a try. Truncate wp_posts first.

    Ah, that’s a shortcoming of wp_insert_post, which I overlooked:

    IMPORTANT: Setting a value for $post[‘ID’] WILL NOT create a post with that ID number. Setting this value will cause the function to update the post with that ID number with the other values specified in $post. In short, to insert a new post, $post[‘ID’] must be blank or not set at all.

    Above solution won’t work. The first workaround that comes to mind is to create a whole bunch of dummy posts starting with id 1 to the highest id in your Joomla installation. Messy.

    [As per version 1.5.4 of Joomla to WordPress migrator]

    The insertion happens on line 408 in joomla2wp-mig.php:

    $id = wp_insert_post( $j2wp_page );

    wp_insert_post accepts the ID as a parameter, so all that’s needed is to put an extra key with the Joomla ID in the array.

    The array is populated on line 376:

    $j2wp_pages[] = array(
            'post_author' => $user_id,
            'post_content' => $post_content,
            'post_date' => $R->created,
            'post_date_gmt' => $R->created,
            'post_modified' => $R->modified,
            'post_modified_gmt' => $R->modified,
            'post_title' => $R->title,
            'post_status' => 'publish',
            'comment_status' => 'open',
            'ping_status' => 'open',
            'post_name' => $R->alias,
            'tags_input' => $R->metakey,
            'post_type' => 'page'
          );

    Just add the id to the list (referring to this, and assuming Joomla does indeed use “id” as index field):

    'ID' => $R->id,

    I believe that making these two changes is all that’s needed to make the script preserve identifiers.

    That is unfortunate.

    I just took a look at this page and browsed code for the third one in the list (Joomla to WordPress migration wizard). I believe that’s the one you used, correct?

    If that’s the one, then you can try doing the following.

    In index.php, the INSERT line goes like so:

    $j = 0;
    	while ($j < $i) {
    
    		/* Create an acceptable WP post_name */
    		$post_name = sanitize_title_with_dashes($import[1][$j]);
    
    		/* Do the actual query */
    		$query = "INSERT INTO wp_posts (id, post_title, post_content, post_date, post_modified, post_name, post_category) VALUES ('', '{$import[1][$j]}', '{$import[2][$j]}', '{$import[3][$j]}', '{$import[4][$j]}', '$post_name', '$wpsection')";
    		/* For debugging purposes */
    		echo "<br />".$query."<br />";
    		$result = mysql_query($query) or die("<p>Query failed</p>");
    		$j++;
    	}

    The script doesn’t preserve identifiers (the first VALUE entered is ”, i.e. blank, which tells MySQL to auto-increment the index). If you empty the table (to remove leftovers and the first default post) and force the id, you should be able to preserve them.

    First, empty the wp-posts table in phpMyAdmin or from the command-line (TRUNCATE TABLE wp-posts).

    Now modify the INSERT in index.php to force the ID (change the ” to ‘{$import[0][$j]}’) in all three places (lines 385, 468 and 577) [1], something like:

    $query = "INSERT INTO wp_posts
    	(id, post_title, post_content, post_date, post_modified, post_name, post_category)
    VALUES
    	('{$import[0][$j]}', '{$import[1][$j]}', '{$import[2][$j]}', '{$import[3][$j]}', '{$import[4][$j]}', '$post_name', '$wpsection')";

    I think that should do it as far as preserving IDs.

    Note that preserving comments would follow more or less the same pattern used in index.php. If you match the rows in Joomla to those of WordPress, you should be able to find out how to do the INSERTs (example: Migrating from Drupal).

    EDIT:
    [1] The third one is actually for links, so you’ll want to truncate the wp_links table as well if you want to migrate links from Joomla and preserve IDs.

    As far as #3 and #4 I think you can still refer to posts via identifier, so if you had a post with, say, id=276 in Joomla, giving WordPress something like ?p=276 will reach the proper location. That’s if your migration preserved identifiers, which presumably it did…

    Fiddling with .htaccess should point you in the right direction. For example, if you had Joomla URLs of the form /content/view/2985/33/, the following should work:
    RewriteRule ^content\/view\/([0-9]*)/ /?p=$1 [R=301,L]

    If your Joomla URLs were formatted like /index.php?view=article&id=2985&itemid=33, then you’ll need to rewrite those as:

    RewriteCond %{QUERY_STRING} id\=([0-9]+)
    RewriteRule ^ /?p=%1 [R=301,L]

    All the above does is use WordPress’s internal id reference (?p=id always works, provided the given id is that of a valid post) to serve the post. The URL is automatically rewritten as per WordPress settings afterwards.

    Note you’ll need to add your Joomla legacy URL rules above the WordPress rules in .htaccess. If you had Joomla pages with other formats, you’ll have to set up several rules to cover all cases.

    I think that covers it as far as SEO. Google will reach the right page with a code 301 (Moved Permanently), and will update its database with the new WordPress URL.

    Hope that helps.

    Quick reference:
    mod_rewrite wiki

    Correct, the code should be placed in a plugin, not in functions.php. My bad. See updated post. Tested now.

    And oops, the above code should be placed inside a plugin file, placed in the plugins directory and activated in the administration area. So you have to enclose the above in the following:

    <?php
    /*
    Plugin Name: e-mail privacy
    Plugin URI: http://www.me.com/
    Description: Hides private details from comment notification emails, such as IP address and email.
    Author: Me
    Version: 1.0
    Author URI: http://www.me.com/
    */
    
    if ( ! function_exists('wp_notify_postauthor') ) :
    
    etc. etc. etc.
    
    endif;
    ?>
Viewing 15 replies - 1 through 15 (of 47 total)