ceberlin

Finding that out of the sudden a "guest" batch-changed 700 file settings scared the hell out of me, I must say. It scared me even more that I cannot see a pattern, why some files were changed and others not. Glad to hear that "guest" was probably not a person and no hack, but only a script gone wild. I really would find very useful if it was recorded somehow, what script was involved. But that is maybe to much to ask.

Today we had an incident were lots of pages got unpublished. There were no normal editor activities around that time and there was no clearly seeable pattern. The logs never should say "guest" if the api does something, better would be "system" or "API" and even better, which script. Because of "guest" I immediately thought of a hacking attempt to the batcher, for example. But we found no sign of hacking. 700 "unpublishing"-changes in little time - this was a script and no person, for sure. We investigate at the moment.

Hi, there were registered changes here today from a user "guest"... how can that be?

Yes that worked. The error is gone. Thank you.

Hi, I have a funny problem with redirects. I want to redirect from /en/index.php (which was a valid link on the website before the update to PW) to /en/ Works perfectly. But if I open the redirect settings for editing, the"from" link is empty and I get a warning "enter valid url".

This works so far, I guess I was mixing here page arrays and single pages and find() returns an array. $page->rootParent->child("page_key=check-status")->url (I wished there were more examples in the tutorials)

Old modules from the past, I see. We have some problem here with the find() and I wanted to be sure to rule out some possibilities.

I find unusal that the PW created database turns out to be a mix of MyISAM and InnoDB tables, Most collations are utf8_general_ci, but I fould also ascii_general_ci and _latin1_swedish_ci. Maybe this is coming from modules... I am not a database pro, I am designer, but to me this looks like potential trouble with searches, sortings and so on.

Thank you very much for this in-depth explanation. This hepls a lot. Maybe I have a problem with the database but this is strange: Setup: /de/file with checkbox menu (autojoin) /en/file with checkbox menu (autojoin) /es/file with checkbox menu (autojoin) This is funny, has_parent only works in 1 language, although I am sure, the settings are identical (cloned): $pages->find('has_parent=/de/, menu=1, include=all) - OK $pages->find('has_parent=/en/, menu=1, include=all) - no result $pages->find('has_parent=/es/, menu=1, include=all) - no result The rootParent way (good to know about the rootParent, I thought this was for something else): $page->rootParent->find('menu_btn_to_footer2=1' - OK only for /de/ - same as above. This works (but it is not what I want, because /de/ could be parent or also grand parent. $pages->find('parent=/de/, menu=1, include=all) - OK $pages->find('parent=/en/, menu=1, include=all) - OK $pages->find('parent=/es/, menu=1, include=all) - OK Can this be stopwords, or is the search string to short for a reliable result? Or can this be a problem with the database? Everything was cloned from the /de/ tree.

>What is the silver admin bar? Is this the AdminBar module or something different? Yes, this is the AdminBar module, I believe. It feels so natural to use it, I thought this is part of PW

check_access, include ...shouldn't they go into the offiicial documentation? - I think they are pretty important!

Same situation here: I have built a structure with language trees. home/de/page1/page2 home/en/page1/page3 I am almost always selecting from the, what I call - local_index page, like /de/ to find pages in the same language tree. $local_lang_url = "/de/"; // (example) //search 1 (works, 2 searches): $blocks = $pages->get($local_lang_url)->find('page_key=block_m-help-legal'); //search 2 (does not work): $blocks = $pages->get($local_lang_url)->children('page_key=block_m-help-legal'); //search 3 (does not work) $blocks = $pages->get("has_parent=" . $local_lang_url . " , page_key=block_m-help-legal"); //search 4 (works best): $blocks = $pages->find("has_parent=" . $local_lang_url . ", page_key=block_m-help-legal"); For my curiosity, I wonder what is wrong with search 2 and 3: What is the problem with children() and get() in this context? And how it is with the speed if I do a get(), narrowing the search with a find() - instead of using find() with an AND selector? And my last question is, whether there is a better way to declare the local_index file as homepage and root for searches? At the moment I stick with search 4, although I thought, find() is slow.

I tried the latest dev and had trouble (which I had not before) with certain serarches: 1. the admin search: clicking on the number-link at the headline of a template editing page (showing the pages that use that template) gave empty results; 2. Switching to Edit this page (from the silver admin bar) gave an empty search page instead of the page with the edit overlay.

Since this is a calculated comparison, I would love a feature where uniqueness starts after the language tree. So that i can have unique fields within a language but I can still copy the whole language tree and copy the "unique" fields over. /de/file-with-uniquefield#1 /en/file-with-uniquefield#1

Only problem with foundation: It is not tolerant at all to older browsers. From our stats still more than 20% of the users come from IE 8 and older. That is a real pain.

If you get a compile error (Error 500) when updating a module (for example with the ModuesManager), this could be for a likely but not so obvious reason. I want to share this. Example alert (Maintenance Module update example): Compile Error: Cannot redeclare class MaintenanceMode (line 3 of /.../site/modules/MaintenanceMode/MaintenanceMode.module) This looks like an attempt to declare the same module class twice. What had happened here was this: When dragging a module over an ftp client to the modules folder, it got placed inadvertedly into another module folder and not in the modules root. - So the module became "invisible" (hidden) on your ftp client at first glance. The funny thing was that the misplaced module was still working alright. No alarm bells rang. Trouble came after we tried to update the module (by ftp or by the modules manager) months later. Then the infamous error 500 appeared. So, before wasting time looking closely at database entries and module codes, maybe check first whether there is a duplicate of the updated module buried in the modules folder somewhere.

Anyone checked the new version TinyMCE 4 already? It's currently in late beta. The new version looks soooo cool and clean! I cannot wait to see this in PW!

Thank you VERY much, Pete!

I like the drupal codings standards a lot. Very clear and comprehensive: https://drupal.org/coding-standards

Yes I used the dev-version for some reason but I did not expect that to be the cause of the issue. Thank you very much for the quick fix, Ryan!

What I did: Right now an editor (who is not a superuser) only sees PAGES and ACCESS. I thought I move a page into admin which has all rights set for any editor. This NOTIFICATION page should be accessible in the black admin menu. The purpose is to give the editors some statistics and notes. What happened: Obviously this is an unintended setup. When calling the file as non-superadmin, i get an error 500. Error: Call to a member function has() on a non-object (line 50 of /xxxxxxxx/wire/core/Role.php) I there anything I can do to fix this?

I like the module a lot. Thank you for this! One idea: I would find a 2 step maintenance extremely useful: a) EMERGENCY - Leave only the Superadmin in (as it is now) - good for updates and for working on the database. b) NORMAL MAINTENANCE - apply a new Permission "bypass_maintenance" to a role which is given access to the backend next to the Superadmin. - good for developing.

Solved - In the settings I had set the limit up to "300", Redirects "5". Refreshed. Then it stopped working after having read in exactly 10 modules. Resetting the limit down to "200" (and refreshed) brought the module back to life again.

Yes please! Uninstalling the module would mean: have the current abstraction replaced with the last known real link. Done by the module uninstaller, if possible. In a second step an admin could run a classic link checker online to identify broken links and fix them manually. - Is this thinking correct?

Hi, I like this very much! My only concern: The numbers in the flie lists are on the right and to o far away from the files. What is hard already (identifying files with children) will be much harder this way. (I would really appreciate a different icon actually, if there are children. None of the templates I tried has that.)