[TYPO3-english] Download website as static (html5)

Mark Boland mark.boland at boland.de
Fri Nov 14 12:06:22 CET 2014


Hi Bernd,

  of course, building a lot of index.php^H^H^Hhtml would not enable 
  turning pages.

yes, and the ?id= parameters are lost in static exports (one single file 
index.php overwritten 100 times). This also means that everything dynamic 
won’t work or has to be rewritten (forms?, search?). Most of the 
javascript has to be stripped (that’s up to you, you build a separate 
template for the export(s)). But cachable content will be included (news, 
comments, calenders from the time of export, even standalone 
javascript/Flash/Video).

  modularity is better for extensions

Yes, definitely. We thought about a pluggable spider and export system.



  what I have in mind would not really benefit from cache:
  think about an individualized catalog where the user do some selects and 
  the resulting products will be stored in a small brochure like ebook:
  just a general introduction, then the (up to 50 out of >10000) products 
  with full description, maybe an overview, and last some general 
  information like 'terms and conditions'

I’m not only talking about caching full pages, but downsized images, 
content elements, plugin outputs etc. You simply can’t export > 100 pages 
in a short period of time (say, hours) if you don’t have any information 
cached - let alone on demand in the frontend (with a timeout of about 240 
seconds). So it’s good if someone else already cached this ;-)



We had prepared a „marketing“ announcement, but due to lack of time did 
not publish it, yet:

---

Interested in an Help Authoring System based on TYPO3? We are currently 
working on a module that helps us to build Online Help files for our 
projects. When the customer called for translated help files for major 
european countries, we thought about taking TYPO3 for implementing this. 
Until now, a working multi-lingual OpenSource package for such a task was 
nowhere to be found (Drupal tries this with a package, but its features 
are far from what we plan to do with our project). The extension will be 
suited to write (as a group) hyperlinked, structured Online Help files 
(e.g. CHM, Java Help etc.) as well as page oriented manuals, exported in 
PDF and similar formats.

The system features:

* Export modules (CHM project package (implemented), static HTML pages 
(implemented), PDF, RTF, Latex, ReST and DocBook)
* Multi-lingual support (separate files/packages)
* Index from markers in RTE (implemented) and additional fields in Content 
Elements ("Text-with-Pictures")
* TOC from page tree (implemented)
* All TYPO3 features, e.g. multi-lingual support, multiple uses as Website 
with comments and nightly builds of export-packages/files, content from 
news, blog and all other extensions

* Parametric output via GET parameters (e.g. template switching, client 
specific content, internal/external documentation, watermarks like "draft 
mode" etc.)
* Highly modular in design. All indexers as well as the exporters will be 
highly extendible
* Internal references, footnotes, picture/table indices, workspace and 
scheduler support currently in planning mode

The system is currently up and running. A single system hosts 3 Online 
Help projects with 5 languages in sync.

If enough supporters can be found we will publish the system as a GPL 
project.


---

Mark Boland






Am 14.11.14 10:31 schrieb "bernd wilke" unter <t3ng at bernd-wilke.net>:

>Am 14.11.14 10:10, schrieb Mark Boland:
>> Hi Bernd,
>>
>> the extension spiders by itself, can spider special page types 
>>(different
>> template, frontend with menu/spider without, different javascript etc.,
>> freedom of choice for templating engine (Classic, Templa Voila, Fluid),
>> can render several languages at once (we author our Online Help files 
>>for
>> Windows applications in 5 languages with it), can generate a TOC and an
>> index (both are also applicable to EPUBs) automatically (TOC from page
>> tree layout, index from index markers in RTE). The results are cached, 
>>so
>> it could use a scheduler job to prepare the files every night and 
>>deliver
>> them on a push of a button.
>>
>> There is also a commercial solution that is not connected to our project
>> that we found after we finished the first beta (life is cruel 
>>sometimes).
>> I can’t find the URL at the moment, but I’m sure it is still alive.
>>
>> There is currently no frontend plugin for it, but I don’t think that it
>> would take long to make one.
>>
>> We did cut some corners, though. You definitely need RealUrl (or some
>> other form of URL rewriting) and the project in its current form is
>
>of course, building a lot of index.php^H^H^Hhtml would not enable 
>turning pages.
>
>> tailored to our needs. For example, we would have to split the export 
>>and
>> the spider module to enable different export types.
>
>modularity is better for extensions
>
>> As already said, spidering needs some time (though the process could use
>> the frontend cache, when running as a frontend plugin) and resources –
>> hey, you _are_ ordering TYPO3 to generate all pages and content elements
>> for you.
>
>what I have in mind would not really benefit from cache:
>think about an individualized catalog where the user do some selects and 
>the resulting products will be stored in a small brochure like ebook:
>just a general introduction, then the (up to 50 out of >10000) products 
>with full description, maybe an overview, and last some general 
>information like 'terms and conditions'
>
>the end format is not determined and could be any format usable as one 
>unit (ebook, pdf, chm, ...). zip would be not so good as it exploded to 
>single files.
>
>bernd
>-- 
>http://www.pi-phi.de/cheatsheet.html
>_______________________________________________
>TYPO3-english mailing list
>TYPO3-english at lists.typo3.org
>http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english



More information about the TYPO3-english mailing list