Forum Replies Created

Viewing 15 replies - 106 through 120 (of 225 total)
  • as long as you have your .htaccess file configured via your permalinks options in the wp admin panel, all should work as expected. for the /2006/07 type URI’s, just choose the default date/name based permalinks from your admin panel.

    as far as digging in a little deeper to see how it works, yes, all of the re-writing is handled by the wordpress code, not the .htaccess file.

    wp uses apache’s mod_rewrite, much of the actual magic happens in wp-includes/classes.php and wp-includes/template-functions-links.php

    if you don’t want any new “posts” to appear on the front page, consider using a plugin for a “static” page instead. then, each post will only appear within it’s category/archive location.

    does the site even use WP ?

    first, go to your theme’s .css file and create classes/attributes for various things you’d like to display.

    then, (i don’t know why you’re using \n or \t) try using ,
    , and &nbsp
    to position/format things as you’d like.

    also, if you take a look at the “extend” link above, i belive there are a number of plugins available for syntax highlighing/formatting, etc.

    i’ve done a number of MT/TP to WP migrations, if the div/class tags are embedded within the body of a post, you’re going to need to go back to each post through dashboard->manage->posts and edit each one, a pain, i know, at least you only have 150 posts, one of the imports I did had over 4000 posts spanning 3 years, i wrote a small perl script to make various changes needed to fix the many ‘quirks’ found after importing to WP. it’s probably not worth the effort to write/customize the script for only 150 posts though.

    if the tags are NOT inside of each post, but rather are the “post” tags themselves, you can then easily change/edit to your heart’s content from within your theme’s .php files using if statments to change the class name as needed.

    if you’re that your RewriteCond is correct (matches only OLD items), try:

    RewriteRule ^(.*)$ /legacy/modules.php$1 [R=301, L]

    it looks like you’ve got a column width set incorrectly in your css file somewhere, you’ll need access to edit the css file for your theme, check all of the column width settings, since you’re using a fixed width design, you’ll find that one of the columns is too wide which is what’s causing your problem.

    first, if you have phpMyadmin or a similar tool do a backup of your db tables, do one backup or dump with structure and data, and one data only.

    then, to recover the old blog, try the following

    first try editing wp-config.php so that the db_name, user and password match the old blog information. this simple change could be all that’s needed (unless of course you made customizations to your site’s files, in which case you’ll need to re-upload the edited files as well).

    if that doesn’t do it, then using the backup of the db you made, and the phpMyadim tool, import the old table data into the new database (you may run into an error because of duplicate ID columns, if that happens, just dump all of the tables (empty the database, don’t delete it), then restore using the structure+data backup).

    there are a couple of ways to approach this, if you’re comfortable with php, you can just use php’s date functions to print directly to/within the page/box. you could also get more complicated (which isn’t really needed, since the php date functions are pretty simple to learn if you’re not familiar with them) and use a perl or shell script as a cron job, and the date functions to figure out what month/season then write to either the Db or a text file, then have your page read whichever of those you choose. (a system like that is more suited for something like the random quotes, etc type things which would be updated/changed more frequently).

    have a look at the plugins area via the “extend” link above, i think there also may be a plugin or two available that either acomplish this already, or can easily be slightly modified to do it (quotes/random quotes plugins, etc).

    if you’re really feeling adventureous, you could write a simple plugin using php (instructions in the wp codex plugins section) to do it.

    you’ll need to edit several php files within your wp-content/themes/your-theme/ folder.

    you’ll need to add the following where you’d like the name/link to appear in each post:

    <?php the_author() ?>

    the files that you should edit (assuming your theme uses the “standard” filenames) are:
    index.php
    page.php
    single.php
    full.php
    post.php (or posts.php)

    as moshu mentioned, there are a number of iterations of the_author template tag, some print just the author’s name, others make the name a link to either the author’s email address or a page/profile, etc. you’ll just need to take a look at the codex and choose how you’d like the author’s name displayed then replace the_author() in the php above with which ever you choose from the codex.

    either write a perl script to cure the index problem by renumbering, or create a second WP install within the same db in a subdir like /old or whatever, and a new set of tables called something like wp2_ , those would likely be the two simplest (or quickest anyway) solutions.

    what server os ? hosting provider, etc ? check to see if the server has the MS frontpage server extensions installed, if it does, that’s the source of the problem. see the codex permalinks section if it does for the cure.

    are you using the wp-cache plugin ? what isp are you using ? who’s your hosting provider ?

    it’s likely that one of the above is the issue, someone is caching the old content somewhere along the line. if you want fresh content delivered with each request, you can try either the old method of setting “pragma nocache” in the headers, or the newer more preferred method for accomplishing the same thing using meta tags in your header php.

    I wrote a rather lengthy reply to a post a while back explaining the various methods used by isp’s and hosting companies for caching content to conserve bandwidth, and the related problems that causes with WP, I’m not going to rewrite that here,but I should probably spend some time getting that info added to the codex, since this issue seems to pop up relatively often.

    first check to be sure all files are in the correct location, then check the permalinks configuration from the dashboard, check to see that all files have proper permissions set.

    There are many different ways of accomplishing the same result that it looks like you’re aiming at, which is the ability for a user to choose a “personal” look and feel for your site. That’s a great feature, especially for a site which would discuss css styling.

    However, personally, I would focus on writing valid standards compliant code (which also eliminates most cross browser issues) before trying to get fancy with the style switching (there are a number of plugins available which are capable of producing standards compliant code as well, which is a nice bonus for that type of effect).

    Here are the w3c validator results for your existing xhtml and css files:

    http://validator.w3.org/check?uri=http%3A%2F%2Fdearauthor.com%2Ftech%2F%3Fp%3D4

    http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fdearauthor.com%2Ftech%2Fwp-content%2Fthemes%2Ffoliage_mod2%2Fstyle.css&usermedium=all

    http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fdearauthor.com%2Ftech%2Fwp-content%2Fthemes%2Ffoliage_mod2%2Fstyle175.css&usermedium=all

    http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fdearauthor.com%2Ftech%2Fwp-content%2Fplugins%2Faf-extended-live-archive%2Fincludes%2Faf-ela-style.css&usermedium=all

    for me at least, a good part of the reason for using xhtml/css to begin with is to make my life easier by producing standards compliant, accessible, cross browser compliant code, thus eliminating any extra effort required to do such things as “tailor” separate style sheets for each browser, then attempt to make that system work with javascript which is not likely to work with all of the browsers the “special” css is written for anyway.

    standards, standards, standards.

Viewing 15 replies - 106 through 120 (of 225 total)