Forum Replies Created

Viewing 15 replies - 181 through 195 (of 215 total)
  • Ok, I found the source on your github. I’ve got the base, login, connect widget, and register features all working now. I forgot to mention I’ve developed several Facebook apps ??

    Mainly the issue is that Facebook’s motto is “move fast and break things” (quote from Mark Zuckerberg himself). So the javascript API’s and XFBML that this plugin used were deprecated. I updated the javascript libraries and cleaned up the fb-login button params and such.

    I also defined some constants in the sfc.php to house the javascript URL and fb:login-button strings so I can update it in a single place.

    Hi, Otto. Would you be willing to allow some of us access to the latest version of your plugin, knowing its unsupported and has issues?

    I’m taking a serious look at writing a “sister” plugin to the official Facebook one that adds key features that are missing. For example, register/login with Facebook and showing profile pics on comments.

    I’ve already written a “members” plugin that has a page that shows all members, individual member pages, login / recent members widget. It also pulls Facebook profile pics from your plugin and the Sociabl.es plugin. I really just need the Facebook user registration / login piece and I don’t want to write it from scratch.

    I’m currently using the Facebook plugin from Sociabl.es on my website and I know it well as I have made many modifications to it, but it has every feature in the world and is way too complex to use as a starting point for what I want to do.

    Hmm. No answer in 10 months? I was wondering exactly the same thing. I created my test website by importing from production a long time ago and now I want to re-import production but have all this data out there in test already.

    So let me see if I can figure this out. Posts and comments should be obvious to truncate, but It exports all categories and tags too so I think we need to clear those too.

    • wp_posts
    • wp_postmeta
    • wp_comments
    • wp_commentmeta
    • wp_terms
    • wp_term_taxonomy
    • wp_term_relationships

    The only tables left (besides custom tables for plugins), should be wp_users, wp_usermeta, and wp_options.

    Actually, differences in wp_options might cause some differences in the how the test site works compared to production, but it also stores the test site’s URL and other stuff that should be purposely different. So I’m not going to mess with that.

    I’m bummed that the export doesn’t include any users. There doesn’t seem to be any easy way to get the users imported.

    I’ve definitely not done this as I abandoned my phpnuke site and built a brand new one in WordPress, but I did experiment with how I would convert it and ended up deciding it was way too much work. I had all kinds of nuke modules, including forums, and some custom modules I wrote, etc.

    However, if ALL you want to do is convert your news stories AND you don’t have too many stories, I would look into modifying phpnuke’s RSS feed to get it to output all of your posts instead of just the last 10. WordPress has a converter for RSS format.

    The file is called backend.php and at the very beginning you’ll see the SQL statements with “LIMIT 10”. You can change that number to 999 or 9999 or however you high you need to go. The issue is that if you have too many posts, your webserver may time out before it gets through all the posts.

    In that case, you’ll also notice at the top of the code that you can add “?cat=xxx” to the RSS feed URL and it will dump only a single category. Hopefully breaking the file into pieces by category will get you under your server timeout limit.

    Now for the harder part, you’ll pretty much only get sid, title, a link that is to your old nuke site, and the hometext (summary). If you are good with PHP and look up the specs on RSS, you should be able to pretty easily add the date, full text of the post, etc.

    Or if you are better at SQL than PHP and RSS, here is a link to the list of fields in the latest version of WordPress: Codex.

    As of right now that is:

    Field Type Null Key Default Extra
    ID bigint(20) unsigned PRI & IND Pt4 auto_increment
    post_author bigint(20) unsigned 0 FK->wp_users.ID
    post_date datetime IND Pt3 0000-00-00 00:00:00
    post_date_gmt datetime 0000-00-00 00:00:00
    post_content longtext
    post_title text
    post_excerpt text
    post_status varchar(20) IND PT2 publish
    comment_status varchar(20) open
    ping_status varchar(20) open
    post_password varchar(20)
    post_name varchar(200) IND
    to_ping text
    pinged text
    post_modified datetime 0000-00-00 00:00:00
    post_modified_gmt datetime 0000-00-00 00:00:00
    post_content_filtered longtext
    post_parent bigint(20) unsigned 0 FK->wp_posts.ID
    guid varchar(255)
    menu_order int(11) 0
    post_type varchar(20) IND Pt1 post
    post_mime_type varchar(100)
    comment_count bigint(20) 0

    Thread Starter Tim Nicholson

    (@timnicholson)

    Hi, David. Thanks for your quick response. I did try to let UpdraftPlus create a new bucket and I got the same error message when testing. I’m sure the S3 upload stopped working in the old plugin, which is why I upgraded to the new one. Just in case there was something wrong with my old access key and secret key, I created a brand new access key and secret key and that still didn’t work.

    Tim Nicholson

    (@timnicholson)

    Also, in playing with this on my test site I noticed that this theme conflicts with the Jetpack mobile theme option. I like Jetpack’s mobile menu much better (it says +menu, has a small search box, and the menu itself is shaded thus looking more like a normal drop-down menu). Jetpack also lets you choose post excerpts instead of full articles which is essential for a mobile site.

    However, with Jetpack mobile activated, it doesn’t honor this theme’s special home page feature (full width page with special widget area). I’d like to see this fixed so they work together. Especially since Jetpack and Twenty Twelve are both official Automattic delivered code.

    Tim Nicholson

    (@timnicholson)

    Thanks TomasM. Code looks good and simple enough. I happen to want 3 footer columns, just like you coded it. Thanks for pulling that together for us. Maybe WordPress will incorporate it for Twenty Thirteen or something ??

    I’d love to see the footer code determine how many widgets are assigned and set the number of columns appropriately. At least to support 1-4 columns (and be responsive as well).

    Tim Nicholson

    (@timnicholson)

    Also, to chime in on the browser compatibility discussion… I do understand why the theme designer would want to keep this default WordPress theme simple, browser compatibility is by far the hardest CSS coding out there and way beyond a typical user’s ability to address. So I feel that browser compatibility should be a huge priority in a theme designed for this purpose. This theme isn’t even distributed with WordPress core yet and there are hundreds of thousands of sites using it on WordPress.com as their *production* site theme.

    Tim Nicholson

    (@timnicholson)

    I’m certainly considering using Twenty Twelve as a parent theme instead of a “framework” because of its balance between features and simplicity. I don’t understand why this theme wouldn’t have a widgetized footer, though. Almost everyone is going to want to have a footer that they can control. I’d even like to see the ability to upload a footer image, just like the way you can upload a background image.

    I also love that this theme is responsive because in today’s day and age, everyone’s site should be expected to look good on a tablet or phone. I’d love to see this theme use a simple grid structure, though, rather than the hard-coded content and widget area. This would let us take advantage of the new static home page features to make a really nice layout with some simple styling. For example putting some elements in a two or three column layout.

    Thread Starter Tim Nicholson

    (@timnicholson)

    Right, the Gigya WP plugin is free. Also, Gigya is the only multi-login provider that let’s you get a valid session ID from the various social networks so you can make your own native API calls. Others charge for that. While the plugin doesn’t support native API’s (Twitter, etc.) you can use those without charge as well.

    Thread Starter Tim Nicholson

    (@timnicholson)

    Ok, I’ve got this all working perfectly in WordPress 3.0 at least. 3.0 DOES display the default maintenance message during an upgrade or mass update of plugins. I’ve created a maintenance.php file that overrides the default and displays a very nice landing page with a message and social networking links. If anyone wants to check it out, here is a link to my article on how to do it:

    https://xtremelysocial.com/2010/how-to-make-an-awesome-maintenance-mode-screen-for-wordpress/

    I just stumbled across this script, but haven’t tried it. I don’t think I have Python installed on my server, but it looks like a prety nice script. https://keskydee.com/wordpress/archives/710

    It handles users, topics, and stories. It doesn’t handle the content module, but it probably wouldn’t be too hard to add that.

    Note that it requires phpnuke and wordpress to use the same database. It also requires empty wordpress tables as it is going to import the data with the same keys (story number, user number) so that you can do a url redirect from your old phpnuke site to your new wordpress site.

    I have done more analysis on the WP 2.9 code and researched 3.0 functionality in the WP tracking system. In 2.9, there is only the ability to declare a custom post type and specify that post type in a custom query.

    In 3.0, declaring a custom post type will automatically create a link and post maintenance screen in the admin section for them. It will also let you specify whether the post type is publically queryable, whether it shows in search results by default, etc. 3.0 also allows you to create custom taxonomies (categories, tags) for the custom post types.

    So this makes sense with the general comments I’ve seen on these forums where people are saying they are going to wait until WP 3.0 when the “UI” (user interface) is built out. With 2.9, everything has to be hand-coded. With 3.0, some simple custom post type and taxonomy declarations will make these things immediately useful without a lot of custom coding.

    Thread Starter Tim Nicholson

    (@timnicholson)

    a1wsn, thanks for writing articles on this. Very helpful. Any clue as to why this maintenance mode page isn’t displayed during an actual WP upgrade?

    Thread Starter Tim Nicholson

    (@timnicholson)

    Anyone? Anyone? Bueler??

Viewing 15 replies - 181 through 195 (of 215 total)