I'm having a heck of time trying to get comments to post to my nodes. I've done all the obvious:
Enable comment module,
set appropriate permissions,
etc.
But every time I try to enter a comment it simply redirects to a "Add new comment" page and nothing gets posted. There is no comment in the Content -> Comments section and my database comment table is empty.
The only thing I can find relating to the issue is an error report in my log messages which displays a warning "page not found." I'm using the Drupal Busy theme.
Type: Page not found
Location: http://mysite/public://color/busy-0970ccd8/style.css?m
Message: public://color/busy-0970ccd8/style.css
Severity: Warning
I've ran the schema module and nothing is funky in with my database. Any thoughts on this? Much appreciated.
It's looking for a stylesheet from the Color module. It would normally be at sites/default/files/color/busy-0970ccd8/style.css
Do you have a sites/default/files directory? Check that you have one at that the directory is writable. Also check to be sure that the color module is enabled. Save your theme settings and clear your cache in configuration -- performance.
I'm not sure if a problem retrieving a style sheet from the color module could be causing this. Seems very unlikely.
You might consider not using the busy theme. It's current status is "minimally maintained" and the theme authors have left a note on the project page that there will be no further development at this time.
I recommend looking for a theme that is actively maintained and has good support. It looks like Busy is a pretty standard 960 grid, you might like Omega.
Related
I just wrote a long and detailed question and when I was about to submit it, I fixed the problem by myself. The problem did cost me about 5 hours and now I will just post this little explanation, so maybe it helps others and they will not feel as stupid as I do right now.
In my defense: I do not have that much experience with this system.
What was the Problem? When did it show up?
Before I change a file on the server, I always duplicate it and change the file name to originalFileName_yyyymmdd_hhmm.php (filename + date + time). I want to keep track of the changes, and when we launch the website, I wanted to do a local backup and then delete them from the server.
Let's say, in the folder of the active theme there is a file called home.php.
It is a template file, which means that you can select it as a template for a page when editing it in the backend of WordPress.
I duplicated it and called the new file home_20180301_2300.php.
Then I edited the home.php, but the changes were not displayed on the website.
I checked for any known cache issue, but that was not the problem. So I installed a debugging plugin (Template Debugger) to see which files are used by the server to create the website.
Wordpress used the home_20180301_2300.php instead of the home.php and I did not know why. When I deleted home_20180301_2300.php WordPress did NOT use home.php It just took the standard template instead.
What I think what happened
In the last moment before submitting this question I realized what happened:
In the process of working, there was a situation where I deleted the home.php and then edited the page in the backend. WordPress could not find the home.php, which was set as the template for this page. BUT it found home_20180301_2300.php and used it. (Because WordPress is smart [sometimes {not a joke}]). When home.php was back in its place, WordPress did not care. It looks like as long as there is no problem, WordPress does not search for other (or newer, or better suiting) files. It still used home_20180301_2300.php, because it worked. That's why my changes in home.php did not have any effect. home.php was ignored.
The Solution
I had to delete home_20180301_2300.php, open the page in edit mode and select home.php as the template again. WordPress did not find home_20180301_2300.php, "BUT HEY! There is home.php, my old friend, so I can use it", WordPress said and they happily lived together for the rest of their time.
Feel free to comment!
I am sure my explanation is quite simple and not showing the whole picture. If anyone knows better, I would be glad to hear it. Better knowledge of the problem and the way WordPress works can help me and others to better understand future issues.
Peace out,
Nils
Only today that it came to my attention that there is a malicious link that was injected in my wordpress site.
The link is only on the homepage of orphicpixel.com and here is the full code in html
<div class="toggle-search"><div id="5221f63">Learn how to extend your penis size using vigrx reviews.</div><script type="text/javascript">document.getElementById("36f1225".split("").reverse().join("")).style.display
= "none"</script><i class="fa fa-search"></i></div>
This are the fix that I tried.
Change the theme to default - the code is still there.
Turn off all the plugins - the code is gone.
I have identified 5 plugins that when turned on, the code appears. But the plugins are the official plugins like Jetpack, WP-pagination etc.
I search already my database but I got nothing.
I downloaded the theme files and search the codes, nothing
I downloaded all the plugins file and search the codes, nothing
So my last resort is to post this question here.
Unfortunately it is likely hidden in something like an eval statement, which can be hidden in hex. Wordpress can be useful but the plugins are what make a security nightmare. It is likely that some plugin has allowed some kind of upload access to your site and they can run their own PHP script or anything really.
Look through your files using
find . -type f -mtime -1
The -1 is days back, you can try -2, -3 etc. If this is a recent problem hopefully this will show a recently modified file. It will look a lot like gibberish when you open a file that is bad.
Again unfortunately, if they are smart they will adjust the time on the file to be something a few weeks back or what ever, thus making the file much harder to find.
Did you purchase your WordPress theme yourself and from the original provider? I would download Theme Authenticity Checker and run the plugin -- it finds malicious code within the theme. I know you checked the theme files, but better be safe than sorry. Usually, purchased themes have no problem but downloaded ones often have malicious code such as this.
My completely finished website started displaying "region" in all the regions instead of the content. This was shortly after I enabled "Calendar Multiday" so perhaps it was related (although I have now disabled that module). Calendar and Date were previously enabled and working perfectly. I am not actually sure if the problem has anything to do with the module.
Anyone seen anything like this? Could it have to do with access control? I disabled the module but that didn't do anything..
To be clear, even admins cannot see the content and simply see "region" in every region.
please clear the cache and tell me if its solved the problem... you can clear the cache by flushing the database tables that start with cache_... , or by implementing cache_clear_all(), drupal_flush_all_caches() functions ...
Check the region.tpl.php file if you have this problem as it was overriding all my content!
Today, I got free hosting space from my internet service provider. So, to test my Drupal project, I installed Drupal along with all those necessary modules (views, imageattach, Private message, search). Everything seems went well, until I tried to create a view.
When I add view and fills out all necessary field and press next, it just shows a blank white page instead of the "Views UI" edit page. I checked back in the view's list page, but no view was created. I'm not sure what causes this to happen;so I much appreciate your help.
Drupal 6.x
View 6.x-2.11
Private Message - 6.x-1.3
Note: It works fine in local environment.
UPDATE : As WmasterJ suggested, I checked dblog and found that my custom module is sending header inadvertently - there was gibberish(inverted question mark) just before my opening tag. I don't know how it got there. But, anyway, I removed it and the problem solves. Thanks WebmasterJ and the rest for helping me out.
Cheers
PS : WmasterJ, just want to let you know that, I tried to clicked on check mark to indicate your post is the solution, but it doesn't work at all. "Add comment" link doesn't work either. So, don't be surprise for not seeing any indication of yours being the right solution.
Some tips from the "white screen of death" page that mattv posted which I would try is:
First, try and get some error messaging out there since this will help you to pin-point the problem and solve it faster. In you index.php file write:
<?php
error_reporting(E_ALL);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);
// $Id: index.php ...
Second, take a look at messages in your watchdog log at: /admin/reports/dblog
After which you will have a better understanding and can go back to the white page of death help page and read more.
There is a whole page in the Drupal handbooks dedicated to debugging the "White Screen of Death". In a nutshell, enable error reporting and check the logs. Those two steps tend to pinpoint the problem, most of the time. If that doesn't point you towards a solution, continue down the handbook page, for lots more tips.
If I had to take a wild guess, I would say your case is probably an out-of-memory error.
If it's free space from your shared ISP, chances are you're out of memory.
Create a PHP file that contains only the following:
<?php
phpinfo();
?>
Load it in your browser (if you called the file "info.php", go to http://www.yoursite.com/info.php) and look for the line that says memory_limit. If it's less than 32MB, that's what's causing it - it's why the site works fine locally and most pages work fine, but the View create page takes up a lot of memory.
Also try going to the Modules page, this page can also consume a lot of memory - if you get a white screen there then this backs up the out-of-memory theory.
Your ISP may let you override the memory_limit by creating a php.ini file somewhere in your account. You should set it to at least 64M, preferably 128M+ for a complex site.
I have a fairly new drupal installation with a few hundred nodes. I moved it from the development server to the production server.
However, when I opened my homepage, it says page not found. After checking all my links, it seems that I can't get to any of my content. They exist in the node database, as well as the content type tables. I verified that all my URL aliases are also in place. In most cases, I can still see all the information from views I had created, but when clicking to see the full node view, I get the "Page not found".
I did trim all my cache tables before importing to reduce the size of the DB. Has anyone had these symptoms before? Perhaps there is a particular table, that when truncated, will lead to this problem?
**Update: Imported my revision table again, and presto - Although my content came back, I'm still having a sort of permissions problem. When an anonymous visitor comes to the site, they are told they don't have permission to see items like content type "Page", yet in user permissions, everything looks good (definitely good before migration) perhaps another deleted table?
Yes, node content information is in the revisions table, not the node table. You REALLY need the revisions table. I assume you can just remigrate again, this time without truncating revisions.
if table is broken, it shouldn't show "Page not found". It may show that sql error that table or column doesn't exists.
Try troubleshoot in http://drupal.org/node/201875 (you will see Page Not Found links in middle).
Also may be you use some redirecting in your node theming, check this.
p.s. In any case, node saving touch 2 tables: node and node_revisions