Forum Replies Created

Viewing 15 replies - 256 through 270 (of 1,808 total)
  • Thread Starter abletec

    (@abletec)

    Hi, Marcin. I think likely the easiest solution is simply to implement a custom product type, ie, a mixed or flex product for this, 1 where the characteristics of both simple & variable products can be accessed. The advantage to Jigoshop, of course, is that, if my research is correct, there are quite a few folks on the net asking for such a feature, & it would give your plugin a way to really stand out from Woocommerce & not be simply a “me, woo” plugin, as it were. I’m not trying to be disrespectful here–far from it–but when I initially installed Jigoshop, my 1st question was, “What’s the difference between this & Woo?” Having a stand-out feature can’t hurt–& I think could really help JS to gain some traction. Just thinking aloud, which for me is always a dangerous thing.

    Hello, drythighs, & welcome. You can use an ftp client like Filezilla to do this, or you can use your hosting provider’s file manager, usually accessed via its control panel.

    You can deactivate a plugin in this way by simply renaming the folder, ie, by putting a 1 or a .old at the end of the folder name. You can deactivate all plugins, if necessary, by doing likewise to the plugins folder.

    If you need further help, please let us know. Please also let us know if/when your problem is resolved, so the volunteers here understand you’ve been helped & can go on to assist others. Thank you.

    Thread Starter abletec

    (@abletec)

    Perhaps, Marcin, & I’ve thought about that. From the point of view of changing product prices & stuff, though, it seems like product variations would make all that easier, would it not?

    Thread Starter abletec

    (@abletec)

    Hello, Marcin, & thanks for your reply. Here is the scenario. The business is a silk flower shop. She basically has 19 different products, ie, bridal bouquet (both round & cascaded), maid of honor bouquet, toss bouquet, various decorations, etc. She groups these by attributes, ie, coral-ivory-cream, orange-fall-cala-lilly, black-orange-daisy, red-blue-white, etc. So a variable product would be the ideal setup for this. But once a customer goes to a page w/products having a chosen attribute, then only those products should be displayed. I hope I’m making myself clearer now?

    Thanks again, & have a blessed day!

    tamadon, here’s a separate post that might help you fix your site.

    A resource you can go to is:
    http://codex.ww.wp.xz.cn/FAQ_My_site_was_hacked

    When dealing w/a site compromise, the objectives are twofold:
    1) Fix the site; &
    2) Fix backdoors that the hacker used to gain entrance into your site, so this hopefully will not happen again.

    Most people place great emphasis on objective #1, but, in truth, the 2nd one is actually the most important, as, without it, your site will continue to be reinfected.

    Here are the steps to take.

    First, notify your host, as this might be a serverside hack as opposed to simply a site compromise. Also, if you’re on shared hosting, the hack has the potential to compromise the entire server. Additionally, you may wish to take the site offline, & your host can help you do this. They might not help you–then again, they might. You won’t know unless you notify them. If they say it’s not their responsibility, (& it really may not be), then please continue reading.

    Second, scan any devices you will use to log onto your website for malware (malicious software like viruses, etc). It does no good to follow these steps if malware phones your credentials home to their command & control center. It’s actually better to do more than 1 scan, each using a different program, as no single malware scanner can detect everything.

    Third, secure your network. Definitively use secure FTP (file transfer protocol) as opposed to regular FTP. The port used for secure FTP varies from host to host. Many use port 22, some 2222, while others use different ports altogether. Check their knowledge base or call their support. You can ask this question when you notify them of the compromise in the first step. You can use a client like Filezilla, which can do secure file transfers.

    Never log onto your site using a public WiFi hotspot, such as those in hotels, cafes, etc. Make sure you’ve changed the default password, Ssid, (&, if applicable) the username on your router/modem. If you don’t use wireless, turn it off in your router’s options.

    All these steps are required to ensure that no one can snoop your credentials, etc.

    Now that the device you’ll use to fix your site, as well as your network, is secure, it’s time to direct your attention to actually fixing your site.

    Next, please log into your website hosting provider’s control panel from a secure connection and change all passwords, including those to any databases you may have set up. This includes your control panel/FTP credentials & your WordPress database. Also, change your salt keys as per the instructions in wp-config.php to log out all users. Please make the passwords long, containing upper & lowercase letters, numbers, & punctuation.

    Next, take a backup of your website’s files. Be certain to label it such that the label contains both the date you backed it up on, as well as the word “hacked”–we certainly don’t want you accidentally restoring this backup! This can be helpful, though, in terms of perhaps being able to determine how this occurred, though my feeling is that it likely did so because of an outdated site, weak passwords, or unmaintained 3rd-party plugins or themes on the site. Probably you should just back up your web root. Depending on your host, it might be called public_html, htdocs, www, or /. If you don’t wish to back up the entire root, then at least back up your uploads folder, as well as others that might contain content that can’t be replaced.

    Please also back up your database as well. The article at
    http://codex.ww.wp.xz.cn/Backing_Up_Your_Database
    shows you how to do that, in case you need it. The section regarding phpMyadmin is likely the most relevant to your case. It’s going to be necessary to search that database file to see if any evidence of the hack exists there. That can be done by opening the file in a text editor. To start off with, consider searching for the words:

    <script
    <? php;
    base64;
    eval 

    preg_replace
    strrev

    This is not an exhaustive list, nor is the presence of any of these words conclusive proof of a site compromise, though some are more suggestive than others.

    You might also wish at this point to backup your WordPress content. To do that:
    * Log into your WordPress dashboard.
    * Go to ‘Tools > Export’.
    * Choose to export all content.

    While in your dashboard, go to ‘Users > All Users’ and delete any users there that you don’t recognize, especially administrators. A WordPress account should never contain the username ‘admin’. If yours does, make an administrative account that does not contain the word (don’t forget to use a very strong password), then delete the old admin username account.

    Also be advised that sometimes supposed image files can contain code, so open all your image files, particularly in your uploads folders, to ensure they really are images & don’t contain code. Better yet, if you have the images on your machine, replace files in the uploads folders with them.

    If you find nothing, either in your database or in your /uploads folders, then the next step is to delete, then completely reinstall WordPress, as well as any plugins or themes you were using. Simply reinstaling WordPress from the dashboard is not effective. I also advise creating an entirely new database w/a new user & password. You can then import your content into the newly reinstalled site.

    Please also let someone knowledgeable look at your .htaccess file so they can make certain no backdoor code exists there.

    In summary, here are the steps:
    1) Back up your WordPress files, including core, themes, & plugins;
    2) Back up your database using PhpMyadmin;
    3) Look through the database to insure there is no evidence of the hack;
    4) Search the uploads folders for image files that contain code;
    5) Let someone knowledgeable look at your .htaccess file.
    6) If you have doubts about your database, please have a professional take a look.

    It would also be helpful to install a plugin like Sucuri or Wordfence to scan for the compromised files.

    Hello, tamadon, & welcome. I suspect the reason for it is that your site has likely been compromised. The folks at ww.wp.xz.cn do not have the ability to create administrative accounts on peoples’ sites, & also probably wouldn’t use a username of ‘administrator’ even if they di.

    Please delete the user, also please change all your passwords on your dashboard, your hosting control panel, & your WordPress database to something impenetrable, ie, make it long & w/upper & lowercase letters, numbers, & punctuation marks. You may well need to reinstall WordPress, & you should check your database to ensure it hasn’t been compromised in the process.

    Please let us know if you need additional help.

    Hello, Jeff, & welcome. My first thought it you should check to ensure that mod_rewrite is operational. It sounds as though it is not, &, if it isn’t, then “pretty permalinks” won’t work.

    Please let us know if you need further help, or, conversely, if that in fact worked.

    Hello, redjones, & welcome.

    If you look in your public_html folder, you’ll likely find a file named index.html or index.htm. Because a .html file will display before a .php file, you’re seeing this behavior. Rename the file to index.htm1 (that’s a #1, not an l), & that will help. The file may also be called home.htm/html or default.htm/html. Either way, renaming the file will solve your problem.

    When you’re ready to make your site go live, copy the .htaccess file in your app folder to your public_html folder. Also copy your index.php file from app to public_html, but make the following change on the last line:
    require('./app/wp-blog-header.php');
    w/o the , of course.

    That’ll get you up & running. Be sure to let us know how you fare, &/or if you need further assistance.

    Eric, sometimes that just has to be done. Congratulations on that executive decision! You can export the posts & stuff if you’d like, but I think you made the correct choice.

    Eric, if at all possible, please try to get that database size down. That’s surely creating strain on the site. WC transients are often a big cause of this, but revisions, plugin tables, Akismet history, spam comments, & other entries not needed to keep the site running can also contribute to make the database excessively large. So can wp-seo entries, IMO.

    Do you perchance have any options using Godaddy to use Nginx as opposed to an Apache server (I assume you’re using Linux, you didn’t really say, & you strike me as one who knows well what you do when you assume :)). But Nginx, when configured properly, can really cut down on memory usage.

    In terms of the cron job, what I do is add an entry to wp-config.php per the following:
    define(‘DISABLE_WP_CRON’, true);
    & then I set it to run every 30-60 minutes in a control panel cron job. This prevents a lot of unnecessary reiterations of wp-cron. Normally I set it to run every hour unless there is a specific need to do otherwise.

    Eric, Thanks for the detailed reply. That error indicates wp-seo fell over in a screaming heap as opposed to Woocommerce. I personally don’t view it as a strictly necessary plugin, but that’s a choice each site owner needs to make.

    Do you know if you can set up cron jobs in your Godaddy hosting control panel? Meanwhile, please consider reviewing your plugins & getting rid of those you don’t need. You may also wish to look at your access logs & see if there are visitors trying to hammer your site w/brute force or vulnerability scans, &, if so, to erect some security measures to stop those.

    If Godaddy permits cron jobs, then we might try disabling wp-cron in WordPress & running it as a cron job via the control panel instead. This can sometimes help w/these types of problems. You may also wish to set up caching on the site if you haven’t already done so. Since you haven’t provided a site url, it’s hard to know whether that’s been done or not. That can create its own set of problems (I can’t count the number of support requests I’ve responded to where caching was implicated), but if you’ve studied the solution & configured it well, it can be very helpful.

    Lastly, you may wish to check your database size & do some thorough house-cleaning, ie, revisions, unnecessary plugin tables, etc. It goes w/o saying–except it doesn’t–that you should back up your database at the start of the process & several times along the way as cleaning measures whittle it down. You never know if the next 1 will make the whole site fall over.

    I hope this proves helpful.

    Hello, Eric. There’s a lot you don’t tell us here. For example, is this shared hosting, VPS, or dedicated server? What is your hosting provider’s operating system? What version of PHP, SQL, & WordPress are you running?

    In cases like these I often change WP_DEBUG to ‘true’ in wp-config.php. That’s a security risk, as you’re likely aware, so please change it back when you’re done. Meanwhile, though, you might see what errors, if any, are being thrown.

    If you have a VPS or dedicated server, then there are error logs in multiple locations, depending on which server you’re running. There may also be an aplet in your hosting provider’s control panel called ‘errors’ or ‘error logs’. Lastly, there may be files called error_log or error.log in your WordPress folder &/or subfolders. Check to se if they have any relevant entries.

    You might also try switching to a default theme to see if the errors go away, but, because of their intermittent nature, these are always tough to troubleshoot. It’s why my hair is short & why I absolutely will not get a talking bird, as they’re entirely able to imitate to the very emphasis on each syllable exactly & correctly what I said in the thick of trying to troubleshoot these sorts of issues.

    Please let us know in your next reply the answers to the questions I posed, & perhaps we can be of better assistance.

    Hello, Michael, & welcome.

    Before going into a long diatribe, I just wanted to ask if you’ve gotten help w/this?

    Hello, Ron, & welcome. Were I you, I’d be looking very closely at my server error logs. There is a lot you don’t tell us here, ie, what distro of Linux you’re running, which webserver, which PHP version, etc.

    1 thing you might try to do is disable plugins & try the update. If it flies, you know for sure that a plugin is causing the conflict. The question, of course, is then to try to find which one(s) is/are causative. Again, error logs may help, or you might look initially at those plugins which havent been updated by their developers in awhile.

    What is your memory limit? You may wish to try raising that & see if that helps.

    Truthfully, I’m rather stabbing in the dark, simply because there’s so much information we don’t have, but those are some starter thoughts. Feel free to post error messages to your next reply, but please make certain any user credentials aren’t included, if applicable.

    Please let us know if you require further help.

    Hello, SeanBanksBliss, & welcome. Truthfully, w/o a site URL, anything one can say is mere speculation. It could be you’re exceeding the size of your host’s database. It could be your site has been compromised (I’ve seen behavior like that when a site’s been hacked). If you’re running a caching plugin, that could be causative. It’s just very difficult to do any sort of investigation w/o the url of the site in question, unfortunately.

Viewing 15 replies - 256 through 270 (of 1,808 total)