Part I: the Search-Form from Hell
I spent the first half of the day today trying to figure out why my search-form wouldn't work. Most of that time was spent wrong because I was searching for "indexed search function", whereas the functionality referred to in "Praxiswissenschaft" happens to be the normal, non-indexed one. In the end, I did 3 things that possibly caused the form to eventually work:
1) I deinstalled the extension "indexed_search" that I had installed yesterday in the belief that it was needed.
2) in the file typo3_src/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php I changed line 732 of code from this:
$content .= $hookObj->cObjGetSingleExt($name, $conf, $TSkey, $this);
to this:
$content .= $hookObj->cObjGetSingleExt($name, (array) $conf, $TSkey, $this);
This change was based on a tip that I found via google that seems to address the error message I kept getting: that a second argument was expecting an array and receiving something else.
This change caused the page to go from displaying an exception error to displaying the page with the marks for the searchform, "###SUCHE###", instead of the actual search form itself.
3) Finally, the tip that Meyer's book gives, and also to be found in several pages via google, is to deinstall the "form" extension. When I did that yesterday, in place of an exception I got an internal server error instead, which is actually worse. Today was the same thing. Only after lunch, by following steps 1 and 2 again, and then (again) deinstalling the "form" extension, did the search form finally work.
Logically, this should have happened yesterday as I had followed steps one and two, before installing the indexed search. The ways of Typo3 are shrouded in mystery!
Now I am free to continue the "content" chapter of "Praxiswissenschaft".
I found out a way to supplement the root template TypoScript without literally typing it in the text area: under "Template" for the root page, select "TypoScript object browser" instead of "Info/Modify". Click on the TypoScript object you'd like to modify and a form comes up called "Edit object/property value". Enter the object property in the text field and click up "update". In the root template, the correct code for this property attribution can now to be seen.
Using this method to change properties is a good way to avoid the typos and mistakes of typing code in by hand; however, it does not have the benefit of code-organisation that can be attained by doing the same thing manually. Additionally, clearing and reseting values in this way makes a mess of the TypoScript in the template textarea, much like creating HTML markup with a WYSIWYG editor. I'm going to decide for clean code and write my TypoScript by hand - I need the practice, anyway.
Part II: Static-Dynamic Content
In order to create a content area that appears on every page (for example, news items on the right-hand side of each page) whose content is dynamic, a mark within the template is necessary, but does not alone suffice. It's also necessary to, once again, set up a helper-page, just below the root page in the site structure. This new helper pages's properties include being of type "shortcut", redirecting to the homepage if called directly in the browser, having enabled visibility, and yet be hidden to the menu. This last property can be achieved by selecting the "Access" tab within the "Page" section and then checking the box "In Menus - hide". Finally, in order to bind this helper page's content into the template that is used by all pages, the following code needs to be implemented:
#make "RECHTS" (right-hand side) marker a content object array
RECHTS = COA
#read out the content of right-hand column of the current page into the RECHTS marker in all positions
RECHTS.10 < styles.content.getRight
RECHTS.20 < styles.content.getRight
#the content of the right-hand-side column should, however, only be read from a list of pages whose page IDs are explicitly set below
RECHTS.20.select.pidInList = 17
It's additionally suggested that in order to prevent the contents of this page from being cached, which would prevent new content from appearing without first manually emptying the cache, the object type COA_INT instead of COA can be used.
Part III: customising your backend (ha!)
In order to create a customized backend layout to make content management for editors easier, click on the "List" module under "Web", and then click on the "root" page. In the upper left-hand corner to the new window, click "create new record". A list of possible types appears; select under "System records" the type "Backend layout". There, enter a name for the customised template and then click on the image next to the text field under the label "configure". This will open up a new window where columns and rows for a table can be defined: each cell of this table needs a name and a unique column number.
After saving this configuration in the new window AND in the opening window (otherwise, the work is lost - I had to find this out on my own), click on the root page and select "edit" from the context menu. Under the tab "Appearance", it's now possible to select the new template as "Backend Layout (this page only)" and "Backend Layout (subpages of this page)". Remeber to save! Clicking on the "Page" module under "Web" and selecting the root page will now show the new template for entering content, instead of the the default one. In this way, it's possible to customise content-entry forms and make them more user-friendly for editors.
Prologue
Today I got through one chapter of "Praxiswissen", with one major problem (the non-functionting, error-causing search form) and two minor ones: getting the dynamic right-hand area of every page to show the same content (I had initially put the new right-hand content area in the homepage instead of in the root document) and not being able to FIND the area for adding a customised backend layout (the instructions in the book skipped the step of getting to the "System records" list of choices). I was able to solve them with a little experimentation and a lot of googling.
The seas have calmed, wind and weather are good, routine has entered the daily course of being on board the Hackership and I am actually learning somthing practical.
The first two weeks are over, four to go. Will I have time to immerse myself in test-driven development with PHPUnit? Will I be able to figure out how to configure my Jenkins CI server to run these tests as jobs? I think I'm going to have to invest in more resources (i.e. e-books). Without "Praxiswissen" my ship would have, by now, floundered on the rocks of bad documentation with no help in sight.
Who's sick of the seagoing metaphores already?
Too bad!
No comments:
Post a Comment
Play nicely!