zimmi88

Hmm… I’m afraid I haven’t used this particular tool before, so I can’t provide much insight into its use. Looking at the documentation (or, at least the documentation that’s publicly viewable), it appears that it doesn’t include itself at the plugin layer, but by asking the theme author to include an external resource (in this case a PHP script that presumably includes the other scripts necessary to make the tool run) in the theme’s functions.php file.

Ultimately, the theme extension would’ve had to been written in PHP in order to interface with WordPress and to run on the server. There doesn’t appear to be any installation instructions that suggest to the contrary (e.g. install this other technology, set up a separate install, et cetera).

But, once again, haven’t used this tool before, so I can only guess based on what’s publicly available. And, of course, you’ll need to determine for your particular scenario whether it’s most appropriate to use this tool, create a plugin (or set of plugins), or do this sort of customization at the theme layer by hand.

I hope this helps!

Well, I’d say the deeper you’re able to get with each of those technologies, the more flexibility you’ll have in creating unique WordPress-powered experiences.

At minimum, if you’re focusing on front-end theme design only, you’ll want a decent working knowledge of HTML and CSS. Thankfully, CSS isn’t too difficult to pick up (at its core, it’s a set of definitions… nothing more) and as you use it over time you pick up more tips and tricks that you can add to your toolkit.

Knowing a bit of PHP is also useful, but because many page elements are revealed to themes by template tags, it’s not necessary. That said, WordPress being built on PHP, the more you know of PHP, the more options you have with crafting experiences in WordPress. A working knowledge of PHP is essential if you’re looking into plugin development, and the ability to interpret source in other plugins and WordPress core doesn’t hurt when needed.

If you have experience with any other programming languages, PHP isn’t too difficult to pick up (its syntax is C-like) and there are a number of tutorials either online or in book form. I’d recommend checking your local library to see if they have any books on introductory PHP programming… it’s so ubiquitous, many libraries will carry at least one book on intro to PHP 5.

Long story short… HTML + CSS is needed to get started with theme development, and knowing a bit of PHP doesn’t hurt, either. For plugin development, you’ll need working knowledge of PHP.

I hope this helps!

Hmm… well, a look at the source on the homepage is showing some weirdness… it looks like your plugin/theme URLs might be getting garbled…

<link rel="stylesheet" type="text/css" href="https://ralstonandanthony.com/wp-content/plugins/simple-coming-soon-and-under-construction//themes/ourtuts/style.css" />
<script type="text/javascript" src="https://ralstonandanthony.com/wp-content/plugins/simple-coming-soon-and-under-construction//themes/ourtuts/js/jquery.countdown.js"></script>

…and yet neither of those URLs are throwing back any errors. Could it be the “simple-coming-soon-and-under-construction” plugin noted in the source (or is that new)? It seems that most pages are kicking back to the homepage rather than to login.

Mhmm… ok, so you have the Drupal database backed up and need to move the posts from that database into WordPress. As long as you have the SQL data from Drupal, you don’t need the old server… we just need some way to translate the old Drupal data into something WordPress can understand. WordPress can import posts from an RSS file (doesn’t have to be a live feed), so by transforming the Drupal SQL data into a set of RSS feeds using some sort of custom script (the languages and tech used for this data transformation are developer’s choice), we can use the RSS Import tool built in to WordPress to add the posts. (In retrospect, writing a full plugin might be a little heavy handed for this situation… sorry. Probably would be better going the RSS route.)

Perhaps I’m partial to a solution that uses WordPress because I’d rather have the WP engine handle the heavy lifting on making sure the posts get imported in working order, rather than muck about with the database. But perhaps another solution would be to match the Drupal data to the structure of WordPress’s database, then modify the post IDs to a high enough number set that they aren’t conflicting with WordPress. The wp_posts table uses auto_increment, so you should be able to easily find out the highest post number and start modifying the posts from Drupal so they’re n+1 to n+1+x, rather than 1-n, and then set the auto_increment value for the table to n+2+x. Haven’t done this method before, so I’m afraid I wouldn’t be able to provide much advice beyond that. =/

I hope this helps!

Ahh, ok… sorry about the confusion.

Was able to find this plugin in the WordPress plugin repository… haven’t used it before, but it looks promising:
https://www.ads-software.com/extend/plugins/user-submitted-posts/

I hope this helps!

Odd.. did you add any plugins or make any other site changes recently? I’ve seen plugins before that will modify WordPress’s behavior to do this. Also, is this behavior being exhibited across all posts and pages, or only specific entries?

One of my first guesses in general for unexpected “out of the blue” behavior is malicious activity, but the site check is coming back clean. Still, might be good to do a quick scan through your WordPress directory to make sure nothing appears out of the ordinary or modified suspiciously recently.

I hope this helps!

The WP_Query class supports the ability to query posts by their post meta value. You can create a new query object looking for posts with a specific bid_id and the is_awarded value of not_yet, then iterate through those posts, setting the post meta for the found posts to no.

I hope this helps!

Are you allowing users to sign up with the default role of contributor? When I’ve experienced this issue in the past, it’s been because the users were set to the “Contributor” role (so they could submit for review, but not publish). The issue is the “Contributor” role doesn’t allow media uploads by default, as media uploads are technically publicly accessible right after they are uploaded (there is no Submit for Review mechanic for media uploads) and probably because allowing media uploads from untrusted sources is risky.

If you’re okay with this, you can install a plugin such as User Role Editor to enable upload capabilities for contributors. That said, I’d be wary of doing this if anyone is allowed to sign up to be a contributor, for the aforementioned security reasons.

Otherwise, if you want to solicit submissions but don’t want to grant contributor access, you probably want to create a contact us form of some sort to accept entries. Search for “Contact Form” or “Contact Us” in the plugin directory… there’s plenty of options (here’s an example plugin… never used it before, but it looks useful enough).

I hope this helps! If this doesn’t work, or if I’ve misunderstood the issue, please post back.

In the SQL dump, did you get a usermeta table as well? That’s where access permissions are stored. You probably need to drop the usermeta table and use the usermeta info from the new installation.

Alternatively, assuming you have access to your database, look in the <dbprefix>_usermeta table. Look for an entry matching the user id of your site’s admin account and the meta_key “wp_capabilities”. If this entry does not exist, add it. Set the meta_value to a:1:{s:13:"administrator";s:1:"1";}.

I hope this helps!

Ahh, ok, I see the issue. Well… if all you’re doing is retrieving the content to be migrated over from Drupal to WordPress, and you have a fair understanding of how Drupal’s data is structured, you probably don’t need access to the old server… just the backup data. You could either…

• Deploy Drupal’s engine and data to a staging environment under your control from backup, then export as RSS. This can be on your local machine (XAMPP’s good for this) or a staging sandbox set up on your remote server. Note that as the URL will have likely changed, you might need to change a couple of settings in your staging DB to reflect this. Unfortunately, I don’t have that much experience with Drupal, so I’m not sure what settings you’d want to change exactly, but as a example from WordPress, when moving data from staging server to staging server, settings like site_url in wp_options needs to be changed (otherwise the links WordPress generates would point to the old site URL).
• Deploy the database only to a staging environment (for safety’s sake, I’d recommend a different database and db user from production if possible) and write a custom plugin/script as mentioned above to parse the data and import it into WordPress. Or, you could write the script to read the database and create an RSS feed (or feeds).

The goal here is not necessarily to get Drupal running again in any publicly available sense, but to find a way to transform the data from SQL or Drupal form into something WordPress can understand (RSS) or query (a database that WordPress can reach).

I hope this helps!

Hmm… well, you might be running into integrity constraints with some of the other columns. Are you importing from another WordPress installation or another blogging/CMS system? Probably the safest way to go about this would be to use the Import feature built in to WordPress. The feature takes in a WordPress XML file or RSS feed (or sometimes native data formats from other CMS tools… a full list is available from the Import menu) and creates the posts for you in the system.

If you’re having trouble using the import feature, either because the data size is too large or it’s taking too long to process, try breaking up your content into more manageable chunks of 20-50 posts at a time per data file, then import the files one by one. This may take a little while, but it’s probably the most straightforward way to get your content into WordPress without database errors.

Alternatively, if the import feature won’t work for you, the other option would be to roll your own import tool, probably as a plugin. That way, you can crawl the content from your old database and use wp_insert_post to add the posts into WordPress.

I hope this helps!

Sounds like there might be some malicious code lurking about (SiteCheck).

Did you install a fresh copy of WordPress, your theme(s), and your plugin(s)? If so, I’d recommend that as your first place to start.

For more information, check out the following resources for cleaning up your site…
FAQ: My site was hacked (WP Codex)
How to completely clean your hacked WordPress installation (Smackdown!)
Removing malware from a WordPress blog – case study (Sucuri)

I hope this helps!

Difficult to say… it would depend on the changes you made and the changes made in the latest revision of the theme. There are two possible issues I could see coming up in such a theme upgrade…

1. If the file you made your changes in is part of the update, your changes could be overwritten by the new version of the file. To check this, I’d recommend downloading a copy of your customized theme, a copy of the theme update, then using a diff utility (such as TortoiseMerge) to merge the changes from the update into your copy. Alternatively, if your changes are very light, it might be easier just to download a full copy of the latest revision, make your changes again, then upload your customized copy of the latest version to the server (after testing).

2. If your customization(s) were dependent on some piece of code (function, css rule, etc) that isn’t in the latest revision, you’ll need to make alterations to your custom code to reflect that. You can try searching for dependencies to make sure they’re in the latest revision or check the updated copy to a test environment to see if everything’s still working okay.

I hope this helps!

Hmm… well, you are appearing in results if you use the site: operator, so your site’s not being blocked.

Have you connected your site to Google Webmaster Tools yet? That system provides a number of diagnostic tools for, in a sense, seeing what Google sees about your site.

Looking at your robots.txt, it looks like your sitemap record is pointing to another sitemap which itself points to roofclean.pro. Dunno if that’s significant, but it might be a possible issue.

I’d also suggest taking a look at Google’s help site, which has info on their index guidelines. If your site isn’t meeting those guidelines, it could have an adverse effect on your site’s rank.

I hope this helps!

Hmm… I’m not seeing any reported errors and it looks like your page is getting styled ok. Could have been an intermittent error or something could be going on with your local cache.

Try refreshing and see if that helps. If the issue persists after a couple of hours, post back.