I have a question about unpublishing pages in 3.6.3. If I unpublish a page, all of its descendants also get unpublished so I have to re-publish all of them when I re-publish the parent page. I do not remember this happening in the past with other versions. This is not very good if it is a feature as I can no longer tell if some of the child pages were unpublished before I unpublished the parent page so It is possible that by batch publishing all of them, I may published pages that should not yet be published. Is this a bug or a feature?
I can confirm this happened in prior versions (I checked as far back as 3.3.2). For what it's worth, reviewing the source code, it looks like this "feature" also exists in SilverStripe 4.x and above as well (e.g. v4.6).
It looks like this was caused by the enforce_strict_hierarchy setting under SiteTree. This apparently defaults to true and means that whenever a page is deleted (regardless of the "stage", e.g. live vs. draft) it will result in all child pages also being deleted.
Technically when you unpublish a page, it deletes it from the "live" stage. Because this was a deletion, it then ends up cascading to all child pages as well. As a result, the net effect is that when you unpublish a page all child pages appear to have been unpublished as well. This is a weird setting which I just discovered unexpectedly after 384 pages suddenly got unpublished. Particularly because this also means that you have to choose between this unexpected functionality of unpublishing (deleting) everything under the current page, or, have the possibility of lots of orphans sitting around in the database.
Anyway, to workaround this, add this to your site's _config.yml file:
SiteTree:
enforce_strict_hierarchy: false
Related
I am having a strange problem where my product pages are blank most of the time in woocommerce. If you click a product, sometimes it may or may not load, and if it doesn't, you have to refresh it multiple times until the page finally shows the content. I noticed this only happens to users who are not logged into wp-admin.
I had W3 caching plugin but I deactivated and deleted and the problem still persists? I am not sure how this started... I am using the most updated version of woocommerce.
Website: http://museiam.ca/
I would appreciate any help as I'm quite stumped.
Issue #1 - Failing to load, redirect loop
According to your comments about the error logs the product page is doing a redirect to itself, and getting stuck in that loop. This explains the "10 internal redirects" error message. The access log error is likely just a side effect of having so many of the same repeat requests in such a brief time window.
Note that I could not reproduce this issue, but I got a very similar issue (below). I was unable to determine why this is happening through poking around. This may take some code investigation (aka, on your end). Is this a custom WP theme?
Issue #2 - Loading complete, but not displayed
A second type of error occurs which is similar. Middle-click or open a product in a new tab. Or click on a direct link to a product, such as: http://museiam.ca/product/black-cut-sleeve-sweater/
The content will load, but it will be a white page. In this case, the javascript has loaded content but did not complete the loading event to make it visible.
You can confirm the second issue by opening your dev tools (for chrome: F12), and entering the following javascript into the script console:
jQuery('.global_content_wrapper').css('opacity', 1)
This should make the content visible.
EDIT: It seems issue #2 is also inconsistent, sometimes it does work - though much less often than following a link from within the website. These two issues may be one in the same.
I recently took over a site from someone else at a new company. Having never used Drupal before, updating things has been a bit cumbersome. There were some outstanding security updates that I applied(but I haven't updated the core yet). Anyway, after doing this, the calls to views_embeded_view have not been working. For example:
print views_embed_view('news_block');
Will break the links(by using the title, rather than alias for the link), or it will link correctly, but not follow the paging rules I have set(show 1 page, 6 items per page) instead it shows 10 items and has links for other pages.
I am not sure if the update has anything to do with it, but it seems likely. Would updating the core resolve this issue potentially?
The first argument of views_embed_view is view name, the second one is display id. If display_id is not provided, 'default' is used. Make sure that you are displaying the correct display. (i.e. default can be configured differently than some other display which you actually wish to see)
When i submit my form that is being displayed in an overlay, the resultant page is unthemed. If i submit the same form from a regular page view the page is themed as expected. Not sure how to debug this?
Using XDV, Plone 4.2
First off, have you tried to port to plone.app.theming? It should be relatively straightforward (there's a guide in the p.a.theming docs), and p.a.theming ships with Plone 4.2 and is even better in 4.3. I don't think there's a straight-up incompatibility, but there could be. XDV is no longer maintained (as in, it was renamed plone.app.theming and development continues there), so porting is probably going to be necessary sooner or later.
The only other thing I can think of is whether there is some sort of condition or list of unthemed paths kicking in, e.g. may it be looking for a request parameter like ajax_load or the tail end of a path and disabling the theme?
Finally, check whether there are any errors in the console output/logs: XDV doesn't throw a site error, but will log if there's a problem.
(Sorry this is rather a vague question. My attempts to be clearer [and indeed to be more code-oriented] have failed...) :-/
//
I've installed the Firebug for Drupal module, and I notice that it shows I'm apparently loading the same eight node objects on every page for no apparent reason. These are all of the same content type (the site uses many other content types).
It seems they are actually all the nodes of this one content type, excepting those produced as dummy content by the developer module.
I've flushed the cache multiple times.
Is there a way to work out where these nodes are being loaded from???
Install devel.module, add ddebug_backtrace(); inside the node_load() function. Reload the site. Now you should see 8 browsable backtraces which will tell you which function calls node_load().
At a guess, you probably have a block (from a view or module) which is querying those nodes on every request.
http://heydon.com.au/node/1044 has a short writeup on this behaviour. If so, the fix is to remove that block from the regions which are rendered, or configure it to only be displayed (and therefore rendered) on pages where you want it to be run.
Drupal caching should prevent those queries being run for anonymous users (depending on the caching and block settings, of course).
I've had this happen with 3rd party modules that were repeatedly calling node_load() needlessly. What I would suggest is for you to disable all 3rd party modules, retry you node loads and re-enable them one by one until you catch the misbehaving module.
Good-luck!
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