What I'm aiming to do!
I'm creating a template for a site in typo3, and i'd like to get rid of typo3's default content zones, and replace them with my own.
I.E. On the page menu.
to remove left, content, border
and to keep/add. Header. Main. Right.
The problem!
I've found snippets around the web, and bluntly, what I'm expecting to happen, isn't happening. Where every post seems to be "Thank you, great success! ++", the code I paste isn't throwing any errors, and isn't doing anything, well, at all.
My attempt
Via the typo3 documentation http://typo3.org/documentation/snippets/sd/24/
I call mod.SHARED.colPos_list in order to choose the three sections to display
t3lib_extMgm::addPageTSConfig('
mod.SHARED.colPos_list = 0,1,3
');
And I edit the TCA in extTables.php to set them to my specs.
$TCA["tt_content"]["columns"]["colPos"]["config"]["items"] = array (
"1" => array ("Header||Header||||||||","1"),
"0" => array ("Main||Main||||||||","0"),
"3" => array ("Right||Right||||||||","3"),
);
extTables.php is being called as as a die(); cuts the page.
I've cleared the cache and deleted typo3temp, logged out and in again.
But nothing happens.
My main guess, is, is this feature anything to do with templavoila? I removed it as I felt like trying out the new(er) typo3 fluid templating system, and didn't feel that I needed a GUI editor.
Any ideas?
Well - the more pages and content elements you got the more problems you will have to face when using TemplaVoila. Having comma separated values in XML structures saved to a single database field will be a performance killer as soon as you want to collect content from more than one page (uncached teaser menus or the like). Handling of references and "unused elements" is questionable as well. Of course it will work for small to medium sites, but concept wise a clean approach looks different.
Backend layouts are available since TYPO3 4.5 and work flawlessly since they just represent a normalized relation between elements and pages based on colPos. If you need more, Grid Elements will take this principle to the next level, offering even nested structures but still based on normalized relations, which will make your life much easier when it comes to DB cleaning and other maintenance tasks.
Find an introduction to backend layouts here: http://www.youtube.com/watch?v=SsxfNd4TYbk
Instead of removing default columns you can just rename them...
TIP: Use TemplaVoila extension for templating, you'll find much more flexibility there.
Related
I have recently tried creating a website using the Jekyll GitHub template here. One major alteration I hope to make to this template is to have two "blogs" in the format provided in the Blog tab of that template specifically shown here.
I (sort of) successfully created two blogs in my website and named the associated tabs (Media) and (Blog). I achieved this by reorganizing the file structure to have a "media" folder and a "blog" folder separately that each contain a _posts folder and index.html file. Now, when I add .md files in the _posts folder, these posts seem to get added to the correct tab (Media or Blog).
Even though that functionality works, both the Blog and Media tab lost their aesthetics compared to the style in the original template blog. Namely, 1) the banner image at the top is now gone; 2) the text formatting with the title in one line followed by the date in the "pretty" format (gray colored and in the format 29 Aug 2016) is now in a less-attractive bullet format with date first and in the format Aug 29, 2016; 3) the introductory excerpt text (in the example: "A pot still is a type of still used in distilling spirits such as whisky or brandy. Heat is applied directly to the pot containing the wash (for whisky) or wine (for brandy).") is now gone.
It is unclear to me why my separation of the _posts folder into two separate folders seems to cause these unwanted layout side effects. Since all three of these layout issues changed at once, I am assuming they can all be solved in the same solution. Whether or not that is true, any advice on how to solve these layout issues could be very helpful. Thank you for sharing any ideas!
You've removed the posts collection from your _config.yml which was setting the default feature_image for all posts. Unless you add that back in or include the overrides in each individual post it will not display the header (it may or may not also affect the rest of the styles):
collections:
media:
title: Media # Needed for Siteleaf
output: true
description: "Recent discussions with the media." # The post list page content
feature_text: |
Sharing our motivations and
opinions with the media.
feature_image: "https://picsum.photos/2560/600?image=866"
You're not actually using a media collection in either blog/index.html nor media/index.html, you're using the post.categories for filtering in the end, which will still causes some weird pagination once you start getting things rolling.
You may want to look at using the separate collections and then pre-building your site using paginator v2 (https://github.com/sverrirs/jekyll-paginate-v2/blob/master/README-GENERATOR.md) which will allow for pagination of different collections.
Edit 2020-01-23
Taking a new look at your repository, you still only have one (posts) collection. Therefore the logic for reading feature_* is being shared. If you look at the include site_feature.html you can see how the feature_image is being parsed out of the collections.
{% assign collectiondata = site.collections | where: "label", page.collectionpage | first %}
Which in your case is why Blog and Media both have the second image ?image=213. Your blog.html and media.html still have the front matter collectionpage: post.
I still think you're going down a slippery slope which will result in things not working exactly as you want them once you get more and more posts by doing it this way.
I'm probably biting off more than I can chew with this particular problem, but I'll try to be as specific as possible in case it's within my scope. Disclaimer: I'm not terribly experienced with MS Word, beyond simple data entry/some formatting, and I have absolutely zero experience working with macros or VBasic. Unfortunately, I'm afraid the solution to my problem will come in the form of one of those last two.
THE GOAL:
What I want to do is to have placeholder text throughout my template document that will change content but not formatting when the first instance of it is changed. Basically, I'm writing a template for support manuals for a software suite. Each app has certain similar features like the menu bar, data entry screen, diagnostic log screen, transaction history, etc., so I am pre-writing those sections and using placeholders when I need to insert certain app specific properties.
I started off using the Insert->Quick Parts->Document Property->Subject tool which I used as a placeholder for the app name. I set the Property to [Subject] and then used Insert->Quick Parts->Field->Subject throughout the document, wherever I needed to include the app name. This worked fine in this case because the app name will always be capitalized. I simply change the text in the first [Subject] (which is content controlled) and update the fields throughout the document, and they all match nicely, easy-peasy, work done, go home and drink beer, right?
Not quite.
Our software handles part tracking via scanners and SQL Server, so while the interface and menu in the apps remains largely unchanged, the parts they track change from app to app. Because of this, I need to change the part name when I reference it within the text of the manuals; for example, if I'm working in ToiletPap.app and our TP is tracked by the roll, I need every mention of [Component] to be changed to roll. If I'm working in LightBulbs.app, I need [Component] to say bulb.
My first efforts went toward creating a custom doc property called Component using the Advanced tab under the Document Properties dropmenu. I then created a plaintext content control around my first [Component] titled Component and made my next [Component] a field with modified code: {COMPONENT * MERGEFORMAT}. This comes from copying what I can find when [Subject] works. This didn't work at all; updating the text in the first CC doesn't change the Content doc prop, and my fields return "!Undefined Bookmark, COMPONENT".
I got close to what I need by using the [Comments] doc property, set initially to [Component]. I used it just like [Subject], but (this is when I realized that capitalization was going to be an issue) when I mention my [component] in-text, as often as not, I need to to be lowercase instead of upper.
I've looked on MS's forums and a few others as well as here on SO, and I can't find anyone who's trying to do the same thing, much less an answer to how. Please keep in mind when answering, it would be a great help to me if you would include step-by-step instructions on how to enter/implement the code you provide because, as I mentioned, I have no idea how to go about editing macros/VBasic for MS Word.
To restate and summarize my overall question: How can I use a placeholder that displays the text "[Component]" so that, when I change the first instance of [Component] to something else, say "hopper", every subsequent instance of [Component] is updated to hopper but maintains its current capitalization and formatting scheme?
Apologies for the length of the request, but I wanted to make sure I explained the situation as accurately as possible. Thanks in advance for your consideration and responses.
I managed to solve this one after a couple extra hours of tinkering. I didn't need macros or VBasic, either.
On the first instance of [component] I created a plain-text content control to act as a container (not a necessity, but it makes it look nicer. Will likely cause a problem eventually, but for now, it's working as intended) and bookmarked it. Then, for all other instances of [container] I selected each and used Insert->Quick Parts->Field->Ref with the following field code:
REF Text1 \*Lower
Where "Text1" is my bookmark and "*Lower" indicates all lower case. The *Lower can be replaced with *Upper or *FirstCap to indicate all upper case or capitalize the first letter respectively. Now, each field reflects the text of the first with the capitalization appropriate to each field's location within the document. Just like using the doc prop with [Subject], ^a -> f9 is needed to update all fields within the document.
I am stumped beyond belief.
I have a select box being generated by the cakephp form helper. I am feeding it an array of options, and passing an empty value... pretty standard stuff.
However, my "empty" field is showing up at the very bottom of the list.. not the top. So when the field loads, it just defaults to the first option... which is not the "empty" option.
Not a whole lot of room for error on the code here..
echo $this->Form->input('whatever',array('empty'=>'Choose One','options'=>$categories));
The only small item that might be important, is that $categories is a multi-array, so the select box has optgroups & options.
Is there some quirk/bug out there that I do not know of that is trying to force me to sneak into my scotch supply a few hours ahead of schedule?
edit: using the latest release of cakephp 1.3.x
I think that I once had the same problem.
It turned out to be the data (options array).
Is there an option with an empty key? probably the last one then.
this lead to the scenario I remember and seems to be the exact same thing.
the form helper will override this empty key value pair then and not create a second one.
without more infos from your end this will be difficult to solve.
This may be a very basic question. But it is not very clear to me, the difference between
setItemCountPerPage and setPageRange. The zend manual defines both as below. I don't see a difference on reading it. Could someone tell how they are different, may be in the context of actual usage. Thanks
setItemCountPerPage : Sets the maximum number of items to display on a page (default 10).
setPageRange : Sets the number of items to display in the pagination control (default 10). Note: Most of the time this number will be adhered to exactly, but scrolling styles do have the option of only using it as a guideline or starting value (e.g., Elastic).
setItemCountPerPage refers to the ACTUAL DATA you are paginating.
setPageRange refers to the PAGINATION CONTROLS (the little HTML snippet with links to the other pages). Check out the different pagination styles in your pagination controls and it will become very obvious what this is.
You can really use one without the other though they work together so well that I usually see no point in separating them.
related to this question Zend_Form - Array based elements?
$form = new Zend_Form();
$subForm = new Zend_Form_SubForm();
$subForm->addElement('Text', '1')
->addElement('Text', '2');
$form->addSubForm($subForm, 'element');
$var = '1'; $var2 = '2';
echo $form->getSubForm('element')->$var;
echo $form->getSubForm('element')->$var2;
If I use this way output will wrongly be (or at least not quite expected)
<input type="text" value="" id="1" name="1">
If I use echo $form output will correctly be
<input type="text" value="" id="element-1" name="element[1]">
but I loose flexibility then
I am not saying it's a bug or something just not sure what proper syntax will be.
Thanks
So the answer is rather late, but I recently ran across this issue and though I'd share the reason and possible solutions.
From my research, there are at least 7 bugs in Zend's ticketing system dealing with this problem - though the descriptions vary dramatically.
(SO has prevented me from pasting all of the links, so I'll link one and give you the ticket IDs for the others: ZF-9386, ZF-3567, ZF-9451, ZF-7836, ZF-9409, ZF-7679)
http://framework.zend.com/issues/browse/ZF-10007
The one that best describes the issue, and possible fixes, is 10007 - however, ZF themselves have inexplicably chose not to fix it until 2.0.
The problem stems from the fact that when explicitly using:
$this->form->a->b->c->d notation, d will forget every one of it's ancestor subforms, except for it's immediate "c". When you have a big form with custom behavior, this is quite burdensome because you may want to render the whole subform "d" without calling out it's specific descendents, but you may want it in a certain spot or the Zend Decoraters may not be able to pull it without a bunch of work or at all.
I should think this would be a common problem in the subform world, since by definition you're working with complex forms and excepting the most generic of forms hardly any of it would be linear or clearly separated by dt/dd or other clean markup.
There are three ways I found to deal with this issue.
The first is the fine patch contributed in 10007 - this won't work for me because it only works with printing a subform directly and not individual elements - which is about 50% of my use case. Not knowing ZF well enough, I did not pursue extending this functionality to elements as well.
The second is to forgo all custom html around the elements and add enough decorators to satisfy the layout. Although mine are structured well with TRs/TDs, etc., I just couldn't justify the time nor the decision to 100% ZFify our most complex forms - because someday it could be that ZF would not be the best choice.
The third is a much more cut and dry tradeoff, which is what I chose: I would forgo the convience of being able to echo the $this->form->a->b->c->d subform, and instead individually echo all of my elements in their apppropriate spots (like echo $this->form->a->b->c->d->element1 and echo $this->form->a->b->c->d->element2). This keeps my HTML out of the decorators which has its tradeoffs, but keeps my forms in ZF, which is all I want. With this solution, you can now call setElementsBelongsTo() on the d subform and use array notation to get the submission to behave properly, like so:
$objSubFormD->setElementsBelongTo('[a][b][c]').
Please be mindful that I've dumbed down these examples almost beyond practicality so the (dis)advantages may not be immediately clear for each one, I've only given what I perceive to be options and what I chose as a solution. I also feel my solution gives me the best upgrade path to ZF 2.0.