New ProcessWire admin theme on dev branch

[horst]

@Ryan, ProcessWire 2.3.14 on Win7 with FF26 & IE10 are the same:

No Core-Tab, but found "Autocomplete" in the Source:

No JS-Messages in the Console.

EDIT: oh, sorry, - it wasn't InputfieldAutocomplete, it was PageAutoComplete

InputfieldAutocomplete not found in source

Edited January 30, 2014 by horst

[kongondo]

I'm lost as to what could be the issue with the missing Core tab. How do you guys install core modules if there is no Core tab? Do those modules appear on the Site tab? If not, try viewing the source and search for "Autocomplete". See if the InputfieldAutocomplete (a core module) is showing up anywhere in the source? This should help us to determine if this is a PHP problem or a front/end CSS/JS problem.

Yes, they are listed under Site tab (PW 2.3.15, W7, Chrome, FF, IE).

This drove me nuts yesterday debugging! tried in xampp 1.77, 1.8x, Uwamp - no dice! But it works in two different remote servers! The mystery InputfieldWrapper4 just doesn't show up!

A search for "autocomplete" reveals the same 4 hits in both cases, i.e. where the "Core" Tab does not show up in some installs and where it does. See code below

<span role="status" aria-live="polite" class="ui-helper-hidden-accessible"></span><input type="text" id="ProcessPageSearchQuery" name="q" value="" class="ui-autocomplete-input" autocomplete="off">

<td><a href="edit?name=InputfieldPageAutocomplete">Page Auto Complete</a></td>

<ul class="ui-autocomplete ui-front ui-menu ui-widget ui-widget-content ui-corner-all" id="ui-id-1" tabindex="0" style="display: none;"></ul></body></html>

Edit:

@Ryan....RE your quote above, this is a typo "InputfieldAutocomplete", no? Should be InputfieldPageAutocomplete

Edited January 30, 2014 by kongondo

[Soma]

BTW, I'm using Fredi a lot lately, and noticed that the WireTabs don't work there anymore when doing a renderAll(), which renders complete page edit form.

I'm not sure which part is responsible for, but lately I find quite a lot of those glitches and wierd behaviors of PW, and find myself debugging and trying searching rather than developing.

Latest was I updated a install 2.3 to latest 2.3.13 and the editors couldn't edit content anymore cause the "edit" action was gone. After not finding abvious reason, I saved something with the roles or something and it was working again. 

[ryan]

Kongondo and/or Sinnut: could you guys try this script. Put it in your site root and then load in your browser:

/test.php

<pre><?php
include("./index.php"); // bootstrap PW
wire('config')->debug = true; 
foreach(wire('modules') as $name => $module) {
  try {
    $reflector = new ReflectionClass($name);
    echo "\n$name => " . $reflector->getFileName();
  } catch(Exception $e) {
    echo $e->getMessage();
  }
}

it should output a list of all modules and the files they come from. But I'm guessing you guys will instead see an error message. What does the error say?

[adrian]

Small issue with the debug tools in the API variables section. Everything under the name column is white (not visible) due to:

#footer a {
    color: white;
}

[ryan]

BTW, I'm using Fredi a lot lately, and noticed that the WireTabs don't work there anymore when doing a renderAll(), which renders complete page edit form.

You reported WireTabs not working in modal=1 mode on GitHub, but I've not been able to reproduce that. There was an issue a couple weeks ago with modal=1 mode, but that was fixed. It's possible the version you upgraded to (2.3.13) didn't that that fix. We are now at 2.3.15. 

find myself debugging and trying searching rather than developing.

Debugging is developing

Latest was I updated a install 2.3 to latest 2.3.13 and the editors couldn't edit content anymore cause the "edit" action was gone. After not finding abvious reason, I saved something with the roles or something and it was working again.

I'm not aware of any changes that would affect access control, though we do have bug fixes in place. Most likely your site was affected by a bug involving the rewriting of the pages_access table, and when you saved something with the roles, it dumped and re-created the table, cleaning out the old buggy data.

[adrian]

Another quick comment. On one install that I have been updating, I ended up with two admin modules:

"New Admin Theme" in the site modules section, as well as "Default Admin Theme" in the core section.

I am sure this won't be an issue for new installs, but might be worth investigating for upgrades, although quite likely it won't happen anymore - I am guessing it was some specific recent version that installed the site "New Admin Theme" and this probably won't happen again, but thought I should report it just in case.

[kongondo]

Kongondo and/or Sinnut: could you guys try this script. Put it in your site root and then load in your browser:

/test.php

<pre><?php
include("./index.php"); // bootstrap PW
wire('config')->debug = true; 
foreach(wire('modules') as $name => $module) {
  try {
    $reflector = new ReflectionClass($name);
    echo "\n$name => " . $reflector->getFileName();
  } catch(Exception $e) {
    echo $e->getMessage();
  }
}

it should output a list of all modules and the files they come from. But I'm guessing you guys will instead see an error message. What does the error say?

No errors - it works as intended; outputs a list of all modules and the files they come from....

[Soma]

No Ryan, I reported that they were not visible in modals where modal=1 is used cause they're were cut off, but it seems it's gone in latest admin theme version, but not sure why or how.

Yeah I also preach that, but I meant getting along with the project/site I'm trying to develop.

Well, it was wierd with the role thing, and costed my editors time and frustration, in that they couldn't edit when they actually wanted

Just debugged half hour why Fredi modal (renderAll()) wouldn't now show WireTabs. Turned out you changed the ProcessPageEdit to init the script from an inline script:

https://github.com/ryancramerdesign/ProcessWire/blob/dev/wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module#L135

So simple changes like this can be nasty, and break other modules that depend on it

[ryan]

No errors - it works as intended; outputs a list of all modules and the files they come from....

Thanks for testing it out. Can you give me an example of one of those paths it outputs? 

Turned out you changed the ProcessPageEdit to init the script from an inline script:

I was worried that might have implications, so tested it pretty thoroughly before committing just to be safe. Just out of curiosity, why does that break Fredi? The benefit of moving that to be inline is that the tabs appear faster and with less jump. It only makes a difference on big/complex edit forms (I'm working with a couple here that have 1,000+ inputs). 

[kongondo]

Thanks for testing it out. Can you give me an example of one of those paths it outputs?

Attached, the whole list (local install, no worries...)

fields.txt

[Soma]

I was worried that might have implications, so tested it pretty thoroughly before committing just to be safe. Just out of curiosity, why does that break Fredi? The benefit of moving that to be inline is that the tabs appear faster and with less jump. It only makes a difference on big/complex edit forms (I'm working with a couple here that have 1,000+ inputs). 

... because Fredi renders/construct outputs the form itself, using ProcessPageEdit to buildForm, just the part you changed is not involved.

[adrian]

I feel like I am interrupting a more important dialogue here, but another weird thing. I have some installs that look perfect, but at least one is not showing the debug accordion properly at all. The div is just:

<div id="debug">

instead of:

<div id="debug" class="ui-accordion ui-widget ui-helper-reset" role="tablist" style="display: block; overflow: hidden;">

which means everything loads completely open with no accordion styling at all. The broken one is a local install, but I also have a local one that is working fine.

[ryan]

Attached, the whole list (local install, no worries...)

Thanks, that helped me to fix it (I think!). If you try out the latest dev, you should now see a Core tab (file updated was this one). Please let me know if that doesn't resolve it. 

which means everything loads completely open with no accordion styling at all. The broken one is a local install, but I also have a local one that is working fine.

The attributes you mentioned are added by jQuery UI via Javascript. Check if there is a JS error occurring?

"New Admin Theme" in the site modules section, as well as "Default Admin Theme" in the core section.

I don't know what "New Admin Theme" is, but check your /site/modules/ directory to see if you've got an admin theme in there and remove it if you do. Also if you've got a /site/templates-admin/, go ahead and remove or rename that too. Double check that your /wire/ directory was fully removed and replaced (rather than replaced into) during the last update. 

[kongondo]

Thanks, that helped me to fix it (I think!). If you try out the latest dev, you should now see a Core tab (file updated was this one). Please let me know if that doesn't resolve it. 

................. 

Nice! Thanks.

Aaah, a Windows issue....

Let me test..

Edit:

Bazinga! Fixed! Am the proud owner of a brand new Core tab!

Edited January 30, 2014 by kongondo

[adrian]

The attributes you mentioned are added by jQuery UI via Javascript. Check if there is a JS error occurring?

Unfortunately there are no JS errors - not sure what the issue is here!

I don't know what "New Admin Theme" is, but check your /site/modules/ directory to see if you've got an admin theme in there and remove it if you do. Also if you've got a /site/templates-admin/, go ahead and remove or rename that too. Double check that your /wire/ directory was fully removed and replaced (rather than replaced into) during the last update.

I don't think I have seen "New Admin Theme" anywhere else either, but it had exactly the same config settings as Default Admin Theme" except that is was in the site modules. I did already get rid of it by uninstalling and deleting the folder from site/modules. Interestingly it couldn't be deleted using the new functionality via modules - the delete button wasn't there.

The site/templates-admin was gone already and I believe wire was properly fully replaced.

Anyway, I don't think this is likely to occur again with any luck.

[Manfred62]

yesssss sir, now I have the core!

[horst]

have core tab too

------

Have found a very minor issue with responsiveness of the theme regarding the PW-logo:

• inner width = 768 - 1 row for Topmenu & Logo is visible
• inner width = 767 - 1 row for Topmenu & but Logo is hidden
• inner width = 485 - 2 rows for Topmenu & but Logo is hidden
• inner width = 479 - 2 rows for Topmenu & and Logo is visible again!

Is this intended behave or should the Logo be constantly visible?

[Manfred62]

because translations in newest dev. Using 2.3.15 with german as default language (only one language). See the screenshots.

overview from Admin - Setup - Fields. In the breadcrumb only Fields (Felder) is translated. The rest is not.

Admin - Setup. The titles are translated.

Admin - Setup - Languages.

in the breadcrumb the 'Fields' is the only one field which translated phrase show up correctly. All others not. Also the small nav in the footer is not translated.

[ryan]

Unfortunately there are no JS errors - not sure what the issue is here!

The debug info is meant to be shared among admin themes (optional), so the new admin theme uses the one from /wire/templates-admin/debug.inc. Have a look in that file. At the bottom should be a Javascript section with a $('#debug').accordion(...). It sounds like that JS is not getting executed or, maybe there's another element on the page with the #debug id? We should probably use a different ID attribute for this debug div, as #debug is a potentially very common thing that is maybe best left for 3rd party use. If you view the source on your page and search for "debug" does it come up anywhere other than for the <div id='debug'> at the bottom?

Interestingly it couldn't be deleted using the new functionality via modules - the delete button wasn't there.

That just means that the files for that module aren't writable to ProcessWire. 

Is this intended behave or should the Logo be constantly visible?

The logo is intended to disappear at mobile sizes. But if the combination of topnav items + search boxes forces them to be split on two rows, then it'll show the logo again, since there is room for it. If the combination forces it to go onto 3 lines, then it again hides the logo and moves all the navigation to that hamburger icon. So the behaviors kind of depend on how many top navigation items you have in your admin. 

because translations in newest dev. Using 2.3.15 with german as default language (only one language). See the screenshots

Thanks, I'll go through and test these out and add any missing __('functions'); 

[adrian]

Ok, there is only one id of debug on the page. If I run that jquery from debug.inc in the console, it applies all that styling as it should.

Turns out the page source was ending like this:

    <script type="text/javascript">
        $(document).ready(function() {
            $("#debug").accordion({ 
                header: 'h3',
                heightStyle: 'content'
            }).hide();
            $("#debug_toggle").click(function() {
                $("#debug").slideD
 

and generated source as:

<script type="text/javascript">
        $(document).ready(function() {
            $("#debug").accordion({ 
                header: 'h3',
                heightStyle: 'content'
            }).hide();
            $("#debug_toggle").click(function() {
                $("#debug").slideD</script></div></div><ul style="display: none;" tabindex="0" id="ui-id-1" class="ui-autocomplete ui-front ui-menu ui-widget ui-widget-content ui-corner-all"></ul></body>
 

Weird!

[ryan]

Turns out the page source was ending like this:

Looks like you've got an incomplete/corrupted debug.inc file? I would download a fresh /wire/ and replace it entirely if you can, just in case there are any other truncated files in the core. 

[adrian]

That's the weird thing though - the end of the debug.inc file looks perfect:

    <script type="text/javascript">
        $(document).ready(function() {
            $("#debug").accordion({ 
                header: 'h3',
                heightStyle: 'content'
            }).hide();
            $("#debug_toggle").click(function() {
                $("#debug").slideDown();
                $(this).hide();
                var n = $(document).height();
                $('html, body').animate({ scrollTop: n },'50');
                return false;
            }); 
        }); 
    </script>
 

Oh and I have already grabbed the very latest dev from today and deleted the old wire completely first. I'll keep investigating.

[adrian]

Speaking of the debug section, would you be opposed to this change so that it can be toggled closed again?

        $(document).ready(function() {
            $("#debug").accordion({
                header: 'h3',
                heightStyle: 'content'
            }).hide();
            $("#debug_toggle").click(function() {
                if ($('#debug').is(":hidden"))
                    $("#debug").slideDown();
                else
                    $("#debug").slideUp();
                var n = $(document).height();
                $('html, body').animate({ scrollTop: n },'50');
                return false;
            });
        });
 

[adrian]

What a waste of time, but I have managed to narrow down the debug accordion/source truncation issue to the ProcessPageDelete module and this code:

    public function addJavascript(HookEvent $event) {
        $js = '
        <script type="text/javascript">
        $(document).ready(function() {
            $("li.PageListActiondelete a").live("click", function(el){
                if(!confirm("Are you sure?")) { return false; }
            });
        });
        </script>';
        $event->return = str_ireplace("</head>", $js.'</head>', $event->return);
    } 

I am still not completely sure why it is breaking things and especially why only on one installation, but what I did was move that JS code into it's own file and call parent::init(); to have the module automatically load the ProcessPageDelete.js file. I'll submit a pull request to Nico.