I am not aware of any module which provides this functionality.
-----
This module is designed to take a page generated by your site and break it into a
header and footer. This is useful when you have other sites providing content for you
on their domain and you need your design wrapped around their content. Based on the
capabilities of the other site, they can dynamically request the header and footer so
that it is always up to date or you may cut and paste the generated HTML into their
administrative systems when an update is required. This module takes care of modifying
relative links and references to images/js/css files and will save a copy of aggregated
JS and CSS files so that they remain available even through aggregation cache clearing.
This module splits a page generated by your site by looking for a string that
indicates where the split should be performed. The string to look for is configurable in
the admin section and there are many options for placing the string in your page. It can
be placed as the content element or added to a template file. This module makes no
restrictions on how you mark the location for the split.
Example of setting up a wrapper:
Create a page on your site with no content other than the string to split the wrapper on. It is recommended that the string take the form of an HTML comment since it will be output as part of the header portion of the wrapper.
Configure the admin settings to set the string to look for.
Note the URL of your page. For this example assume it is example.com/pet_wrapper
To retrieve the header, make a request to example.com/third_party_wrappers/top/pet_wrapper
To retrieve the footer, make a request to example.com/third_party_wrappers/bottom/pet_wrapper
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | third_party_wrappers.tgz | 2.91 KB | tekante |
| #7 | third_party_wrappers.tgz | 2.87 KB | tekante |
| #5 | third_party_wrappers.tgz | 2.87 KB | tekante |
| #3 | third_party_wrappers.tgz | 2.86 KB | tekante |
| #1 | third_party_wrappers.tgz | 2.95 KB | tekante |
Comments
Comment #1
tekante commentedModule uploaded
Comment #2
avpadernoStrings used in the user interface needs to be translated; this includes also the strings used as options for the form fields.
The code should use
file_scan_directory().As the file is in the server running Drupal, why isn't the code using a local path, rather than using a URL, which could be not allowed from the PHP configuration?
See the Drupal coding standards to understand how a module code should be written.
Strings used in user interface should have the first word in capital case, and the other words in lower case (with the exception of proper nouns, adjectives derived from proper nouns, and acronyms).
Would not be easier to use directly the constant?
Not considering that the constant is not correctly written, if there is not the need to define access arguments, then that array index can be omitted. I am not even sure of the effect of setting those arguments explicitely to
NULL.Menu callback titles, and descriptions should not be passed to
t()because that is already done by Drupal core code.Comment #3
tekante commentedThank you for the feedback. Attached is an updated module bundle which corrects identified issues. Issues which could not be corrected are discussed below.
1. All module generated strings should now be run through the t function.
2. Switched to using file_scan_directory().
3. The requested contents are a Drupal generated page, not a file on the filesystem. Changed to using drupal_http_request to make this more clear.
4. Corrected brace style to match coding standards
5. Corrected capitalization
6, 7. Corrected declaration of access callback so that access arguments and function returning true were no longer necessary.
8. t function removed from menu strings.
Thank you, please let me know if I was supposed to enter a new account request as I wasn't sure if this counted as a rejection message.
Comment #4
avpadernoI am still not convinced there is really a use case for this module, and if somebody could reach the same purpose using a different method / module.
The following lines should be better written, IMO.
The module is requesting the page to view through
drupal_http_request(), passing to the function the content of$_GET['q'], which would include the string third_party_wrappers; what is the result ofpreg_replace('/^[^\/]*\/[^\/]*/', '', "third_party_wrappers/user/12"), and what should the result be?Comment #5
tekante commentedI am not aware of any other methods for accomplishing the task this module accomplishes but I will look into any you suggest. We use this module to allow other sites that provide content to have an updated wrapper with little additional work from us. For example, our St. Augustine newspaper uses ZVents for calendering: http://go.staugustine.com/
In order to keep this up to date with our latest wrapper, we have them automatically pull from
http://staugustine.com/third_party_wrappers/top/zvents
and
http://staugustine.com/third_party_wrappers/bottom/zvents
which they surround their calendar code with. This way when we change menu items or designs the go.staugustine.com site stays up to date.
Your provided example is an invalid request I had not considered. I have enhanced the code to capture and report when invalid requests are made. The newest version is attached. I will give you the result of a similar valid request:
preg_replace('/^[^\/]*\/[^\/]*/', '', "third_party_wrappers/top/user/12") results in /user/12. The module will then make a request for the URL http://local_server/user/12 and then return the header (top) based on the portion requested.
Comment #6
tekante commentedComment #7
tekante commentedUpdate of module with changes based on coder module recommendations.
Comment #8
dawehnerI think http://drupal.org/project/libraries does the same
Comment #9
avpadernoThe name could make you think so, but the purpose of the proposed module is to get a page from the local Drupal site, split it in two parts, and return the two parts as output of two different URLs.
So, http://staugustine.com/third_party_wrappers/top/zvents, and http://staugustine.com/third_party_wrappers/bottom/zvents are two parts of a single page (http://staugustine.com/zvents).
Comment #10
tekante commentedIs there more information that I need to supply for this request? Kiamlaluno's response to dereine's question is correct. I do not believe libraries matches the purpose of this module.
Comment #11
avpadernoI am adding the review tags.
Comment #12
avpadernohook_disable()should be moved inhook_cron(), if it is not already included, andhook_disableshould be removed.Comment #13
tekante commentedThe code in hook_disable is for cleaning up module created files and directories when disabling the module. To put that code in hook_cron would incorrectly remove those directories on each cron run rending the module non functional. There is code in hook_cron cleans up module created files older than a certain age if the module is configured to do so but leaves the directories present.
Could you be more specific on the coding standards? I believe I have followed all formatting requirements and naming conventions with the version uploaded in #7.
Comment #14
Anonymous (not verified) commentedThe problem with
hook_disable()is that can cause a PHP timeout, if there are too much directories / files to deleted, whilehook_cron()is executed when the PHP timeout has been raised.There are just two alternative to this: have a list of directories that can be safely removed on
hook_cron(), or increase the PHP timeout before to executehook_disable(), in the same way done by drupal_cron_run().Comment #12 reports exactly what needs to be checked. Coding standards reports how the code should be formatted, and report that code as
if ($test) continue;is not formatted as it should.Comment #15
tekante commentedI have added in the extension of the timeout in the disable hook as I can't mark directories for removal from in cron (since the module will have been disabled the cron hook would never run). I have been unable to find the code you reference as not adhering to the formatting standard. There is no continue anywhere in my module nor are there any unbracketed if statements. I'll be happy to fix if you can reference a line number but so far the coder module is reporting everything as clean and adhering to the standards for me.
Comment #16
avpadernoConstants needs to be written in upper case characters (
NULL,TRUE,FALSE,MODULE_CONSTANT, etc).Comment #19
avpaderno