Is this a Bug concerning "published/unpublished" of a resource

212 Posts

lettis Reply #1, 14 years, 11 months ago

When we unpublish a site by php using the following code the site is as expected not marked as published in the backend anymore but unfortunately the site is still accessible to not logged in visitors in the frontend. (When we unpublish a site manually in the backend and not by this php-code the site is not accessible for not logged in people):

$htmlsiteasobject = $modx->getObject('modResource', $idhtml);
$htmlsiteasobject->set('published', '0');
$htmlsiteasobject->save();

Does anybody know if this is a bug? Or do we have to make some changes in the code? Would be great if anybody knows this ...

Letti [ed. note: lettis last edited this post 14 years, 11 months ago.]

MODX Staff
10,725 Posts

opengeek Reply #2, 14 years, 11 months ago

You have to refresh the cache after the save, at least for the context in which the Resource appears. Just add something like this after you save the changes to the object:

<?php
$modx->cacheManager->refresh(array(
    'db' => array(), /* clear the db cache if cache_db is enabled */
    'auto_publish' => array('contexts' => array($htmlsiteasobject->get('context_key'))),
    'context_settings' => array('contexts' => array($htmlsiteasobject->get('context_key'))),
    'resource' => array('contexts' => array($htmlsiteasobject->get('context_key'))),
));

That said, this only unpublishes a single Resource. If you are trying to temporarily make the site inaccessible, you'll want to change the site_status setting to 0 (and then clear the cache by calling refresh() with no arguments, so everything is refreshed). Whatever you do, do not try to unpublish a Resource that is the site_start or you could get unexpected results.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

212 Posts

lettis Reply #3, 14 years, 10 months ago

Btw: We very often get this error-message in the modx-log-file:

(ERROR @ /connectors/resource/index.php) Could not cache context settings for web.

Is there anything we can check in our settings to avoid this error-message?

MODX Staff
10,725 Posts

opengeek Reply #4, 14 years, 10 months ago

Make sure if the Context is meant to be publicly accessible that anonymous users have "load" permission to that Context.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

212 Posts

lettis Reply #5, 14 years, 10 months ago

Anonymous users have "load only" for the web-context. Is this correct or do we have to change this?

In addition: When we work in the MODx-Backend (saving resources etc.) on traffic peak hours (~1.000 visitors per hour) the error-log often shows messages like this:

[2011-11-02 15:16:49] (ERROR @ /index.php) Could not cache resource 637

and

[2011-11-01 17:37:39] (ERROR in xPDO::connect @ .../core/xpdo/xpdo.class.php : 344) SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'sending authentication information', system error: 32
[2011-11-01 17:37:39] (ERROR @ /index.php) Error preparing statement for query: SELECT `modSession`.`id` AS `modSession_id`, `modSession`.`access` AS `modSession_access`, `modSession`.`data` AS `modSession_data` FROM `modx_session` AS `modSession` WHERE `modSession`.`id` = ?  - Array
(
    [0] => 00000
)

Is there any possibility to change for example the cache-settings to solve these kind of problems when working in the Backend on peak hours? These problems often let disappear our website for maybe 1-2 minutes.

Do you have any idea what we may have done wrong in the settings our in file-permissions/chmod?

MODX Staff
10,725 Posts

opengeek Reply #6, 14 years, 10 months ago

Losing the connection to MySQL while sending authentication information indicates that you are perhaps using too many connections. You might be able to address that by fine-tuning MySQL, or maybe by using the standard file-based session handler, which avoids connections for session handling. MODX uses databases for sessions by default, but you can set session_handler_class to empty to use whatever is configured in your PHP as the session handler.

The errors caching the context and/or resources might just be two simultaneous requests attempting to write the data at the same time. If one has a lock already, the other request will try a few times and then give up, causing that error to be output. But it does not necessarily mean you have a problem. This just avoids multiple writes of the cache files by competing requests which can lead to cache file corruption.

Jason Coward
Chief Architect @ MODX
http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek