Dragons Eye

You can actually delete the WordPress files themselves from your public folder, or wherever your local website loads from when you start up your server system. You CAN over-write them, though, by re-extracting the WordPress files from their archive file, but you will need to re-enter your database and user info in the “wp-config.php” file prior to re-installation.

As far as your MySQL databases,

If you still have access to them through PHPMyAdmin, you can easily manipulate and/or delete them when you view the “databases” by clicking on the databases tab. You should see a list of databases in tabled-format with a check-box by each one. You just check the box for each database you wish to remove, then go to the bottom of the page, while still in PHPMyAdmin, and click on the button that says “drop” (their term for “delete” a table or database). After you confirm what you want, this should delete or “drop” the tables you have selected.

You would probably want to delete the tables rather than the whole databases if you have plans to reinstall WordPress on your server, though. You can do this by viewing the tables within a database. This you would need to do within each database. This would preferable if you wanted to preserve the actual databases and their associated users.

You can also change the passwords of the database-users from the PHPMyAdmin control panel under “users – edit privileges”. Just be sure to enter the correct password into the “password” variable in your “wp-config.php” file too. Should do this all before you execute WordPress’s installer again.

– Hope this helps!

Not too sure if this falls in line with the topic,

But, I have my website installs on SD-cards, so that I can switch them out as each one has a different website on it. I did this through LAMPP (“XAMPP-for-Linux”) by altering the “DocumentRoot” directive in the httpd.conf file to point to the location of the SD-card (in my case: /media/<user>/HTDOCS). The only draw-back: The SD-card (or whatever removable media you are using) needs to be labeled “HTDOCS” (or whatever name you used for it in the httpd.conf file).

However, it works well for me, and I can change out the card for a different one for working on a different website project.

On LAMPP if you change out the card or removable media, you MUST stop and restart Apache, as each drive or removable has a different UUID code associated with it! (Regardless if they are labeled the same name or not.)

If you are looking for how to do it in the .htaccess file,

This one works:

<IfModule mod_suphp.c>
# Change path to where YOUR site’s “php.ini” file is located.
suPHP_ConfigPath /root/user/www
# Be sure to protect your “php.ini”
<Files php.ini>
order allow,deny
deny from all
</Files>
</IfModule>

Whoever said the suPHP is discontinued, needs to realize that most of the major web-hosting providers run such secure services like Fast-CGI, etc. from Apache. BTW: If you set up your .htacess this way, you MUST have a “php.ini” for your site as pointed to by the ConfigPath variable. YOU are responsible for the proper settings of the various PHP-environment variables to include the “include” file locations, whichever additional Apache modules you wish to preload and use, etc.

But YES, this is how you secure the execution of your PHP scripts, for your whole site if you wish.

– Dragon’s Eye

Unfortunately,

On later testing, it did the exact same thing on my own local-host set up. I have no such settings on my XAMPP installation.

This seemed to do this on every HTML page (no matter the size) that I tried to import. Therefore, I just settled to manually copy-and-paste those pages from another editor (like my page editor).

** Meantime, you can ensure that on your live environment you’re not outputting these warnings by ensuring error_reporting is set to E_ALL ^ E_NOTICE:

error_reporting(E_ALL ^ E_NOTICE); **

I like the thought, but I would not recommend this action. I say this because if the folks who develop PHP, one day, decide to make some of those conditions “critical errors”, due to deprecating certain methods, this would become a “stopper” instead of just a “warning”.

Also, to add to “Lorem Ipsum’s” thoughts above, I would rather not disable the error-level warnings because I use those messages to help me clean up my own code.

As to the non-implementation of a font-select option, I know this can be done through PHP and HTML on the widget side. This may become a desired feature, based on the feedback from other users. This would have little effect as far as the WordPress install is concerned. It was just a “floating of ideas”. Also, the Tiny MCE portion does, in fact, support font-selection.

Anyway, I have found the plugin that best suits my purposes. All projects evolve over time, so I look forward to what features will become in future releases. ??

– Jim

** Okay… I’m a little confused after your posts above… **

Sorry about that! I sometimes get a little “wordy” when I am on a roll.

** Where do you stand with this? **

I’ve got it working, though I had to manually install it by extracting to the “plugins” folder as suggested in the little “readme” text.

If I need to color any section of text, I noticed that if the text has bold or italics attributes set, the color does not get set. This means I end up going to HTML tab and move the style “color: #??????” out of the “span”-tags, and into the “em” or “strong” tags instead – in order to see the text “colorized”. I usually have problems setting some text attributes within “span”-tags for some reason. I am not sure if it is a Mozilla problem, or if there is some other issue with “span”-tags being mixed with other tags like “em’s” and/or “strong”-tags.

I have encountered a few issues like this one when working on some other webpages and styles I have written. ( Some by source editing. )

It might be that FireFox is not properly implementing some of the styles properly. This has been a problem since version 10, while I am now running version 17.0.1 (FireFox).

However, this plugin seems to running okay for me now. I had to FTP it to my live site because of the upload-size restrictions from my hosting service though.

– Jim

Forget about the last post.

The little text “readme” file helped me out. Seems that the folders created in its entries in WP’s “upgrades” folder was missing a lot of files. So I manually extracted the contents of the zip-file into the right “plugins” folder as suggested.

Seems a few plugins still give me trouble if I use WP’s “upload and install” features. So I guess I am going to have to try manual extraction-and-install if all else fails me?!?

Looks pretty good here!

I am not sure if this a FireFox issue, or what: I end up having to move the font-color style properties to a different tag from the “span”-tags because if they are styled within span-tags, I see no change in the font colors.

Is there a way for me to change where these style “color: #??????” property settings are inserted?

– Jim

Update:

It is NOT installing on my machine under this version of WordPress either!

I guess I need to figure out how to do a manual install of it.

What a shame!

I am beginning to wonder of WinDOZE is a part of the problem? I should be having no problems installing it on my local machine under XAMPP.

I don’t get it.

– Jim

I do have a question for you, Josh.

I am going to have trouble installing this plugin to my live site because the webhosting provider limits upload sizes to 2 MB. This I can not get around because it is one a free hosting account (for now, anyway).

How else will I be able to install it to my live site?

I have not checked to see if WordPress supports any other archive formats, or any higher-level compression ratios that are greater than the recognizable “inflate/deflate” compression ratio.

Any ideas?

– Jim

Would THIS help you out, Greg?

Author of TinyMCE Advanced

And his project page is here.

Usually, the number one expert in a plugin, is its very author. ??

– Jim

Hmmm!

I don’t recall the one working on my website now being based too much on jQuery? I will have to take a closer look at its coding then.

** But the Analog JQuery clock (divs) and the Old School clock (ul+li) on https://www.jqueryrain.com/2011/11/14-best-jquery-clock-tutorials-both-analog-and-digital-clocks/ seem to be doing what you are thinking about ?? **

So are you saying the one that operates within “div”-tags seems to be working for you in IE?

Funny thing is, my website main is DOCTYPEd “XHTML 1.0”, yet FireFox STILL renders it properly within a “CANVAS”-tag! This is very strange indeed! I know FireFox (from versions 10.0 and newer) have a few other bugs that have crept in, and have not been resolved YET.

I might check out a few other variations to see what works the cleanest and, hopefully, on all the available browsers. I haven’t used IE in so long because I don’t like the fact that it still has gaping security holes in it. So I couldn’t help you much further on issues of IE-compatibility.

I’ll have to check out the jQuery version of it as I am getting interested in jQuery, myself.

I’ll try and find out some other things that may be some help!

– “Cheers!”

– Jim

Actually, it seems that most of the plugins I have tried would not install on version 3.5 of WordPress.

I usually try them out on my XAMPP system first.

I ended up having to uninstall v 3.5 and rollback to 3.4.2. That solved most of the problems I had with many plugins. This is to be expected sometimes with the newest versions of software.

When I try out this plugin again, I will be sure to let you know what’s up.

Thanks for the response.

Hmmm!

I even learned a little something from this! I had forgotten completely about the CSS “import” directive.

The thing I usually did is just backup the modified CSS file(s) and then rename the newer CSS files so that mine will continue to work on the new theme when I go to copy them back to the original theme folder, but the other idea made a lot of sense!

Thanks from me too!

From my issue, I would consider it resolved by a “work around”.

As for it not properly working with the newest version of WordPress, if there are other similar complaints with this version, that may say differently.

As far as I am concerned, I am sticking with 3.4.2 for the time being.

Anyway, thanks for the feedback.

??