ceberlin

Hi, with one of the latest releases, there came something new: Hovering the fields top bar there turns up now the field's original name in grey, which makes the admin page flickering a lot, when moving the cursor over any of the expand ("v") buttons. Is that something I can switch off? (Or where does the effect come from out of the sudden?) I have the fields names already with the excellent module HelperFieldLinks.

Hi, I did not find that mentioned before, there is another limitation of field dependencies. Chains do not work (yet). example: field1, field2(hidden), field3(hidden): 1. Display field2, if field1 has a string -> works! 1. Display field3, if field2 has a string -> works NOT, if field1 is still empty and therefor field2 is still hidden, error: Session: Max number of iterations reached for processing field dependencies (ProcessPageEdit)

I do not think those extra few carriage returns matter too much. Planning the "presentation" of source code is for psychological reasons: e.g. if 3rd parties (clients?) look at the code. So, the "purpose" of minimizing html may vary from user to user.

Hi, one quick question: Is there a way to set it up that it cleans the HTML but leaves the line breaks intact? So I see a clean, neat website source code without spaces and comments but the code is not squeezed into one single endless line?

>> automatically displayed in the user's browser >This is not considered a good practice I test like this: 1. is there a url with the language in it, like "/de/"? (coming from a Google search result or because of my language switcher menu / or for search engines) if not, 2. is there a session with a valid language? (user decided already before) if not, 3. is there a cookie with a valid language? (user decided already earlier before) if not, 4. What is the language set in the browser? (yes, a bad practice, but clients sometimes demand that feature) if not - or not in the array of valid languages, 5. display a default language. (last resort fallback) So there is an automatic language switcher, but the user can change that any time, using my language switcher menu.

If I delete those empty fields (which I successfully did and had no incidents after that)... is it guaranteed that they do not come back? I want to double check: does PW 2.4 now delete those fields if not used, so that error has gone forever? I think so... Just for my curiosity: Would it help if the module ignore pages from unpublishing which are older than, say, 1975 (very old but younger than the infamous 1970)?

Sorry for the late reply, here is an example page: Notice: Array to string conversion in /site/modules/HelperFieldLinks/HelperFieldLinks.module on line 155 Fields on that page used are of type: checkbox, select, range slider (from a module), text area, page, text, pagetitle...

Just a tiny note: The htaccess file could say "@version 2.4" in the title comment area now as well - that would avoid maybe questions from updaters...

CONGRATULATIONS TO 2.4 ! An opportunity to thank Ryan and all contributors again for this wonderful software!

Hi, I just wanted to note that the php notice is still there, when using PHP 5.4 (not visible for PHP 5.3) I am using the PHP dev version. Can this have to do with languages?

Hi, the module is only checking the presence of tinyMCE and not of CKeditor, is this correct?

This module seems to be not working well with the latest DEV 2.3.13 of PW: - Throws an error about a button problem (I think to remember: InputfieldButton, line 253?) when deleting an entry. - Uses not PDO but Mysqlli (a "depreated" warning)

Sure, whatever you use it for - it IS extremely useful already! Thank you also for the ModulesManagerNotification module. I am looking forward to this.

Sounds cool! Didn't notice the "new version" filter works. Updating modules is mostly about possible included security fixes and also for keeping up with the ongoing rapid changes with the PW DEV admin-template changes. Since the main reason for using the module is looking for new versions (is this correct?) a shortcut would be nice, like a button, so that this feature becomes more obvious, i.m.h.o. Other cool searches would be: "Latest Additions" and "User Favorites" - as shown on the PW website. Drupal handles updates like this: You can subscribe to infos about updates of your installed modules from within the module manager settings, so you don't need to check yourself. That helps when maintaining many websites. - Special security alerts are sent by the Drupal team manually to subscribed users (and not by a module). Mails arrive if a security update of a module or the core becomes necessary. The mail gives some details about the problem as well as a severity ranking.

I am really impressed. Thank you very much! Just a small idea: I would love to have an easy option to filter the list to show only those modules which are installed and need an update. <dreaming> And if there was a weekly reminder mail about outdated modules (like Drupal does it), my live as admin would be even easier. </dreaming>

I like that feature too. Right now we print out this page and write the notes by hand. (For the same reason I include an "internal notes" textarea and a "reminder" date on every template, so I can leave internal comments on any page, if I need to remember something there.)

One more question about i18n. (I am exactly at the point of choosing between language trees or i18n for a new project, and just saw the i18n video): Assuming I have a template and using the i18n strings. Then I add that to the template path to the admin language support settings. Fine so far. What, if I ever need to rename the template later for some reason. Is then every translation lost or is it kept (updated there by PW)?

Hi diego, sure I can edit modules like this one myself. Adding a class is not that difficult This would disconnect the module from the update path and this is against the idea of community delivered turn-key solutions?

One more observation: The green label "This site is in maintenance" destroys my page setup and makes design testings tricky. If there was a css class with it, I could overwite the included hard coded styles more easily.

Is there an easier way to make this language aware than putting tons of fields in an individual add-on module? With all the new toys from the PW dev version? What, if an additional language comes? I am not sure editors want to edit modules code for that extra content fields?

WISHLIST: Forgot to mention that it would be great if those fields were language aware. Are they? SEO: Well its a bit off topic but interesting enough: I was mentioning the technical CMS need for an alt text. I was not talking about content in there. When talking about "the SEO guys", I do not mean manipulations, keyword stuffing and other eval things. They sometimes like to but things slightly differently in there than in the caption texts. And I want to make that possible, technically. - Client is king You could use that data also to output a "title" attribute - for a basic mouseover help text, and so on...

Now that tags are possible for images I wonder whether this could be stored with images also: - ALT - COPYRIGHT Why? I have the description field which I use as caption and as "alt" attribute at the moment. But my editors have problems with that and fill up the description with to much information. I would like to store some information separately: 1. description would be output as caption. 2. the alt attribute would be open for manipulations to the SEO guys - without them ruining the caption. If no alt attribute is set, I would output the the description and if there is no description either, a ".". So we are always validating with out the need to code this manually for every single image used. 3. The copyright: This could be placed where we like it, maybe at the bottom of the page. This is very important to make the usage of many stock images legal. And we do not need to misuse the description for that any more.

HI Pete, now I am using the DEV version. There is something funny: I set the module to redirect to the login page (default behavior). The "is in maintenance" info appears twice at the login screen. Maybe one time with the redirect and one time calculated new. Because it is only one time after I refresh the login page. Another idea: It would be great if the switch to put the maintenance mode on and off would be more accessible as a separate admin "setup" page and available to certain user roles - and not buried in the module's settings.

I see... I need to calculate the loop earlier (in the head already) and then have the info I need ... Here is my code in case s.o. wants to play with it further: I am trying this now within the page's head: $limit = 12; // the "limit"-setting used on this page $children = $page->children("limit=" . $limit); $totalpages = ceil($children->getTotal() / $limit); // PAGINATOR: set SEO tags for Google if ($input->pageNum) { if ($input->pageNum < $totalpages) { echo "<link rel='next' href='" . $page->url . $config->pageNumUrlPrefix . ($input->pageNum + 1) . "' />"; } if ($input->pageNum > 1) { echo "<link rel='prev' href='" . $page->url . $config->pageNumUrlPrefix . ($input->pageNum - 1) . "' />"; } } Within the body comes the loop and the paginator: <?php foreach($children as $child): ?> ... <?php endforeach; ?> <?=$children->renderPager(); ?>

Google wants special code in the header to identify pages with a paginator correctly: <link rel="prev" href="http://www.example.com/article?page=1" /> <link rel="next" href="http://www.example.com/article?page=3" /> Is there a way to do that with the paginator module already - or with some small tweaks? All the needed information should be there already (like "is there a next/prev page" and "what are the links") and there might be just some additional rendering for the header part of the webpage necessary. Source/read more: http://googlewebmastercentral.blogspot.de/2011/09/pagination-with-relnext-and-relprev.html