version 3_16_3, 3_16_1 and probably earlier
file: packages/cms/page_templates/page_remote_content/page_remote_content.inc
line: 22
require_once 'HTTP/Client.php'
should be
require_once 'HTTP/Client/CookieManager.php'
Susie
Event listener cache not updated on step_03.php
Also:
- packages/data/data_source_xml/data_source_xml.inc
- packages/ecommerce/delivery_methods/default_delivery_method/default_delivery_method.inc
have the same bug
No, we use the HTTP_Client package from PEAR – our installation instructions and requirements list this. Our CookieManager is used only by remote content. The CookieManager.php will be called by persistent_cookie_manager.php.
Sorry, I didn't install it, I was just trying to compile and it didn't work. Not sure how it was compiled originally if we don't have the pear stuff installed. Will install it now.
When you say "compile", do you mean running step_03.php as part of the install? If so, you will need the PEAR HTTP_Client installed, yes. Matrix itself is not a compiled application: the PHP is compiled at runtime by the Apache PHP module. We do recommend using a PHP opcode accelerator like eAccelerator to improve performance (so that the module doesn't have to recompile every script on every page load).
We refer to running step 3 as compiling, as it is easier to say and is a similar concept. We have been doing significant module development, so it needs to be 'compiled' regularly, not just on installation. This is only on our dev box, so we don't run an accelerator on it.
whilst we are talking about step 3, any idea why it 'remembers' things you have already compiled? E.g. if you write an event listener, then 'compile' it, then remove the event listener, then 'compile' it again, the event listener still works?
The developers can probably answer this in more detail, but its probably because step_03.php just adds/removes database entries for assets. I can understand why you use the term compile to refer to step_03.php, but it really isn't a compile at all (or even remotely similar). Essentially, step_03.php reads the package contents and adds/removes asset types and attributes from the database.
When you say "event listener", what exactly are you referring to? If you remove an asset and re-run step_03.php, then that asset type should no longer be instantiable (and any existing assets of that type will break).
You use an event listener for keyword replacements.
step 3 doesn't just add/remove things from the database, it reads your code and creates new php files in the data directory based on your code. It then takes the structure of your asset from these files, rather than your original code.
I'm out of my depth, I think. We shall have to wait for the developers to read the forum.
Edited to add that the private/events/event_listeners.inc cache file should be recreated on step_03.php, so if it isn't, that may be a bug. When the developers get here, they will know for sure.
e.g. my pgstudent_loader template has a keyword replacement event listener
after 'compilation', in /data/private/events/event_listeners.inc suddenly
'page_pgstudent_loader' =>
array (…),
appears.
new lines also appear in:
private/asset_map/cms.xml
and private/db/asset_types.inc
also these folders get added
/private/assets/page_pgstudent_loader (this one is needed for recording assets themselves)
/public/asset_types/page_pgstudent_loader
/private/asset_types/page_pgstudent_loader
the last two containing localised screens and images.
(we run the localised screen script as part of our 'compilation' process)
So I suspect there is perhaps an issue with the event_listener.inc not being updated properly as part of the step_03.php process when asset code is removed?
it is possible that they've already fixed the bug, as I haven't tested it yet in 3.16.3
but when we were using 3.14.x, it took me a while to figure out why my keyword replacements in my template didn't work when I had made an exact duplicate of another template. I discovered that keyword replacement code had been removed from the template I was copying, but it hadn't been automatically deleted from the event_listener.inc file on 'recompile', so the keywords were still working for his.
I couldn't find anything in the Bug Tracker about this, so I'm doubting it was even looked at, to be honest. You may want to log this as a bug over at the tracker (http://bugs.matrix.squiz.net).
Also, I've changed the title of this topic to reflect the majority of the discussion.