ceberlin

it's perfekt now. Thank you very much!

Hi Teppo, the 1.3.8 update, which fixes the admin/users access, does not show in the PW update system yet.

> #3: To have the first element already visible with repeaters, you can adjust the "Ready-To-Edit New Repeater Items" setting. I have set this to 3 (which is the default). From my understanding this only means that you can add that certain amounts of repeating elements without having to save the page in between. It does not mean (at least not in my PW 2.4.1 dev version) that 1 element is already set, visible and ready for input. And that is what I would like to have. If I set one of the repeater's fields to "required" the PW behavior is unexpected (bug?). There comes an error about a missing field content. But that field was not set with the +ADD ITEM at that time. Thank you very much for the code. I would like to avoid applying changes to the wire folder or any modules directly - I do not want to break it when there are updates. It the idea does not find general support, I could consider overriding certain css with some plugin or so.

3 more ideas (I hope I am not repeating something this time): 1. For the titles of collapsed fields add an ellipsis… (for example with CSS for the collapsed field's title something like: ::after {content: "…";} ) Why? My clients have difficulties to identify collapsed fields as expandable with more content available inside. 2. If repeater or group is collapsed, infos about required missing content are hidden. I would suggest that in this case those blocks are auto-expanded to show the spots to fix. 3. Repeaters - 1st element already visible Option in repeater settings to aways show the first element for new pages without requiring the click on "+add" helps clients to identify, what this area is for.

Now I get it. I was searching for the wrong keywords maybe. Sorry for posting something that has been posted here already.

This behavior seems to make the * (for required) disappearing also!

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.