How to import articles/pages?
  • How can I import articles and pages into the DB of a freshly-installed TangoCMS from another TangoCMS DB without borking the new installation? I've tried moving the appropriate tables over, but that just causes all the URLs on the new installation to give me TangoCMS's 404 page.
  • You'll more than likely have to clear the TangoCMS cache. This can be done by going to "Settings -> Cache & Performance". Once done, it should all work. If not, let me know
  • Do you mean before or after I move the DB tables over? If after, then is there a manual way to clear the cache? Because like I said, once I move the tables over, all URLs give me Tango's 404. So I can't actually get into TangoCMS to clear the cache in the settings section (unless you mean to clear it before moving the tables over, which I'll try...).
  • *all* URLs? Eh, that shouldn't happen. But yes, if you're using the default file cache then you can safely remove the ./tmp/cache directory.

    What tables are you copying over? Are you trying to merge to TangoCMS installs, if not - then why not just copy all tables over, and your configuration directory (./config/default) and away you go? =)
  • Deleting that cache directory didn't make any difference. These are the tables I copied over:

    tcm_layouts
    tcm_modules
    tcm_mod_aliases
    tcm_mod_articles
    tcm_mod_article_cats
    tcm_mod_article_parts
    tcm_mod_comments
    tcm_mod_contact
    tcm_mod_contact_fields
    tcm_mod_media_cats
    tcm_mod_media_items
    tcm_mod_menu
    tcm_mod_menu_cats
    tcm_mod_page
    tcm_mod_poll
    tcm_mod_poll_options
    tcm_mod_poll_votes

    And yes, I'm essentially trying to merge installs. The config table and user data got destroyed when I tried to fix some file permissions that my web host broke, but I managed to save the rest of the DB. If I need to manually hack up some rows/cells/ids in the DB, that's fine, I'm no stranger to SQL, but I don't really know TangoCMS's structure very well.
  • So when you go to /session, or /users in your browser all you get is a 404 page generated by TangoCMS? Are there rows in the tcm_acl_{rules,roles,resources} table?
  • "So when you go to /session, or /users in your browser all you get is a 404 page generated by TangoCMS?"

    Yes.

    "Are there rows in the tcm_acl_{rules,roles,resources} table?"

    Yes, 108 in resources, 213 in rules, and these 4 in roles:

    id name parent_id
    1 group_guest 0
    2 group_member 1
    3 group_admin 2
    4 group_root 0
  • And your tcm_modules table has rows in as well? Beyond this, I really don't know what is going on I'm afraid. I can try to help further if you would like to provide me with either access to edit the files (so I can do some debugging) or if you want to provide me with the database so I can try it locally here. If so, email it over to alex@tangocms.org
  • "And your tcm_modules table has rows in as well?"

    Ahh, that was part of the problem. That table was empty. If I leave that table intact from a fresh installation, and copy over the rest of the tables I mentioned, then I don't get the 404's anymore.

    However, none of the articles or categories are showing up (except for my "Meta" category, but it's showing up as not having any articles). And all of the articles/categories *are* in the DB, in the tables tcm_mod_articles, tcm_mod_article_cats, and tcm_mod_article_parts.

    Since I'm using all the old articles/categories, but on a new installation with a new user account (although it's the same user name), is there maybe something I need to adjust to associate the articles/categories with the new account?
  • Actually, the "author" column in all the rows of tcm_mod_articles *are* already my correct user ID (unless it's supposed to be the ID for the guest account?). So I guess it must be something else.
  • Try clearing the TangoCMS cache by going to Settings -> Ccache & Performance, which should now work =)
  • Well, I can clear the cache through the admin panel now, but that didn't help :( Actually, there wasn't anything cached anyway. Tried disabling the cache too, didn't work.
  • Ok, I just see that you didn't copy over the tcm_acl_{resources,rules} tables which will most likely explain this. If an ACL resource does not exist, then the article category will appear as if it doesn't exist.

    What does "SELECT COUNT(*) FROM tcm_acl_resources WHERE name LIKE 'article-cat%';" return?
  • Ahh, I think I'm starting to get the hang of TangoCMS's DB now. I didn't copy over the original tcm_acl_{resources,rules} tables because they had been clobbered along with the account and settings data.

    So, my tcm_acl_resources table had one article category entry: "article-cat-1", which corresponds to the id of the one category that is showing up. My tcm_acl_rules table had two rows for article-cat-1: One granting access to 'guest' and one granting access to root.

    I added similar entries for the rest of my article categories to those two DB tables, and now those categories are showing up as well. Still no articles yet, but I kind of expected that since, so far, I've only granted access to the categories. So, about getting the articles working:

    I assume the articles themselves work similarly to the categories, right? If so, what's the format of the names for the articles that I should use in tcm_acl_resources? Is it "article-{id# of article}"? Something else? Or does it work on the basis of article *parts* instead of articles? Or do I need to grant access for *both* the articles and the article parts?

    On a related note, I have a suggestion/feature request: The setup pages should have, in addition to "Install" and "Update", there should also be a link to *just* check all the file/directory permissions without reinstalling or changing anything.

    That's how I managed to screw up my original DB in the first place: My web host switched me to a different server, but they screwed up my file permissions. I didn't know how the permissions were supposed to be set, and I remembered that the necessary file permissions weren't really documented. But I did remember that early on in the installation process there was a part that automatically told me what files/dirs needed to be setup for R/W access and which of them were already working and which were not-yet-working. So I thought I could *just* run that part of the installation process and not actually finish a reinstallation. But by the time I realized what was really going on, it had already wiped a few of my DB tables. And yea, I know I should have had a backup, but I didn't think to since I wasn't expecting to make any DB changes at all: I was just thinking "Setting up file/dir permissions...".
  • Glad you seem to be getting it sorted :)

    However, articles & article parts don't have any resources - just their parent categories. If you have permission to view the category, you have permission to view the article. But you're saying you can view all the categories, but no articles in there?

    For your suggestion, you could just put the install/setup directory back and attempt an installation. If there are permission errors then it will tell you, if there isn't then it will continue the installation to the database stage - of which point you just go to a different URL/close your browser/grab a tea etc. In theory anyway =)

    You should always have a backup, especially with a host that does something mad like that
  • "But you're saying you can view all the categories, but no articles in there?"

    That's right.
  • So any ideas?
  • Not off the top of my head. Are you sure the tcm_mod_articles.cat_id value matches those in tcm_mod_article_cats.id?
  • Yea, those match. I also tried clearing the cache.

    They *do* show up in the Manage Articles section of the Admin panel, FWIW. That did make me think to check the "published" column of tcm_mod_articles, but those are all set to 1, which I understand should be right.
  • And what is the URL you're going to that the articles don't display on?
  • Any of them in the main site.

    article/
    article/cat/{category identifier}

    And if I go to "article/view/{article identifier}" on a valid article, I get a blank page (literally, zero-bytes, not even any HTTP headers, just an HTTP status line of "HTTP/0.9 200 OK"). If I do it on an invalid article though, I correctly get TangoCMS's 404 page.
  • And there was nothing added to the error_log
  • That'll be PHP and/or your webserver segfaulting.

    "HTTP/0.9 200 OK" .... 0.9? Your host/client is messed up. There is so much funky behaviour going on with your host that I really would not advise you stay with them, they sound like they have no idea what they are doing.

    I can't help anymore on this I'm afraid, nothing makes sense and the fact that PHP is segfaulting is not a good sign.
  • It's HTTP 1.1 on all other pages it serves, including all other TangoCMS pages. *Only* the "article/view/{article identifier}" is giving 0.9, and only when {article identifier} is valid. And it all worked before I went and damaged my original DB.
  • Well, I know what you'll be doing next time ;) Backups
  • You know, I already admitted I know I should have had a backup. I don't appreciate you repeatedly rubbing it in.
  • I've partially tracked down the issue on the "article/view/{article identifier}" pages:

    On those pages, it dies when the View for the captcha module (not the recaptcha one, although I haven't tried recaptcha) tries to substitute any of these: "{URL_ADMIN}", "{URL_MAIN}" or "{URL_CURRENT_ST}".

    If I disable captcha, then the "article/view/{article identifier}" pages work. Or, if I keep captcha enabled, the page will work if I change line 340 in application/libraries/View.php (TCM v2.6.1) from this:

    $tmpViewContent = str_replace( '{'.$tag.'}', $val, $tmpViewContent );

    to this:

    if($tag != "URL_ADMIN" && $tag != "URL_MAIN" && $tag != "URL_CURRENT_ST")
    $tmpViewContent = str_replace( '{'.$tag.'}', $val, $tmpViewContent );

  • You're going to run into other issues with that tweak that rely on those tags.

    I recall this issue, someone had it a while back and I wasn't able to replicate it on the 3 different test environments I had at the time. PHP segfaults are not fun to track down and sadly your tweak is not where the issue is, but further within the framework.

    IIRC, reCaptcha will work without any modifications to the code.
  • Right, I wasn't proposing it as a fix, just demonstrating where it dies, and under what conditions.

    When I get a chance, I'm going to try it on my local system, see if maybe I can figure out some PHP versions that are/aren't affected. The server I've been running it on is PHP 5.2.16 and Apache 2.0.63 (Yea, those might be somewhat old, but a lot of shared hosts like to be conservative about updates so they don't break people's existing apps. PHP in particular is notorious for subtle changes in different versions - even different installations of the same version, and it's not just the well-known PHP4->PHP5 change.)
  • I never got around to tracking it down any further, but my host recently migrated my account to another server (this one with PHP 5.2.17 and Apache 2.2.21) and it's working now, so I'm satisfied. Thanks for the help!

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

Tagged