text:
Camelbak M.U.L.E. Military Hydration Pack
By Camelbak
General Features
- Hydration capacity: 100 oz. (3L)
- Cargo capacity: 488.2 cubic inches (8L)
- Weight: 2.2 lbs. (1 kg) with empty reservoir
- Dimensions: 17 x 9 x 7 in (435 x 230 x 180 mm)
- Got Your Bak Lifetime Guarantee
Reservoir Features:
- Reservoir: Omega Water Beast Wide Mouth
- Reservoir Cap: leak proof screw cap
- Reservoir Tube: Insulated PureFlow
- Reservoir Valve: Big Bite
- Reservoir Exit Port: HydroLink (Multiple ports)
- Reservoir Drink Port: HydroLink/HydroLock one handed flow control
Pack Features:
- Pack Back Panel: Air Director
- Pack Shoulder Strap: Side release
- Pack Access: Access separate insulated reservoir compartment without having to remove pack
- Pack Fabric: 500D Cordura Fabric front panel/gusset/shoulder harness front side
- Pack Fabric: 420D High Density Nylon on shoulder harness back side
- Pack Fabric: 7 mm EVA foam shoulder harness
- Pack Fabric: 210D Nylon lining
- Pack Fabric: 5 mm Closed Cell PE foam on back panel and inside hydration compartment for insulation
- Pack Fabric: 15 mm Closed Cell PE foam utilized on raised POD design of back panel
- Pack Fabric: Nylon webbing
Pack Storage:
- Pack Pockets: Glasses, goggles and NVG pocket with external access
Click Here To Start A Return
If, for whatever reason, you are not satisfied with your purchase, you can return it to HRM USA within 45 days of purchase date subject to conditions below. Claims for items damaged in transit must be received within (3) business days of receipt of merchandise. Items deemed defective by manufacturer standards must be reported within 7 days of receipt.
Refunds & Credits Refunds on returned items will be issued to the same payment as tendered at the time of purchase. Once we receive and inspect the product you will be issued a credit back to your account. Please allow 5-7 Business days for a credit to appear on your account.If payment was made by check, the refund check will not be issued within 7- 10 business days after receipt of return.
Easy Return Process
Please be sure to place a note in the package with this information:
1)Order number
2)Reason for return
3)State that you would like a refund, or an exchange and what you would like to exchange for.
Our return address is:
Attn: Return Dept
1044 Pulinski Rd.
Warminster, Pa 18974
Or log in to your account by clicking here, and process your return online.
No Return/Exchange
on the following:
– Hydration Packs, Water Bottles once any of the packaging has been opened or safety seals have have been broken.
– Computers and Computer Software, once any of the manufacturer's packaging has been opened.
– Heating Pads, once safety seal has been broken
– Electronic Software is not returnable or refundable once opened.
– All consumable items or hygienic items (e.g., Gels, Energy Chomps, Elixirs, etc.) once unwrapped or seal broken.
– Special Order merchandise, Clearance, or any itemindicated on the website as non-returnable.
– Imprinted products.
– HRM USA Stores Gift Cards are redeemable for merchandise only and may not be redeemed for cash.
If the item is returned to us for exchange, please allow 2-5 business days for the replacement to be processed and shipped. All returns are shipped with our Economy shipping method and arrive within 2-10 Days.
Please read all conditions below. If conditions are not met, HRM USA reserves the right to refuse the return or to charge a restocking fee not less than 10% or a $2.95 minimum restocking fee charge.
If using a shipping label generated by HRMUSA Inc, the cost of this label will be deducted from refund amount (unless product is defective).
All returned items must be in new condition, in their original unaltered box (including the UPC code being intact) and must include all packing material, blank warranty cards, manuals,and accessories. Defective items may be exchanged for the same model or manufacturer's equivalent model. Please call us at 800-403-8285 for assistance. Please allow time to discuss any issues you may be experiencing as we may recommend tech support to resolve any issues prior to exchange. Any refused package will be assessed shipping charges incurred by the carrier.
Click Here for a list of Manufacturers Tech Support Phone Numbers


text:
Showing 1-1 of 1
Where is the crossword for April 12th>
The last line of clues was omitted in the print version.
This is last week's puzzle.
The file has been corrected and ready for download. Thanks for your patience as we worked through the technical issues.
Another one unable to download PDF Version this morning, 11/16. . I would just love it if two consecutive weekly …
No recent videos found.

subset: commoncrawl


text:
Join as a member. There's a certificate with your name on it.
Views currently has basic functionality to enabled and disable views. This currently works by setting the 'disabled' key on ViewStorage and calling save() on the view. It would be better if this could work more like exportables currently does in D7, with the status to be set/overridden outside of the view.
This feature could benefit any type of configuration entities.
Proposed resolution
Add a new key to the entity info for configuration entities to store the config name for a new file. This file can store an array of key => status for each configuration entity.
Remaining tasks
Initial patch only, needs review and work.
User interface changes
API changes
Enable, disable, and isEnabled methods to interface and ConfigEntityBase and ConfigStorageController. As above, definitely needs work and review.
Original report by damiankloip
PASSED: [[SimpleTest]]: [MySQL] 49,843 pass(es). View
|704 bytes
PASSED: [[SimpleTest]]: [MySQL] 49,202 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] 49,191 pass(es), 1 fail(s), and 0 exception(s). View
Comment #4heyrocker CreditAttribution: heyrocker commented
If we end up adding manifest files (see #1697256: Create a UI for importing new configuration) then it seems that would be a sensical place to also store enabled/disabled?
Comment #13xjm CreditAttribution: xjm commented
Not having this is a regression from D7 Views, so bumping to major.
Comment #14tim.plunkett CreditAttribution: tim.plunkett commented
|Allow configuration entities to be enabled/disabled
|» Allow all configuration entities to be enabled/disabled
|» Normal
|Issue tags:
|-feature freeze
This is already in Views, we're just working to abstract it for all ConfigEntity.
Comment #19yched CreditAttribution: yched commented
ConfigStorageController::setStatus()/getStatus() look like they could be abstracted to act on any "property" besides 'enabled' ?
Comment #20aspilicious CreditAttribution: aspilicious commented
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.phpundefined
@@ -26,6 +26,13 @@
+ * Returns whether the configuration entity's status is disabled or not.
+ *
+ * @var bool
+ */
+ public $disabled;
There is alrdy an issue to change this to $enabled. I fully support that.
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.phpundefined
@@ -53,6 +62,28 @@ public function setOriginalID($id) {
+ /*
+ * Implements Drupal\Core\Config\Entity\ConfigEntityInterface::enable().
+++ b/core/modules/config/tests/config_test/config_test.moduleundefined
@@ -197,4 +210,26 @@ function config_test_cache_flush() {
return array();
\ No newline at end of file
Damnit how did this get in in previous patches. It will be gone now ;)
Comment #23aspilicious CreditAttribution: aspilicious commented
patch is identical
Comment #25andypost CreditAttribution: andypost commented
It looks strange to have imageStyle disabled or a whole menu... Suppose better to provide a annotation
disableable for config entities
Comment #30attiks CreditAttribution: attiks commented
Trying to understand this, the enable/disable is stored inside a manifest yml file, so this would mean that if I want to deploy something I need to copy an extra file now?
Comment #32heyrocker CreditAttribution: heyrocker commented
Yes, please see the discussion this came from at #1697256-44: Create a UI for importing new configuration
Comment #33attiks CreditAttribution: attiks commented
Comment #35sun CreditAttribution: sun commented
There is absolutely no reason to put this into manifest files, or tie it to them in any way. It would be a clear abuse of manifest files.
Configuration objects are cached. And there are usually not many of a certain type. If you need to iterate over all, just do it. If this turns out to become slow, we add specialized caching of lists and/or helper methods for it.
Furthermore, a disabled config object does exist. The system cannot simply hide them away as if they would not. Doing so would have an immense amount of ugly repercussions down the line.
The proper solution here is:
Add an
'status'key to config files.
(Ideally following what content entities are doing; the common publishing status property of content entities actually is not too different from the desired effect here.)
Add a new
ConfigEntityToggleableInterface(better name welcome).
Config entities that implement this interface have a status and can be enabled and disabled.
ConfigStorageControllerwith the proposed enable/disable/isEnabled methods, but check
instanceof ConfigEntityToggleableInterfacebefore operating on one.
As a slight variation of the last two points, we could alternatively consider to add a new
'status' => 'status' key to the
entity_keys array in entity info, which is the pattern for enabling additional entity semantics/behavior already (such as UUIDs, revision support, etc).
Comment #36tim.plunkett CreditAttribution: tim.plunkett commented
Views already currently has
protected $status, see ViewStorageInterface
However, the act of enabling and disabling is made much faster by this patch, since the whole View yml file doesn't have to be written, just the small manifest file.
Comment #37sun CreditAttribution: sun commented
To further explain why we cannot simply hide away disabled configuration:
#949220: Text format names can never be reused (Possible solution: Allow disabled text formats to be re-enabled)
#562694: Text formats should throw an error and refuse to process if a plugin goes missing
In other words:
Disabled configuration/entities still exist. The system and API has to know about them. They are an active part of the system, at all times. The decision to "disable" them (instead of deleting) has UI consequences only. They still exist. They just don't necessarily participate at all times with regard to dependent operations.
E.g., a disabled node type must still exist. It's a bundle, and there can be fields attached to the bundle. The node type has to participate in all API operations, regardless of whether it is enabled or disabled. The only thing that really changes is that it no longer appears on
/node/add and potentially elsewhere, but all of these decisions are purely cosmetic.
This means that listing/loading all config entities of a certain type will always return all, regardless of whether they are enabled or disabled.
If you want to remove configuration, delete it.
Comment #39sun CreditAttribution: sun commented
We should limit the scope of this issue to a pure enabled/disabled status as an opt-in for config entity types.
Anything related to "overridden" is an entirely different can of worms, for which we have separate issues already:
#1398040: Detect if default configuration of a module has been changed, and allow to restore to the original
#1620140: Allow synchronizing config entities from default config when modules are updated
Also, depending on how fast we move forward here, #1779026: Convert Text Formats to Configuration System might land upfront, and like Views, Filter module's text formats can be disabled in HEAD already — although that behaves slightly differently than Views and also, disabling a text format has a non-trivial range of consequences across the entire system. In general though, there's a lot that can be learned from the status implications of text formats.
Comment #44dawehner CreditAttribution: dawehner commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 48,013 pass(es). View
This patch fixes hopefully all failing tests.
// Force the rebuild of the menu.
For whatever reason just using
state()->set('menu_rebuild_needed', TRUE);
doesn't cause the page to appear, maybe someone has a clue why.
Comment #47sun CreditAttribution: sun commented
This looks pretty good. Some questions:
1) I wonder whether we shouldn't add (enforce) a status property/key for all config entities, just like we have a langcode for all. Long-term, I think that would be good for consistency. Of course, the status handling would have to be implemented first, so short-term, the easiest way would be to force the statusKey to be 'status' and force the value to be 1 (enabled). And in the list controller, we'd have to differentiate between config entities that "actually" support it and those that do not (only temporarily until status handling has been implemented everywhere).
2) Regardless of 1), the status for config entities that support a status should default to 1/enabled. That way, default configuration supplied by modules would only have to specify the status if the entity should not be enabled by default.
3) I don't necessarily see why the status property should be bound to the storage controller, as we'd still expect a status to be there, even if the storage controller is swapped out — but alas, that's how we're doing things in the entity system currently (and I don't understand it), so this aspect of the proposed implementation, while strange, seems to be correct.
4) Regardless of 3), I'm not sure whether it is a good idea to directly save an entity upon calling ->enable() or ->disable(). For the storage controller methods, that might make sense — but for the entity methods, I wouldn't have expected those methods to directly perform a write operation. I'd only expect the entity methods ->save() and ->delete() to actually perform storage operations/manipulations, so this would be more natural from my perspective:
$foo = entity_create('foo', array());
(...which, alas, questions whether those should be methods on the entity in the first place, but I don't see why not.)
Comment #48sun CreditAttribution: sun commented
Oh, and we need dedicated tests for this functionality; i.e., not mixed into completely different tests. I'd even recommend to create a new ConfigEntityStatusTest class, since I predict that we'll have to verify some edge-cases over time. You should be able to use DrupalUnitTestBase for that.
Comment #50sun CreditAttribution: sun commented
Yes, long-term, I think we want to have an enable/disable functionality on all config entities. In fact, most Configurables we have support that notion in one way or the other today already, it is merely not standardized yet. @merlinofchaos suggested that direction very early already, and I agreed, and only deferred the topic to "when we're there" — now, we are. ;)
Off-hand, I can't really see what would break by making $status a public property on ConfigEntityBase and defaulting it to 1 in the constructor, unless a config entity type explicitly opted-out by setting $statusKey to FALSE. (i.e., the identical opt-out logic as existing for $uuid for config entities already; we should actually make sure to copy the entire logic of uuid as a template for status, because it should behave exactly the same with regard to the entire entity life-cycle) — right now, we only have config test, image styles, contact categories, and views in core, no? I don't see why any of those would break.
Aside from that:
The enable/disable/isEnabled methods on ConfigEntityBase should really just set/check the property value on the entity object, instead of calling into the storage controller; only save() and delete() should call into the storage. EDIT: Again, just copy what we're doing for uuid().
And minor: The new test class should be renamed to ConfigEntityStatusTest, since the context/subject is ConfigEntity.
This looks great, and I think we're very close.
Comment #54sun CreditAttribution: sun commented
Thanks! :)
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php
@@ -26,6 +26,13 @@
+ public $status = '1';
The default value should be set in the ::create() method of the (config) storage controller, just like uuid is set there by default.
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php
@@ -88,6 +95,28 @@ public function set($property_name, $value, $langcode = NULL) {
+ public function enable() {
+ $this->status = '1';
We are type-casting everything to strings at the storage layer currently, but I think the default value as well as the value being set by enable()/disable() should be TRUE/FALSE Boolean value.
(Also note that we might remove the string-casting via #1653026: [META] Use properly typed values in module configuration)
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php
@@ -88,6 +95,28 @@ public function set($property_name, $value, $langcode = NULL) {
+ public function isEnabled() {
+ $status_key = entity_get_controller($this->entityType)->statusKey();
+ return isset($status_key) ? $this->status : TRUE;
+ }
The current entity system practice is to all these methods identical to their properties (which is a bad practice), so/but at least for now, we should keep this in line and rename isEnabled() to just status().
Second, as you can see from the other entity methods that return entity key-specific values, the default implementation on the entity class always assumes and uses the default property name; i.e., we do not call into the storage controller here, but instead, simply return $this->status.
(I've been told that entity classes that diverge from the defaults are supposed to override the entity methods as needed; e.g., you also need to override the id() method if your entity key is different; see #1822176: Why do we have $entity_info['entity keys']['id'] *and* MyEntity::id() method overrides?)
Also, let's type-cast the returned value to bool, so functions that call into status() can at least reliably expect a Boolean value there.
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityInterface.php
@@ -32,4 +32,21 @@ public function getOriginalID();
+ /*
Missing * :)
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigStorageController.php
@@ -57,6 +57,13 @@ class ConfigStorageController implements EntityStorageControllerInterface {
+ protected $statusKey = 'status';
@@ -66,6 +73,13 @@ public function __construct($entityType) {
+ if (isset($this->entityInfo['entity_keys']['status'])) {
+ $this->statusKey = $this->entityInfo['entity_keys']['status'];
+ }
+ else {
+ $this->statusKey = FALSE;
+ }
OK, thinking through this once more, I guess that my suggestion to make the status key an opt-out like uuid wasn't really right/correct, since there is not really a way to opt out of entity keys (you could specify FALSE as value in the plugin annotation, but that would be not very consistent with the other entity keys).
For now, I guess that this code works. We might want to add a @todo, or simply create a follow-up issue to actually enforce some entity keys for config entities (at least the uuid property/key is strictly required, but not properly enforced currently). So yeah, that rather sounds like an independent follow-up issue. This code looks fine to me.
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigStorageController.php
@@ -237,6 +251,13 @@ public function create(array $values) {
+ public function statusKey() {
+ return $this->statusKey;
+ }
This method should be obsolete with the above ConfigEntity class changes.
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityListTest.php
@@ -54,19 +54,27 @@ function testList() {
+ 'disable' => array(
+ 'title' => t('Disable'),
+ 'ajax' => TRUE,
+ 'token' => TRUE,
1) Note that config_test module does not use translatable strings currently. That's why the other expected operation labels are not wrapped in t() either.
2) I don't really get the purpose of the 'ajax' and 'token' properties — looks like those should be removed here and tackled in a separate follow-up issue?
+++ b/core/modules/config/tests/config_test/config/config_test.dynamic.default.yml
@@ -1,2 +1,3 @@
+status: 1
I wonder whether we should intentionally comment this out, and add a comment above it that the default status is expected to be enabled (and add a test for that)?
+++ b/core/modules/config/tests/config_test/config_test.module
@@ -116,6 +117,18 @@ function config_test_menu() {
+ $items['admin/structure/config_test/manage/%config_test/enable'] = array(
+ $items['admin/structure/config_test/manage/%config_test/disable'] = array(
One very interesting aspect is that the enable/disable operations can only be accessed from the list overview page, but not from within the entity edit form. I think Views gets around that by adding a dropbutton on the upper right of the edit form, which contains all of the entity operations once more. In general, this also reminds of #1834002: Configuration delete operations are all over the place, and we will have to design/invent a pattern for that.
However, just mentioning — that should be done in a separate follow-up issue.
+++ b/core/modules/config/tests/config_test/lib/Drupal/config_test/Plugin/Core/Entity/ConfigTest.php
@@ -62,4 +63,11 @@ class ConfigTest extends ConfigEntityBase {
+ public $status = '1';
Specific entity classes do not need to repeat properties of the base class, so this ConfigTest entity property can be removed.
Comment #55sun CreditAttribution: sun commented
|Needs work
|» Needs review
FAILED: [[SimpleTest]]: [MySQL] 47,488 pass(es), 466 fail(s), and 174 exception(s). View
Helping you out a bit.
Comment #59sun CreditAttribution: sun commented
Comment #60sun CreditAttribution: sun commented
Heh. Surprisingly similar, even. ;)
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityListController.php
@@ -30,25 +30,24 @@
- if (!$entity->status()) {
+ if ($this->getStorageController()->statusKey()) {
+ if (!$entity->status()) {
ah, removing that condition makes sense.
Comment #64sun CreditAttribution: sun commented
|» configuration system
|Needs review
|» Reviewed & tested by the community
|Issue tags:
Excellent! :)
Comment #65tim.plunkett CreditAttribution: tim.plunkett commented
Extra +1 from me!
Comment #66catch CreditAttribution: catch commented
I haven't got time to fully review the patch now, but this is something with Views that always made me uncomfortable so when I saw the title and the RTBC status I wanted to get in quick. Will try to explain the lack of comfort below, if it's not valid please say so:
Disabled makes sense if you have 'default' configuration in PHP that you can't delete, like stuff from hook_views_default_views(), however we no longer have that situation.
If you delete some default configuration, the configuration still exists in the folder of the module that provided it. Currently there's no public API or UI for accessing default configuration vs. live, but that feels like something that could be useful for other things (like override/reset).
If we had that, then could 'disabled' configuration be 'stuff that exists as a default somewhere, but isn't in the live configuration? i.e. have a UI for showing configuration objects that exists as default but aren't represented in the active storage?
And if that's the case, then for modules to provide configuration disabled by default we'd need to provide a way to say "don't actually import this configuration file, just leave it there', and people could find it if they want it.
On top of that, if there's configuration that's not default, why would you want to disable it? I can see something like wanting to work on a custom view without exposing it anywhere else maybe? Is that the idea here and if so how does that tie in with the potential for eventual revisions and drafts on config entities down the line?
Comment #67sun CreditAttribution: sun commented
I think I understood your concerns. And I think they are irrelevant for this issue. Here's why:
Loading default config from
./configdirectories within individual extensions is and was only ever acceptable for the installer from my perspective, and for that limited scenario and use-case, it made a tonne of sense. At regular runtime, a filesystem scan across potentially hundreds of extensions would not remotely be acceptable from a performance perspective. The configuration system does not assume that the storage is shielded with a cache bin/backend, and I'd strongly object to any proposal that wants to introduce that assumption. Lastly, and most importantly, configuration is declarative, and loading "additional" configuration from arbitrary locations fundamentally breaks the concept of staging configuration. Your configuration is not declarative anymore. It is extended by "may or may nots" and tons of vague assumptions about what exists and what doesn't, and what has been configured and what was not. It is impossible to stage vague, random assumptions.
As mentioned elsewhere already: Configuration is owned by the user. Configuration, even if it came as some default, can be deleted. Default configuration in
./configdirectories cannot be deleted.
Default configuration in
./configdirectories cannot be disabled either. The maximum you'd end up with is the current, terrible architectural design of menu links in the menu/router system: As soon as you touch the default config in any way, it cannot be default configuration anymore. Whereas "touching" includes to innocently drag other configuration items within a tabledrag-enhanced table on an administration page, since the weight of all items needs to be adjusted. You didn't actually touch the default configuration, but yet, it has to be customized. #550254: Menu links are sometimes not properly re-parented tells an epic story about that. An architectural mistake I don't want to repeat at all costs. The essential architectural flaw is that the system assumes there would be some sort of a hybrid ownership of something, which leads to conflicts that are impossible to resolve. I will not accept this hybrid for configuration. And yes, I'm perfectly aware that we're still lacking bare-essential tools to cope with the situation, but my entire stance is that we will only be able to invent and provide the required tools if the ownership is clearly defined.
As you already alluded to, there are use-cases for disabled configuration. Regardless of whether it was supplied as default or not.
I actually consider this change as an essential milestone to bring config entities more in line with content entities: As I already mentioned earlier in this issue, the "enabled status" of config entities has logically (not necessarily technically) the exact same effect as the "published status" of content entities: The entity still exists, and the entity still participates on all fronts. The only difference is a UI implication: Much like unpublished content entities, disabled entities no longer appear in certain non-administrative listings.
This is essentially why I made sure that we're using the identical property name as content entities that support a publishing status and that the entire concept we're introducing here is identical to content entities. (And thanks to @damiankloip for coping with me ;))
This change won't prevent us from introducing revisions for config entities. Quite the contrary in my mind: The more we harmonize the two, the more likely are features like revisions (as well as typed properties/fields).
Comment #68catch CreditAttribution: catch commented
@sun I think we're talking past each other a bit (and I still haven't reviewed the patch). Here's some use cases though:
1. I have a view, that provides a block and a menu item. I disable it and the block and menu item disappear. What happens to my Scotch display that has the block configured then?
2. I have an image style and disable it, what happens if you try to visit an image URI, or the image style is configured for a field formatter?
3. I have a node type and disable the node type, what happens to all the nodes?
Essentially this feels like the same problem with have with disabled modules, but multiplied many, many times over, unless we actively stop people from using it all over the place whenever there's any kind of dependency.
Comment #69attiks CreditAttribution: attiks commented
#68, @cacth: this is the same as it is now for Drupal 7
1. If a view is disabled it no longer will show
2. If an image style is disabled the picture will no longer output, or maybe will default to the original image
3. The node will still be there, but the output isn't going to work, you probably still see it in admin/content, but editing/viewing will not be possible
I'm also waiting for this functionality for breakpoint so we can allow people to disable/enable breakpoints coming from themes, see #1734642-133: Move breakpoint module into core, breakpoint originally had enabled/disabled en override/revert. The problem is that we need everything inside the config dir (sites/default/files/config) because the config is build the moment a module/theme is enabled. We can not fallback to the .yml file shipped with the module/theme for this functionality.
Comment #70catch CreditAttribution: catch commented
|Reviewed & tested by the community
|» Needs review
No for #3 we actually don't let you disable a node type, at least via the UI, if you have content attached to it, that was fixed since Drupal 7. Node types disappearing at random was the cause of this bug:
#1017672: D6 to D7 update process permanently deletes comment bodies and other data, and throws fatal SQL errors
If we can't deal with the dependencies that content has on configuration, then we shouldn't allow the configuration to disappear arbitrarily.
Moving back to CNR, 'because you could do it in Drupal 7' isn't a good enough argument.
Comment #71attiks CreditAttribution: attiks commented
Comment #72catch CreditAttribution: catch commented
@attiks, there isn't actually a use case for why it's needed in #67, it just mentions that there are use-cases.
With breakpoints coming from themes, why can't users just delete them if they don't want them?
Comment #73attiks CreditAttribution: attiks commented
Deleting a breakpoint will mean that we need to reparse the theme.breakpoint.yml file to 'enable' it again, it will also mean that if the breakpoint has been added to a custom group, it has to be re-added to that group.
Comment #74sun CreditAttribution: sun commented
Typical use-cases from my POV:
- Build out [possibly even sets of] site configuration without immediately "publishing" it for user consumption.
- Disable some bundle/configuration, because it should (temporarily?) not be used (anymore).
What you could argue is that most use-cases can be translated into restricted access — but, if you think about it, then you'll realize that the status property of content entities works in the exact same way and has the exact same purpose; it is a flag whose value has access implementations, nothing else.
In light of that, the way Views handles the status flag indeed seems to be bogus/wrong; it needs to register all views in
hook_menu() regardless of their status, and only check the status upon trying to access a view.
Comment #76sun CreditAttribution: sun commented
Given the discussion and conclusions in #1776830: [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API, I think that @catch is very right to be concerned about what the exact consequences of disabled configuration are. For me, that essentially boils down to what I mentioned in #74 and earlier:
1) The enabled/disabled status of a config entity must only have an impact on "user view access".
2) Disabled config entities must still exist and be fully available.
3) The status of a config entity must only ever have an impact on 'view' operations in the UI. It needs to be treated like the publishing status of nodes.
This inherently means that Views' treatment and implementation of disabled views violates those roles, since it uses the status flag during API operations already and e.g. skips over disabled views when registering menu router paths. Instead, it always needs to register everything, and essentially, only check for access on view.
Likewise, to address #70, the disabled status flag on a content type would only mean that it does not appear on
/node/add for unprivileged users. Every other aspect of the content type would be retained 100% functional.
If there are architectural problems even with this very limited impact of the enabled/disabled status, and we cannot address them, then I think I tend to agree with @catch that we cannot implement the status and we want to remove it altogether instead.
Comment #78sun CreditAttribution: sun commented
I've the impression we're talking past each other :)
The conclusion that can be drawn from most of our existing "disabled status" throughout Drupal core, in particular with regard to the amount of critical/major bugs that the fundamental idea of having anything disabled has caused over the years, is that the idea itself caused more architectural and technical/functional problems than it actually resolves from a user perspective.
Disabled modules, disabled text formats, and almost everything else that can be disabled caused us a lot of problems, of which some are still not resolved today, and a few of them are almost impossible to resolve. Most of the problems are about stale/invalid references from something that is enabled to something that is disabled, as well as logical and security problems caused by disabled things that are involved in user workflows (e.g., something was created while something else was enabled, but then that other thing got disabled, which leaves the newly created thing in a undefined state - and also vice-versa, when something was created before something else got enabled, whereas the newly enabled thing could have a security impact on the newly created thing, potentially leaving it in a undefined state).
This is why we are extremely wary when introducing a new disabled notion. Thus, to clarify, the concerns are targeting the entire disabled config concept, not a particular implementation.
Therefore, it is critically important that we have a clear and concise understanding of the exact consequences of an enabled/disabled status for config, and also, what kind of effects/implementations are "allowed" (or "supported") and which are not. I think this is what @catch was referring to in his comments.
Technically, I think that the interpretation/guidelines for disabled config in #76 should not impose any of the typical "disabled problems", but I also want to admit that I'm not 100% sure.
Comment #81Fabianx CreditAttribution: Fabianx commented
#76: So for context (for example) this would mean:
* Disabled contexts are available for re-enabling
* Disabled contexts are greyed out on the UI.
* Context chooses to only process "published" contexts (status==1)
Do I understand this right (applied to this use case?).
Comment #82sun CreditAttribution: sun commented
That said, I'd also like to amend that the disabled status for a text format is actually required and the only way to make a text format disappear from the user interface. That is, because text formats can only be created, but they cannot be deleted - since we are not able to determine where a text format is used and thus whether a format can be deleted, and it is additionally not possible to automatically determine a replacement text format that has the same security effects as the deleted one.
Therefore, we do not allow to delete text formats, they can only be disabled, which essentially hides them from the node/add and node/edit forms — unless the format is assigned to the content already, in which case unprivileged users are not allowed to edit the content, and privileged/administrative users are asked to change it to a format that is enabled. However, the text format itself is fully functional and works as usual even if it is disabled.
And in essence, I guess that's the kind of usage that #76 would foresee - disabled config only has access implications, and those implications need to be handled very carefully. (The access handling in
filter_process_format() is anything but trivial...)
For text formats, we will have to introduce this notion anyway. However, that doesn't necessarily mean that we need to support it for everything; it could also be a one-off implementation.
re: #81:
Unfortunately, I'm not familiar with contexts, so I can't comment on that. I guess it would be better to think through config entities that are in core, since everyone of us knows how they work. :)
Comment #83dawehner CreditAttribution: dawehner commented
Probably similar to text formats, also Image styles would make sense to disable,
as you have the same issues to figure out where it is used.
Not sure about the other configuration entities, but we should better not provide a way to disable it, as many of them in custom/contrib world could have the issues mentioned by catch and sun. Maybe we could introduce "disable-ability" similar to the way uuid() works.
Comment #84tim.plunkett CreditAttribution: tim.plunkett commented
|configuration system
|» configuration entity system
Comment #86xjm CreditAttribution: xjm commented
So @EclipseGc thought of a different kind of solution to this problem: prefixing the filenames with
disabled. I initially rejected this idea because of all the reasons we've disliked magical names elsewhere--disallowing modules from having that name, #1186034: Length of configuration object name can be too small, #1831774: Config import assumes that 'config_prefix' contains one dot only, more magic generally, etc. etc. However, there are also advantages:
- It's really simple. We don't have to add hardly any new complexity to the configuration system; it just works with
- You don't have to load the objects to see if they're disabled.
- It's REALLY easy to see what disabled objects you have.
See also: #1881096: Regression: Site broken when disabling module without removing block instances.
Comment #87sun CreditAttribution: sun commented
The reasons stated in #86 are the exact consequences that must not happen for disabled config.
Disabled config has to exist. It has to be listed with listAll(). It has to be loaded with entity_load_multiple(). It has to be processed as usual. It has to be maintained.
The only acceptable impact of disabled config is an access condition for UI purposes.
Any additional hiding/munging on top of that will ultimately end up in the same, architecturally broken situation as disabled modules. We definitely do not want to go there, since we already know where that ends.
FWIW, the actual problem of #1881096: Regression: Site broken when disabling module without removing block instances. is much rather that the new config files of the new block system are not namespaced + owned + supplied by each module, and instead, collected by a single service. Therefore, the service has to manually check whether the configuration is actually valid, and it also has to maintain the configuration on behalf of the actual modules. Instead of
plugin.core.block.ID config names, the block system should actually use
$module.plugin.core.block.ID. I wanted to raise this concern in the block plugin conversion issue already, but didn't want to block that monster patch on it.
Comment #88xjm CreditAttribution: xjm commented
Instead of plugin.core.block.ID config names, the block system should actually use $module.plugin.core.block.ID. I wanted to raise this concern in the block plugin conversion issue already, but didn't want to block that monster patch on it.
There's already an issue for this: #1839904: Rename plugin.core.block CMI prefix to block.block
Well, not exactly what you've suggested I guess, but core also doesn't do what you suggest elsewhere. We use (e.g.)
views.view.frontpage.yml, not
Disabled config has to exist. It has to be listed with listAll(). It has to be loaded with entity_load_multiple(). It has to be processed as usual. It has to be maintained.
This seems completely counterintuitive to me. If the module isn't there, it can't be processed as usual.
Comment #89xjm CreditAttribution: xjm commented
Oh, sorry, I just realized the error in my thinking. Disabled things belonging to enabled modules really aren't the same things as previously-enabled things belonging to disabled modules.
Comment #90EclipseGc CreditAttribution: EclipseGc commented
FAILED: [[SimpleTest]]: [MySQL] 50,550 pass(es), 3 fail(s), and 0 exception(s). View
OK, wondering about something like this? I had to rearrange module_disable slightly so that entity cache is still around and usable for the hook. Likely a good thing, but not sure how it'll affect tests.
Comment #91sun CreditAttribution: sun commented
@EclipseGc: Unfortunately, that's really something very different than the goal and scope of this issue. We have a patch in #63 already, and all we're trying to decipher here is the exact architectural definition of "disabled config entities of an enabled module" and what that MAY constitute, though much more importantly, what it MUST NOT constitute.
I think the patch in #90 is more related to the discussion in #1776830: [META-1] Installation and uninstallation of configuration provided by a module that belongs to another module's API and related issues (of which we have too many already).
Comment #92EclipseGc CreditAttribution: EclipseGc commented
I agree. This was a misunderstanding on my part with regard to the desired outcome here.
Comment #93EclipseGc CreditAttribution: EclipseGc commented
Although, if tests come back green on it, I'd still suggest the module_disable change I made.
Comment #95xjm CreditAttribution: xjm commented
|Needs work
|» Needs review
FAILED: [[SimpleTest]]: [MySQL] Failed to run tests: failed to login to test site. View
General apologies to @damiankloip, though I do think we've accomplished something here which is to clarify that this issue solves a very different problem than #1881096: Regression: Site broken when disabling module without removing block instances.. :P
Here's an attempt to reroll this to "un-derail" the thread and also stir the pot since this has been sitting awhile. The block changes will still need to be reimplemented.
Comment #96xjm CreditAttribution: xjm commented
The merge conflicts.
Comment #98xjm CreditAttribution: xjm commented
|Needs work
|» Needs review
FAILED: [[SimpleTest]]: [MySQL] 50,163 pass(es), 259 fail(s), and 83 exception(s). View
And fixing the Views blocks.
Comment #103xjm CreditAttribution: xjm commented
It's entirely possible I screwed up the reroll or that the merge wasn't smart enough. :)
Comment #104sun CreditAttribution: sun commented
|» task
Meanwhile, we have some real world data of running into the overall problem space that we've extensively discussed in this issue:
#1901636: Importing a disabled format that is assigned to a role causes a fatal
Alas, text formats cannot be deleted, so they have to be disabled.
In turn, in one way or another, we will have to deal with disabled config entities. So I'm actually inclined to simply move forward here, since all this patch is really doing is to make the existing concept more generic. Which in turn means that we need to cater for the possibility within and outside of the ConfigEntity API.
Comment #119tim.plunkett CreditAttribution: tim.plunkett commented
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.phpundefined
@@ -89,6 +96,29 @@ public function set($property_name, $value, $langcode = NULL) {
+ * Implements Drupal\Core\Config\Entity\ConfigEntityInterface::enable().
+ * Implements Drupal\Core\Config\Entity\ConfigEntityInterface::disable().
+ * Implements Drupal\Core\Config\Entity\ConfigEntityInterface::status().
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityListController.phpundefined
@@ -23,4 +24,31 @@ public function load() {
+ * Overrides Drupal\Core\Entity\EntityListController::getOperations();
+++ b/core/modules/block/block.moduleundefined
@@ -365,20 +365,17 @@ function _block_rehash($theme = NULL) {
- if (!empty($region) && $region != BLOCK_REGION_NONE && !isset($regions[$region]) && $status == 1) {
+ if (!empty($region) && $region != BLOCK_REGION_NONE && !isset($regions[$region]) && $status) {
Heh, that was ugly
+++ b/core/modules/block/block.moduleundefined
@@ -365,20 +365,17 @@ function _block_rehash($theme = NULL) {
// Set region to none if not enabled and make sure status is set.
if (empty($status)) {
This comment needs adjusting, and this could probably be
if (!$status) {
+++ b/core/modules/block/block.moduleundefined
@@ -365,20 +365,17 @@ function _block_rehash($theme = NULL) {
$block->set('region', BLOCK_REGION_NONE);
- $block->set('status', 0);
- $block->save();
Good catch on the status bit, but we still need the save() for the region.
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityStatusTest.phpundefined
@@ -0,0 +1,54 @@
+ * Contains Drupal\config\Tests\ConfigEntityStatusTest.
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityStatusUITest.phpundefined
@@ -0,0 +1,59 @@
+ * Contains Drupal\config\Tests\ConfigEntityStatusUITest.
Contains \Drupal
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityStatusTest.phpundefined
@@ -0,0 +1,54 @@
+use Drupal\Core\Entity\EntityMalformedException;
Not needed?
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityStatusTest.phpundefined
@@ -0,0 +1,54 @@
+ * Test the enabling/disabling of entities.
+++ b/core/modules/config/tests/config_test/config_test.moduleundefined
@@ -146,3 +159,25 @@ function config_test_config_test_create(ConfigTest $config_test) {
+function config_test_entity_enable(ConfigTest $config_test) {
+ $config_test->enable()->save();
+ return new RedirectResponse(url('admin/structure/config_test', array('absolute' => TRUE)));
+++ b/core/modules/filter/filter.moduleundefined
@@ -351,7 +350,7 @@ function filter_formats($account = NULL) {
- if (!empty($filter_format->status)) {
+ if ($filter_format->status()) {
@@ -481,7 +480,7 @@ function filter_get_filter_types_by_format($format_id) {
- return $filter->status;
+ return !empty($filter->status);
This looks odd. Opposite changes?
+++ b/core/modules/node/lib/Drupal/node/Tests/Views/StatusExtraTest.phpundefined
@@ -35,7 +35,8 @@ public static function getInfo() {
- state()->set('menu_rebuild_needed', TRUE);
+ menu_router_rebuild();
+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/AreaTest.phpundefined
@@ -173,7 +173,10 @@ public function testTitleArea() {
+ // Force the rebuild of the menu.
+ menu_router_rebuild();
This seems unfortunate. But it *is* in a test
+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/ViewListController.phpundefined
@@ -82,7 +82,9 @@ public function buildHeader() {
+ * @todo Obsolete after extending from ConfigEntityListController.
Why not just remove it?
Comment #127dawehner CreditAttribution: dawehner commented
+++ b/core/modules/action/tests/action_bulk_test/config/views.view.test_bulk_form.ymlundefined
@@ -143,6 +143,6 @@ display:
-disabled: '0'
+status: '1'
That is great, no reverse logic anymore.
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityStatusTest.phpundefined
@@ -0,0 +1,53 @@
+ $entity = entity_create('config_test', array(
+ $entity = entity_load('config_test', $entity->id());
Shouldn't we use the entity manager to load the entity via the storage controller? Urg, yeah this makes it way harder to read.
+++ b/core/modules/config/lib/Drupal/config/Tests/ConfigEntityStatusUITest.phpundefined
@@ -0,0 +1,59 @@
+ $disable_path = "admin/structure/config_test/manage/$id/disable";
+ $enable_path = "admin/structure/config_test/manage/$id/enable";
Should/Could we use entity uri as well similar to the other part before?
+++ b/core/modules/config/tests/config_test/config_test.moduleundefined
@@ -146,3 +159,25 @@ function config_test_config_test_create(ConfigTest $config_test) {
+function config_test_entity_enable(ConfigTest $config_test) {
Missing @return
+++ b/core/modules/node/lib/Drupal/node/Tests/Views/StatusExtraTest.phpundefined
@@ -35,7 +35,8 @@ public static function getInfo() {
- state()->set('menu_rebuild_needed', TRUE);
Why not keep using state(), as it worked so far.
+++ b/core/modules/views/lib/Drupal/views/Tests/ModuleTest.phpundefined
@@ -182,15 +182,15 @@ public function testLoadFunctions() {
+ $this->assertTrue($view->status(), 'A view has been enabled.');
+ $this->assertEqual($view->status(), views_view_is_enabled($view), 'views_view_is_enabled is correct.');
So in general i'm wondering whether we could enabled()/disabled as methods as they might be easier to read then status(). We do have a enable method, so why not also one boolean to check the status? Alternative we could provide a setStatus instead of enable()/disabled() ... sounds odd to have two separate ways.
+++ b/core/modules/views/lib/Drupal/views/ViewStorageInterface.phpundefined
--- a/core/modules/views/tests/views_test_config/test_views/views.view.test_field_output.yml
+++ b/core/modules/views/tests/views_test_config/config/views.view.test_views_move_to_field.ymlundefined
+++ b/core/modules/views/tests/views_test_config/config/views.view.test_views_move_to_field.ymlundefined
@@ -1,25 +1,19 @@
diff --git a/core/modules/views/tests/views_test_config/test_views/views.view.test_field_output.yml b/core/modules/views/tests/views_test_config/config/views.view.test_views_move_to_handler.yml
--- a/core/modules/views/tests/views_test_config/test_views/views.view.test_field_output.yml
+++ b/core/modules/views/tests/views_test_config/config/views.view.test_views_move_to_handler.ymlundefined
Haven't we removed that file already?
+++ b/core/modules/views/tests/views_test_config/test_views/views.view.test_argument_default_fixed.ymlundefined
@@ -1,7 +1,7 @@
-disabled: '0'
+status: '1'
Desperate calling for a review on the plugin_id patch, as all this changes have the potential to break that one again.
Comment #133tim.plunkett CreditAttribution: tim.plunkett commented
|Needs review
|» Reviewed & tested by the community
Its nice to see this code move out of Views. Major props to @damiankloip, you really stuck with this one! :)
Comment #134olli CreditAttribution: olli commented
+++ b/core/modules/views/lib/Drupal/views/Tests/Handler/AreaTest.php
@@ -173,7 +173,10 @@ public function testTitleArea() {
+ // Force the rebuild of the menu.
+ menu_router_rebuild();
It is in a test, but I'm not 100% sure we need that anymore.
+++ b/core/modules/views/tests/views_test_config/test_views/views.view.test_display.yml
@@ -1,7 +1,7 @@
-disabled: '1'
+status: '1'
Since view->enable() used to save the view, should view->save() be added to views_enable_view?
Comment #135olli CreditAttribution: olli commented
|Reviewed & tested by the community
|» Needs work
Comment #137olli CreditAttribution: olli commented
|Needs review
|» Reviewed & tested by the community
Comment #138Dave Reid CreditAttribution: Dave Reid commented
Wow, thank you for flipping the 'disabled' property into 'status'. That's always bugged me.
What happens when a contact form category which is set to default is disabled?
Comment #140catch CreditAttribution: catch commented
|Reviewed & tested by the community
|» Fixed
Yeah I can't stand $view->disabled. While I'm paranoid about disabling of anything, at the moment this is just taking existing concepts of disabled config entities and making them consistent, and doesn't impose usage on anyone. We can then take any implementation of that case by case.
Patch is 99% updating default views, rest looks good, committed/pushed to 8.x.
Comment #141sun CreditAttribution: sun commented
|» Active
Yay, thank you for sticking with this :) Really glad to see this in.
A couple of remarks though:
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php
@@ -27,6 +27,13 @@
+ public $status;
1) Since this is a public property, isn't its value automatically exported for all config entities now? Perhaps I'm missing something...? At least the default langcode property right above the new $status property is exported for all config entities. If this is handled in a special way somewhere, then at least a @see would be helpful.
2) I think we should add a default value of TRUE here, so that
status() automatically works correctly, even when not going through the ConfigStorageController?
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityInterface.php
@@ -32,4 +32,27 @@ public function getOriginalID();
+ /**
+ * Returns whether the configuration entity is enabled.
+ *
+ * @return bool
+ */
+ public function status();
I think we should actually add some architectural documentation here — essentially what we've discussed and clarified in-depth in this issue; i.e., that the status does not affect loading, that it only takes effect when explicitly declared in entity_keys, and that each entity type/controller/integration needs to check and handle the status on its own.
Most importantly, we should document that disabled config entities MUST always be available on an API level, and that the disabled status MAY only have UI implications (more or less ~access).
+++ b/core/modules/views/lib/Drupal/views/ViewStorageInterface.php
@@ -13,22 +13,4 @@
interface ViewStorageInterface extends \IteratorAggregate, ConfigEntityInterface {
Looks like this interface is obsolete now? Do we have a follow-up issue to kill it? :)
+++ b/core/modules/views/views_ui/lib/Drupal/views_ui/ViewListController.php
@@ -82,50 +82,14 @@ public function buildHeader() {
public function getOperations(EntityInterface $view) {
$definition['clone'] = array(
'title' => t('Clone'),
'href' => "$path/clone",
Should we create a follow-up for incorporating a 'clone' operation into the ConfigEntityListController?
Comment #146tim.plunkett CreditAttribution: tim.plunkett commented
|Needs work
|» Needs review
PASSED: [[SimpleTest]]: [MySQL] 49,202 pass(es). View
That adds the ajax to the generic controller, we just need it in Views.
I really would like to see a setStatus() method.
Let's say you want to react to a value, and enable/disable based on that.
if ($foo) {
else {
It was discussed earlier and then removed, not sure why.
Comment #147dawehner CreditAttribution: dawehner commented
Oh I really like that change, you want for sure that on every configuration entity.
I have been asking for a setStatus() command earlier, though sun suggested to use one for enable()/disable().
Would you suggest to have both enable()/disable() and setStatus()?
Comment #148dawehner CreditAttribution: dawehner commented
Comment #150sun CreditAttribution: sun commented
The expressiveness of
enable() and
disable() is generally appealing.
We can have a
setStatus(bool $value) in parallel, but for the sake of extensibility/overrides, we'd have to declare which method(s) is/are the "master method(s)"; i.e., which one is supposed to be overridden. I guess if there was a
setStatus(), then rather that; and in turn,
enable() and
disable() would call into
Sidenote: Not sure whether that wouldn't be 1-2 public methods too much for a facility that shouldn't play a key role in the first place...?
Comment #151andypost CreditAttribution: andypost commented
Another related issue - I see Enable as a first action for configurables that inherit getOperations() (picture, menu, contact)
+++ b/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.phpundefined
@@ -31,7 +31,7 @@
- public $status;
+ public $status = TRUE;
This really required.
Comment #152andypost CreditAttribution: andypost commented
And that actially point that we lack of testing for order of operations on entities
Comment #158tim.plunkett CreditAttribution: tim.plunkett commented
|Needs work
|» Needs review
Comment #161tim.plunkett CreditAttribution: tim.plunkett commented
|Needs review
|» Reviewed & tested by the community
Comment #162webchick CreditAttribution: webchick commented
|Reviewed & tested by the community
|» Fixed
Committed and pushed to 8.x. Thanks!
Comment #164Fabianx CreditAttribution: Fabianx commented
Uh, no change notice on that?
Comment #165andypost CreditAttribution: andypost commented
Yes, just describe properties and methods at least
Comment #166catch CreditAttribution: catch commented
|Allow all configuration entities to be enabled/disabled
|» Change notice: Allow all configuration entities to be enabled/disabled
|Needs work
|» Active
Comment #167dawehner CreditAttribution: dawehner commented
Comment #168andypost CreditAttribution: andypost commented
I think all new methods needs to be described:
- setStatus() - done
- enable()
- disable()
- status()
Also here's a duplicated change notice http://drupal.org/node/1926374
Comment #172andypost CreditAttribution: andypost commented
|Change notice: Allow all configuration entities to be enabled/disabled
|» Allow all configuration entities to be enabled/disabled
|» Normal
|» Fixed
Comment #174xjm CreditAttribution: xjm commented
Untagging. Please remove the "Needs change notification" tag when the change notice task is complete.


text:
I was wondering if anyone lives in Missouri and how the service are there? Our family is thinking about moving and this one of the top places on our list. I know that it made the top five list but I would really like to know more from families that really live there and use services. We currently live in Pa (which did not make the list but is a great place for service) but the cost of living is becoming to high here. If anyone has any input I would be grateful. The area we are looking at is in Webster County.
This was posted on another forum:
As someone from Missouri which made the top five listing of Best States for Autism, let me just say that you can't believe everything you read. Missouri is NOT a good state for services for autism. I live in the No. 2 rated district in the state - Lee's Summit, just south of Kansas City. Lee's Summit is a great district for typical children but the autism population, specifically, is treated like an ugly stepchild. There are several due process hearings against Lee's Summit currently that revolve around children with autism.
The other services listed for Missouri was the Thompson Center at MU and the Judevine Consultation Center. Both of these centers are top knotch but Judevine is not state-wide. It is located in St. Louis and is only available in the middle and right side of the state. The Thompson Center only offers diagnostics and assessments. It is trying to open a school for children with autism but it is not open at present.
Joyce Lindsey
Powered by UBB.threads™ 6.5.5
Home - Autism Symptoms - Autism Videos - Autism Organizations - Autism Message Boards - Articles - Autism Recipes - Hyperlexia - Fragile X - Contact


text:
Move over the profile to follow the route.
No stories submitted yet. Did you climb this mountain? Tell us your story!
Did you ride the Port de Larreau? Please send your cycling story, description or comments to climbbybike and get your own tour on climbbybike, or discuss about the Port de Larreau on our forum. You can also send us video's or send us pictures on the Port de Larreau.
© climbbybike™ All rights reserved 2005 -


text:
Save Balmossie Fire Engine
Balmossie Fire Station has served the people of Monifieth,Broughty Ferry and surrounding areas since December 1982. At present the station is crewed by a full time crew who respond from the station 24/7 and a part-time crew who respond from their homes 24/7. In August this year, the Chief Fire Officer of Tayside Fire & Rescue, Mr Stephen Hunter, submitted a proposal to the elected members of Tayside Fire Board effectively reducing the number of fire engines stationed at Balmossie Fire Station from two to one. These proposals included the removal of the part-time crew during the day and the removal of the full time crew during the evening. At present if you require the services of Balmossie Fire station you can expect to have a fire engine mobile to your location within 1-2 minutes of fire control receiving your call followed by a second fire engine approximately 5 minutes later. If these proposals go ahead, during the day the second fire engine would have to come from Kingsway East Fire Station or Blackness Road Fire Station. That is assuming that these extremely busy stations are not attending another incident at the time. In the evening, (when most fire deaths occur), the first fire crew would have to be mobilized from their homes delaying the attendance time to an incident by more than 5 minutes and again hope that the second fire engine is not attending another incident. We believe that these savage cost cutting measures are putting the lives of the people served by Balmossie Fire Station at risk and we believe that with the public's help we can ensure that these frightening proposals do not become a reality. If you feel strongly about these proposals then please take the time to sign this petition. REMEMBER YOUR SIGNATURE COULD MAKE THE DIFFERENCE.
6 years agorgkpkqlqjt United States6 years ago
7 years agoLinda Tennant United Kingdom7 years ago
7 years agoGraeme Tennant United Kingdom7 years ago
7 years agoGraeme Tennant United Kingdom7 years ago
7 years agoAnon United Kingdom7 years ago
7 years agoTony Robb United Kingdom7 years ago
7 years agoSandra Brown United Kingdom7 years ago
7 years agomandy griffen United Kingdom7 years ago
8 years agoAlison Wallace United Kingdom8 years ago
8 years agoAlan Fenton United Kingdom8 years ago
8 years agoEdward French United Kingdom8 years ago
8 years agoJennifer Jordan United Kingdom8 years ago
8 years agoJune Fenton India8 years ago
8 years agoAlan Fenton India8 years ago
8 years agoElizabeth McRae United Kingdom8 years ago


text:
All content on Lab Tests Online has been reviewed and approved by our Editorial Review Board.
The Test Sample
What is being tested?
The RBC antibody screen looks for circulating antibodies in the blood directed against red blood cells (RBCs). The primary reason that a person may have RBC antibodies circulating in the blood is because the person has been exposed, through blood transfusion or through pregnancy, to RBCs other than his or her own (foreign RBCs). These antibodies have the potential to cause harm if a person is transfused with red blood cells that the antibodies may target or if a pregnant woman has antibodies that target the red cells of her developing baby.
RBCs normally have structures on their surface called antigens. People have their own individual set of antigens on their RBCs, determined by inheritance from their parents. The major antigens or surface identifiers on human RBCs are the O, A, and B antigens, and a person's blood is grouped into an A, B, AB, or O blood type according to the presence or absence of these antigens.
Another important surface antigen is Rh factor, also called D antigen. If it is present on a person's red blood cells, that person's blood type is Rh+ (positive); if it is absent, the blood is type Rh- (negative). (For more on these antigens, see the article on Blood Typing). In addition, there are many other types of RBC antigens that make up lesser-known blood groups, such as Kell, Lewis, and Kidd blood groups.
There are a few reasons why someone may produce antibodies against RBC antigens.
- Following blood transfusions: Antibodies directed against A and B red cell antigens are naturally-occurring; we produce them without having to be exposed to the antigens. Before receiving a blood transfusion, a person's ABO group and Rh type are matched with that of donor blood to prevent a serious transfusion reaction from occurring. That is, the donor's blood must be compatible with the recipient's so that antibodies do not react with and destroy donor blood cells.
If someone receives a blood transfusion, the person's body may also recognize other RBC antigens from other blood groups (such as Kell or Kidd) that the person does not have as foreign. The recipient may produce antibodies to attack these foreign antigens. People who have many transfusions make antibodies to RBCs because they are exposed to foreign RBC antigens with each transfusion.
- During pregnancy, with blood type incompatibility between mother and baby: A baby may inherit antigens from the father that are not on the mother's RBCs. The mother may be exposed during pregnancy or at delivery to the foreign antigens on her baby's RBCs when some of the baby's cells enter the mother's circulation as the placenta separates. The mother may begin to produce antibodies against these foreign RBC antigens. This can cause hemolytic disease of the newborn, usually not affecting the first baby but affecting subsequent children when the mother's antibodies cross the placenta, attach to the baby's RBCs, and hemolyze them. An RBC antibody screen can help determine if the mother has produced RBC antibodies outside of the ABO blood group.
The first time a person is exposed to a foreign RBC antigen, by transfusion or pregnancy, the person may begin to produce antibodies but his or her cells do not usually have the time during the first exposure to make enough antibodies to actually destroy the foreign RBCs. When the next transfusion or pregnancy occurs, the immune response may be strong enough for enough antibodies to be produced, attach to, and break apart (hemolyze) the transfused RBCs or the baby's RBCs. Antibodies to the ABO antigens are naturally-occurring so do not require exposure to foreign RBCs.
RBC antibodies that are detected with a screen can be identified with an antibody identification test.
How is the sample collected for testing?
A blood sample is drawn with a needle from a vein in the arm.
NOTE: If undergoing medical tests makes you or someone you care for anxious, embarrassed, or even difficult to manage, you might consider reading one or more of the following articles: Coping with Test Pain, Discomfort, and Anxiety, Tips on Blood Testing, Tips to Help Children through Their Medical Tests, and Tips to Help the Elderly through Their Medical Tests.
Another article, Follow That Sample, provides a glimpse at the collection and processing of a blood sample and throat culture.
Is any test preparation needed to ensure the quality of the sample?
No test preparation is needed.


text:
sku 19855-PEPPR-88
After Eight Bench Grp2 Opt2 Black Onyx 19855 PEPPR 88After Eight After Eight 20' 29' 20' 29' 20' 29' 20' 29' Benches And Ottomans Benches And Ottomans Upholstered Upholstered $500 To $1000 $500 To $1000 Contemporary And Modern Contemporary And Modern Standard Bench Standard Bench 60' 69' 60' 69'
Product Information
Classic Tinsel-town glamour and ''Hollywood Regency'' style adored by Golden Age celebrities comes alive in the After Eight Collection by Michael Amini and AICO Furniture.
Rug & Home is proud to offer FREE White-Glove Delivery on most Furniture purchases totalling $2,500 or more! This offer excludes shipment to Hawaii, Alaska, Canada, and Puerto Rico. If you have any questions, please contact customer service at 1-877-RUG-HOME (877-784-4663). We at Rug & Home want you to be 100% satisfied with your purchase and, to ensure this, we have a convenient 7-day in-home-trial-policy for furniture purchases. If you are not completely satisfied with your purchase, you may return it within 7 days from the date the merchandise was delivered for a full refund (excluding return trip shipping fees). Please see our Shipping & Returns Policy for restrictions and complete details.


text:
Top 10 SQL Server 2008 Features for ISV Applications
Author: Burzin Patel
Contributor: Kun Cheng
Reviewers: Sanjay Mishra, Denny Lee, Mike Ruthruff, Sharon Bjeletich, Mark Souza, Peter Carlin, Hermann Daeubler, Peter Scharlock, Wanda He
Microsoft SQL Server 2008 has hundreds of new and improved features, many of which are specifically designed for large scale independent software vendor (ISV) applications, which need to leverage the power of the underlying database while keeping their code database agnostic. This article presents details of the top 10 features that we believe are most applicable to such applications based on our work with strategic ISV partners. Along with the description of each feature, the main pain-points the feature helps resolve and some of the important limitations that need to be considered are also presented.
1 Data Compression
2 Backup Compression
3 Transparent Data Encryption
4 Data Collector and Management Data Warehouse
5 Lock Escalation
6 Plan Freezing
7 Optimize for Ad hoc Workloads Option
8 Resource Governor
9 Table-Valued Parameters
10 Filestream
Abstract courtesy : Microsoft
Reference : Pinal Dave (https://blog.sqlauthority.com)
1 Comment. Leave new
Hi Pinal, thats indeed amazing..you are really a pioneer of SQL server…Can you please add or update more interview questions based on sql 2008?


text:
Connecting Homes and People to Improve LivesConnected Life Exchange
By Jason Kohn, Contributing Columnist You hear the term "M2M" a lot these days in the tech industry, and it means different things for different people. Broadly, machine-to-machine communications isRead More
Living the Connected Life – in Tasmania, AustraliaConnected Life Exchange
By Lionel Walters, Guest Columnist I grew up in suburban Sydney and enjoyed many of the benefits and conveniences of life in a large and established community. I was closeRead More
How Service Providers Enable the Connected LifeConnected Life Exchange
More than ever, access to local telecommunications network infrastructure has become an important part of the way many of us live, work, play and learn — throughout our daily routines.Read More
How Broadband Boosts Individual ProductivityConnected Life Exchange
By Howard Baldwin, Contributing Columnist We've shared our perspective about how broadband boosts the potential productivity of continents, countries, and municipalities. But never about how broadband boosts the productivity ofRead More
Cisco CLUE Part 4: Global mobile moxie – no cord, no problemSP360: Service Provider
Welcome back to our fourth and final installment of the updated Cisco Connected Life User Experience (CLUE) Index findings. We've previously covered residential and business services, and today, mobile servicesRead More
Cisco CLUE Part 3: No such thing as "business as usual" for today's global workersSP360: Service Provider
Yesterday, we discussed the "At Home" or residential services category of our Cisco Connected Life User Experience (CLUE) Index findings. Today, we'll focus on the "At Work" or business servicesRead More


text:
I got a letter asking about Christians and the Sabbath. Here's the letter, and I wonder What do you think? If you keep your feet from breaking the Sabbath and from doing as you please on my holy day, if you call the Sabbath a delight and the LORD's holy day honorable, and if you [Read More…]
Archives for Feb 4, 2014 @ 12:21
What do you think?
A Few Slots in our DMin Still Open
Our cohort for the DMin in New Testament Context is taking shape, and I could not be more excited than who has enrolled. Think about joining us… I will be directing a new and innovative Doctor of Ministry (DMin) program at Northern Seminary. Here's our announcement: Northern is excited to announce a new Doctor of [Read More…]
More Than Just Genes and Neurons (RJS)
I've taken a hiatus from the series on the book by Malcolm Jeeves Minds, Brains, Souls and Gods. The topic is important though, and worth a return. I'll get back to the book, but today I would like to point (again) to a few short videos on the topic. The web site Test of FAITH [Read More…]
Tim Keller on Suffering
Interview with Tim Keller. David Moore conducted the following interview. Dave blogs at www.twocities.org. I've read quite a bit on the topic of suffering. There are some very good books available, but the ones that simply articulate a "free will" defense leave me empty. There is certainly truth to this line of argument, but it [Read More…]


text:
This is very good hotel! beautiful views, and a lovely balcony where you can rest. effe The beds were very nice! The bathroom was quite large, very hygienic, there is also a fridge! Also convenient way, you get good treats everything was explained well, the food was very tasty and healthy beautiful place where you can shop Enzo, the hotel workers explained where the tram stops were and where the museum. Highly recommended!
- Reservation Options:
- TripAdvisor is proud to partner with Orbitz, Expedia, Hotels.com, Booking.com, Travelocity, Hotwire, Cheap Tickets and TripOnline SA so you can book your Hotel Bellington reservations with confidence. We help millions of travelers each month to find the perfect hotel for both vacation and business trips, always with the best discounts and special offers.


text:
Clipped from The Digital Deli
Celebrating the Golden Age of Radio
Have you ever gazed upon an old photo or illustration, contextually drinking in the era and yet sober minded as to how the times have changed? As was the case in most of Norman's work, this is a simple, playful perspective of the 40's. However, six decades later, we have been even more awakened to the world and it's complexities. Our viewing process brings with it an assortment of images, thoughts, and emotions.


text:
Teenage Rock Star Lil' Chris has told reporters if he could change one thing he'd like to end bullying.
The musician, whose real name is Chris Hardman, was speaking at a news conference with pupils taking part in BBC News School Report in Manchester.
"If there could be no bullying that would be nice," he said in the interview which was also webcast on the BBC News website.
Chris sprung to fame when he appeared in the second series of Gene Simmons' Rock School and got to open a concert for heavy metal band Judas Priest.
He admitted it was a nerve-racking experience. "I was so nervous. The first time I went on stage was to perform in front of 20,000 people. That was really being chucked in at the deep end."
Chris says his inspiration is fellow East Anglian Justin Hawkins, the former frontman for The Darkness, who also went to Kirkley High in Lowestoft.
Despite his rock star status it seems Chris has still kept his feet firmly on the ground. "I thought he was nice and kind, he was just like one of us," said 12-year-old Yinka from Whalley Range High School, one of the pupils that interviewed him, before adding that she hadn't actually bought any of his records.


text:
It appears you have not yet Signed Up with our community. To Sign Up for free, please click here....
Headaches & Migraines Message Board
what does it mean when your head is sore in a one spot
All times are GMT -7. The time now is 07:46 PM.
Site owned and operated by HealthBoards.com


text:
There has been an almost unending run of bad news out of Afghanistan, including new peaks in casualty figures for U.S. troops. Gen. David Petraeus, the top commander for the war effort, is currently on a media mission to convince the American people to stick with President Obama's strategy there a bit longer nonetheless.
He's likely to succeed.
"I think our job is … to show those in Washington that there is progress being made," Petraeus said on NBC Nightly News on Thursday. "We've got to build on the progress that has been established so far." He's due on NBC's Meet the Press this Sunday, CBS-TV next Friday and ABC-TV by the end of the month.
Most Americans Still Onboard With Afghan Plan : NPR
Current Status: Blessed (1)
Seeded on Fri Aug 13, 2010 1:09 PM
keyboard shortcuts: V vote up article J next comment K previous comment


text:
Comedian Rob Delaney, who has been called "the funniest person on Twitter" by Comedy Central, and one of the "50 funniest people" by Rolling Stone, recently gave an "At Google" talk.
The company has now made the hour-long talk available to all on YouTube. He discusses his memoir "Rob Delaney: Mother. Wife. Sister. Human. Warrior. Falcon. Yardstick. Turban. Cabbage." among other things.
The talk was recorded on November 6th.


text:
Miami Spring Home Design And Remodeling Show ( Home Show )
Home Show Management
Friday, March 22, 2013 at 12:00 PM - Sunday, March 24, 2013 at 10:30 PM (EDT)
Who's Going
San Francisco, California
London, United Kingdom
Florence, Italy
Event Details
Miami (spring) Home Design And Remodeling Show
March 22 - 24, 2013
Miami Beach Convention Center
(1901 Convention Center Drive)
An Unparalleled Event!
The nationally recognized show fills the Miami Beach Convention Center with an international showcase of residential decorating, remodeling and home improvement products and services.
This year's show will feature:
Celebrity Guest Speakers
Informative seminars presented by industry experts in home design and remodeling will be offered throughout the weekend. Featured celebrity guest speaker Mark Brunetz of Style Network's Clean House will share tips and techniques for organizing. He will sign his new book "Take the U Out Of Clutter" following each seminar, All seminars are free to show attendees with paid admission.
Special Feature:
Decorating On A Budget
Learn easy decorating tips on a budget and get great do-it-yourself ideas.
Also Featuring:
Celebrity Designer Showcase
Elegant designer showrooms will be created for South Florida media personalities
When & Where
Miami Beach Convention Center
1901 Convention Center Dr
Miami Beach,
Friday, March 22, 2013 at 12:00 PM - Sunday, March 24, 2013 at 10:30 PM (EDT)
Add to my calendar
Home Show Management
Home Show Management Corp., producers of the Home Design & Remodeling Shows, has over 40 years of experience in producing successful home shows in South Florida. Both exhibitors and consumers recognize the difference this experience makes. Sold-out shows in both markets indicate exhibitor preference and record attendance attests to consumer demand. Contact us 305-667-9299. For information about exhibit space email email@example.com.


text:
The Waratahs will ramp up the pressure on returning Chiefs five-eighth Aaron Cruden in a preview of the upcoming Bledisloe Cup showdown between Australia and New Zealand's playmakers.
Cruden will wear the Chiefs' No.10 jersey for the first time in two months after coming back from a broken thumb. He featured off the bench against the Hurricanes but was predictably rusty in a loss the two-time Super Rugby champions will be eager to purge from their memories.
His run-on return pits the incumbent All Blacks five-eighth against Bernard Foley and Kurtley Beale, the two Waratahs' playmakers earmarked last week for the prized Wallabies No.10 jersey.
Waratahs coach Michael Cheika said Cruden's ice cool performance against Ireland in Europe at the end of last year, when he slotted a near-sideline conversion to cap a comeback and snatch the match, was proof of his value to a Chiefs side badly stung last week.
"He's obviously an experienced campaigner and, with the pressure being on, he's been in those situations before," Cheika said.
"He's kicked a goal to keep the All Blacks undefeated in their season-ending run, from the sideline.
"He has a very good temperament, so I suppose we have to try to put as much pressure on him as possible and also give him a bit of traffic to deal with himself."
Cheika rejected the notion of a Bledisloe Cup sneak peek with Foley and Beale coming up against the 29-Test All Black and warned that the NSW forwards had to perform for their playmakers to make any ground.
"I'm not big on the one-on-one contests," he said. "You might get those chances in the game, when one man comes up against another, but I really believe it's about how we orchestrate the style of game we want to play.
"Bernard's been doing that quite well, with the balance between running and distributing, and hopefully he can keep Cruden guessing a little bit in what we want to do.
"But nothing will happen without a platform being laid and it's a massive task for our lads to muscle right up – and that's all the forwards both on the bench and in the starting pack . . . without that, both in attack and defence, we're not going to have any chance."
The Waratahs forwards' physical and mental transformation has made all the difference to their performance this season. The injection of some South African abrasiveness via Jacques Potgieter, added to Wycliff Palu's regeneration and Kane Douglas' coming of age has earned the pack the respect of rival sides.
Captain Dave Dennis, voted players' player for his tireless performance against the Rebels last week, also won his coach's praise. But Dennis knows that the Waratahs will need to produce another level of aggression against the Chiefs in New Plymouth.
More importantly, they will need every available reserve of energy endurance against a side that, despite the 45-8 loss last week, are practised winners.
"A team coming off a loss like that will be disappointed, and might be lacking in a bit of confidence, but the way we've looked at it is that they've won the competition for the last two years and they're a quality team," Dennis said.
"They will be highly motivated to put in a good performance, they will bounce back strongly."
For all the firepower in both sides' back lines – the Chiefs boast Tim Nanai-Williams, Asaeli Tikoirotuma and Tawera Kerr-Barlow – Cheika has the side well-prepared for a grind on Saturday night.
"It's a bit of a final for us around who's going to work harder in the game," he said. "They're a benchmark around that and, if we can stay with them or go past them, then we might be a chance."
"They've got some big guys in the forwards, like [Brodie] Retallick and [Ben] Tameifuna, [Liam] Messam, and they can scrap you on the floor with [breakaway] Sam Cane.
"Then they've got twinkletoes out wide in Nanai-Williams and Tikoirotuma, Cruden and [Tawera] Kerr-Barlow orchestrating in the middle – it's pretty comprehensive.
"The trick is not to worry too much about the opposition and think about our jobs, what we can bring to the table and see if we can't pinch a result."


text:
Former province of Périgord, the Dordogne has a wealth of remarkable places of interest, especially prehistoric sites, and appeals as much to architecture fans and lovers of unspoiled landscapes as it does to sporty types. Divided into four geographical areas – Black Périgord, Green Périgord, White Périgord and Purple Périgord – the Dordogne has enough to keep all its visitors happy.
The biggest department in metropolitan France, Gironde can also be proud of its multitude of treasures, both natural and architectural. The City of Art and History of Bordeaux, the superb castles of Cazeneuve, Roquetaillade and La Brède, the Atlantic Coast with its salty waves and sandy beaches beloved by holidaymakers and surfing fans, the wonderful Arcachon Bay with highly prized seaside resorts and typical oyster villages, the tallest dune in Europe and its unforgettable views, the lakes ideal for water sports, the pine forests dotted with cycle paths, the famous Bordelais vineyard with its prestigious wines, or the famous oysters of Arcachon Bay - you can enjoy all these treasures on a weekend or longer getaway!
A surfers' paradise and an exceptional summer holiday destination, Landes combines the pleasures of the beach and ocean with the natural attractions of the forest and lakes. A hydrotherapy hotspot, with the five spa resorts of Dax, Saint-Paul-lès-Dax, Eugénie-les-Bains, Préchacq-les-Bains and Saubusse-les-Bains, the Landes department boasts many other features, such as its 106 kilometres of fine sandy beaches which stretch out along the Atlantic coast from Biscarrosse to the mouth of the Adour, its renowned seaside resorts, such as Capbreton, Hossegor and Vieux-Boucau Port d'Albret, which offer a varied choice of sports activities, its immense pine forest and many lakes where you can recharge your batteries and enjoy outdoor activities. Everything for you to really enjoy your stay in the Aquitaine region!
Nestling in the heart of southwest France, bordered by Périgord, Quercy, the Landes and Gascony, the Lot-et-Garonne département is a leading destination for nature-orientated holidays. Traversed by the two rivers from which it takes its name, this fertile orchard region famous for the Agen prune is crisscrossed by some 200 km of navigable waterways and 3,500 km of walking trails! In addition to this natural wealth, it offers beautiful built and rural heritage in the form of bastide towns, castles and manor houses, dovecotes and windmills. Definitely one for architecture fans and those who love outdoor pursuits!
Ideally located between the ocean and mountains, Pyrénées-Atlantiques is ideal for lovers of nature as well as fans of outdoor activities and architecture enthusiasts, with a wide range of things to see and do. You'll find an extensive selection of attractions, from the beautiful villages of Béarn and Pays Basque to the splendid Pyrenean mountains, which are ideal for skiing and hiking, through the spa resorts with their health-giving water, the Cities of Art and History of Bayonne and Pau, and the seaside resorts of the Basque coast, with their long, sandy beaches... Enjoy without moderation!


text:
1.Diet books are the new self-help books.Ten years ago, we began to soothe our souls with books like the Chicken Soup series, Life's Little Instruction Book and Codependent No More. These days, we're more interested in physical well-being. With Dr. Atkins' New Diet Revolution leading the way, diet books took 9% of sales in 2003 while self-help dropped to 2% — down from a high of 12% in 1997.
2.On Mother's Day, moms take the cake.The end-of-year holidays are a big deal for cookbook sales, but there is one other time when a book like The Cake Mix Doctor seems the perfect present (or, at least, the gift of last resort): Mother's Day. In each of the last 10 years, cookbooks — from Dr. Atkins recommending low-fat cooking to Martha Stewart's fancy hors d'oeuvres — have seen a perceptible bump as the second Sunday of May draws near.
3.We're losing our sense of humor.Sitcom stars Tim Allen (Home Improvement), Paul Reiser (Mad About You), Ellen DeGeneres (Ellen) and Jerry Seinfeld (Seinfeld) all had best sellers in the early years of the book list. So did humorists Dave Barry and Erma Bombeck. But where have the laughs gone? Humor books have shrunk to just 0.6% of list sales, down from a high of 5.3% in 1995. Some still carry on: David Sedaris (Me Talk Pretty One Day), DeGeneres (The Funny Thing Is . . . ), Bill Cosby (I Am What I Ate and I'm Frightened) and the staff of The Onion, always ready to parody the news.
4.If you're buying a dictionary, it's probably in August.Want to know when summer's over? It's when dictionaries show up en masse on the best-seller list, signaling the end of long, lazy nights and a return to the schoolhouse grind.
5.September brings 'The Scarlet Letter.'A staple of high school American lit classes, Nathaniel Hawthorne's classic tale of adultery faithfully returns to the best-seller list every fall. So does the Cliffs Notes version — which outsells the real book 3.6 to 1.
6.Movies sell books.When Hollywood hypes a movie, you can bet that the book it's based on will climb the best-seller list. More than a year before the first installment of J.R.R. Tolkien's Lord of the Rings trilogy hit the big screen, sales of the books skyrocketed. Just in the last year, Academy Award best-picture nominees Seabiscuit and Mystic River helped their authors climb the list.
7.'Harry Potter' redefines the meaning of best seller.How big is the Harry Potter phenomenon? Big enough to be its own category. Between 1999 and 2003, sales of J.K. Rowling's magical tales accounted for 7.7% of all sales tracked by the list — even more than the fast-growing diet and health genre.
8.The longevity award goes to . . .What to Expect When You're Expecting by Heidi Murkoff, Arlene Eisenberg and Sandee Hathaway, which made the top 150 list 523 out of 532 weeks from the start of the list to the end of 2003. (And even in the nine weeks the maternity guide didn't make the top 150 list, it registered as one of the 300 books USA TODAY compiles each week.) Other contenders: The 7 Habits of Highly Effective People by Stephen Covey (449 weeks in the top 150) and To Kill a Mockingbird by Harper Lee (441 weeks in the top 150).
9.John Grisham spends more weeks at No. 1 than anyone.Through 2003, legal legend John Grisham spent 90 weeks at No. 1, nearly double J.K. Rowling's time atop the list. One reason: Grisham has been around longer. He had three titles in the top 50 when the list began in 1993. Since then, 11 of his hardcovers have debuted at the top. Only Bleachers, a non-legal thriller, started at No. 2 in September 2003 (trumped by Dr. Phil's The Ultimate Weight Solution). That's quite a testament.
10.Chances are, you've given this as a gift.Each spring, Oh, the Places You'll Go!, Dr. Seuss' classic book of encouragement, climbs the top 150 list as students everywhere prepare to move on to a new stage of life (and parents prepare to help them along). May and June account for 68% of the book's annual sales tracked by USA TODAY's list.Other perennial best sellers have a reputation for being the right gift for the right occasion. Some favorites: Margaret Wise Brown's Goodnight Moon (for babies) and Robert Munsch's Love You Forever (whose sales rise for Valentine's Day and Mother's Day).


text:
Washington, DC—Senate Majority Leader Harry Reid released the following statement today regarding the appointment of Democratic Conference Secretary Patty Murray as Chair of the US-China Inter-Parliamentary Group (IPG):
"Today, I appointed Senator Patty Murray as the Chair of the US-China Inter-Parliamentary Group (IPG). In her role as Chair of the IPG, Senator Murray will meet with leaders in the Chinese government to discuss critical issues with top ranking legislative officials. This group represents the Senate at the highest level in its interaction with China.
"Under Senator Murray's leadership, this group will address economic issues, international issues, trade, human rights and religious freedom among other important issues in the US-China relationship. I am hopeful that the IPG can help to foster a stronger, healthier long-term relationship with the Chinese government. Given her long history of working for stronger trade and intergovernmental relations with China, I have great confidence in Senator Murray's ability to be an effective voice for positive developments in US-China relations going forward."


text:
CADWELL-L ArchivesArchiver > CADWELL > 2006-08 > 1156595210
Subject: [CADWELL] Nash-Cadwell-Dickinson
Date: Sat, 26 Aug 2006 08:26:50 EDT
Anna E Cadwell -- b. 1829 NY, dau. of Roderick Cadwell & Laura Dickinson, m.
David L Nash, d. Dec 1909 Lapeer MI; Nash children -- Mazovia/Masovia (1862
IL), Charles W (1864 IL), George C (1866 IL), Laura W (1868 MI).
Roderick Cadwell (b. 1795 Wilbraham MA) appears to have been the son of David
Campbell (b. 1768 MA) & Olive Arnold (b. c1768 CT). Other children of
Roderick & Laura, all b. NY -- George (1833), Francis (1835), & John (1837).
According to censuses Roderick & Laura lived in Livingston Co NY, Dodge Co WI, &
DeKalb Co IL. Roderick's whereabouts unknown after 1860.
Laura Dickinson Cadwell (b. 1797 CT) dau. of Capt Noah Dickinson (b. 1741 CT)
& Hannah Skinner (b. 1753 MA), both parents died in York Town, Livingston Co
NY. Laura may have died 1863 in Dodge Co WI, which would have required a
return to there from IL sometime after 1860.
Would be interested in hearing from anyone who can add to or correct any of
this data. David L Nash & Anna E Cadwell were the parents of Charles W Nash,
the auto industrialist, by the way.
Wade Dick
Bradenton FL
Cadwell-Dickinson>Nash-Cadwell>Nash-Currier>Firman-Nash>Dick-Firman>Wade B
This thread:


text:
The NPS is a scoring model developed by Bain & Co. Consultant Frederick F. Reichheld.
It basically involves asking respondents to respond on a 0 -to- 10 point rating scale question - "How likely are you to recommend Company/Product to your friend/colleague?" - The scale is then divided into three sections :
To add a Net Promoter® Score question type go to


text:
I was asked to do a review of the new Born Pretty Holo Polish not to long ago. It was supposed to be a great holographic polish, with great opacity and formula. I was very much interested... and what do I think about it now that I've tried it? Read on.
Born Pretty, Holo Nail Polish #12, 2 coats
Born Pretty Holo Polish in shade #12 is a dark green holographic shade. The holo effect is visible, but it's not over the top. The polish doesn't look dull in low light which is great. The shade kind of reminds me of a washed down a England's Saint George. Well, they're obviously no dupes, but they're the closest in my collection. This Holo Polish has a great formula and the application was also very easy. The brush is nothing special, but it's easy to work with. I used 2 coats for full opacity. All in all... I must say it was a nice surprise. It's a great polish, but what's not so great is the size of the bottle. You only get 6 mL of this green holographic liquid for $12.88 (it's on sale at the moment, for $5.59). It's still a lot for a tiny amount of polish, but if you're into the color, go for it.
I made some outdoor photos, but the sun wasn't cooperating... It's prettier in real life.
You can buy this polish on Born Pretty Store (here's a direct link to the Holo Polish #12). If you're planning on buying from Born Pretty Store, here's a 10% off code for you - SSG10. It's also in the sidebar.
*Product was sent to me for reviewing purposes.
Thanks for looking and commenting!


text:
teakwood chairs, with red embroidered backs and cushions, stood about the walls.
There is a small cabinet of teakwood that is beautifully carved.
Then he advanced to a divan beside a teakwood table on which stood a large copper samovar.
The best kind of wood, if you can afford it, is teakwood, which lasts for centuries.
He stood with his back against the rough bark of a teakwood tree to protect his rear and to face out toward the pitch-black night.
The room was furnished somberly but richly with heavy hangings and teakwood furniture decorated with mother-of-pearl.
Her narrow beam, her graceful sweep of teakwood rail, and the long, tapering counter suggested speed.
He motioned to a stool as he let himself fall heavily into a teakwood armchair made especially for his bulk.
And the teakwood stand is there too—I steadied them both with my feet.
Trowley appeared on deck just as a shot from the Cristobal struck the teakwood rail of the Heart of the West amidships.


text:
© 2002-2017
Encyclopaedia Metallum
Best viewed
without Internet Explorer,
in 1280 x 960 resolution
or higher.
|Peter Wildoer
|Pierre Richter
|Guitars, Vocals
|Jesper Granath
Title of the demo is "Prophesy". Stated on the title-edge and the labels of the tapes (both sides). However the tracklist mentiones "Prophecy".
|Added by: FrayedEndsOfSanity39
|Modified by: berzeviczi
|Added on: 2005-08-26 12:50:25
|Last modified on: 2014-09-04 12:27:41