Jump to content

Recommended Posts

Yep, I had that bug for a few moment, but I fixed it yesterday.

There is also changes that fixes that original bug, so I suggest that you do following:

  • Uninstall the module
  • Remove (not required) the unnecessary adminbar pages from your admin
  • Replace your module with latest files
  • Install

Share this post


Link to post
Share on other sites

AdminBar is really great! I will be installing it on all of my clients' sites (already started actually).  ;D

Share this post


Link to post
Share on other sites

Thanks Ryan, nice to hear that it is already in good use!

I pushed little fix to issue that Adam reported. AdminBar uses jQuery so it won't work nicely if there isn't jquery on templates (and many times there won't be). There is now option in module settings whether to load jQuery or not.

Share this post


Link to post
Share on other sites

Tiny update again: tooltips, two new icons & smaller hide button, fixed modal position.

Works fine on: IE9, Chrome & Firefox. Haven't had possibility to test IE8 yet.

EDIT: You can see tooltips in action here: http://www.screencast.com/users/apeisa/folders/Jing/media/9a10b4bb-d49c-4097-939c-824e9c729afc (I recorded this to show one bug that Ryan already fixed).

Share this post


Link to post
Share on other sites

Hey folks,

I have admin bar working happily but I think there is a CSS fault with the tooltips which I noticed in Chrome. See screenshot here:

http://grab.by/9eJq

Changing line 80 of AdminBar.css to the following fixes this.

left: 120px; 

IE9, Opera 10, Safari and Firefox 3 all work fine with this update.

Cheers

R

Share this post


Link to post
Share on other sites

Ragnar: Welcome to the forums and thank you for letting me know and providing fix also. I'll update AdminBar soon.

There is also few other issues currently:

  • Another css problem when you don't have margin: 0; padding: 0 on your lists
  • Changing template won't work (same issue in other settings also, if they require confirmation step after saving)

On the good news, AdminBar works nice on IE8 (well, modal background is not showing, but that should be an easy fix).

Share this post


Link to post
Share on other sites

No problem Apeisa, and if you need any further CSS bug checking etc let me know as that is what I consider my strength!

Share this post


Link to post
Share on other sites

would add something like "autohide" (is a narrow strip on the left screen, and when it hover over it appears completely)  :)

Share this post


Link to post
Share on other sites

Hi,

Thank you for AdminBar, it's great!  :)

Now, changing the "title" field's name to anything else threw the error:

Exception: Field does not exist: title (in E:\(...)\wire\core\PageFinder.php line 195)

#0 E:\(...)\wire\core\PageFinder.php(99): PageFinder->getQuery(Object(Selectors))

#1 E:\(...)\wire\core\Pages.php(125): PageFinder->find(Object(Selectors), Array)

#2 [internal function]: Pages->___find('title=adminbar', Array)

#3 E:\(...)\wire\core\Wire.php(241): call_user_func_array(Array, Array)

#4 E:\(...)\wire\core\Wire.php(203): Wire->runHooks('find', Array)

#5 [internal function]: Wire->__call('find', Array)

#6 E:\(...)\wire\core\Pages.php(197): Pages->find('title=adminbar', Array)

#7 [internal function]: Pages->___findOne('title=adminbar')

#8 E:\(...)\wire\core\Wire.php(241): call_user_func_array(Array, Array)

#9 E:\(...)\wire\core\Wire.php(203): Wire->runHooks('findOne', Array)

#10 [internal function]: Wire->__call('findOne',

This error message was shown because you are logged in as a Superuser.

Obviously there's no real advantage in changing that name (I can understand where this issue comes from) but I thought I'd point this out.

Share this post


Link to post
Share on other sites

Ragnar: started to edit css today, but noticed that the bug you reporter is not in tooltip css, it is because AdminBar didn't clear margins on lists. So if your site css didn't have something like ul, li {margin: 0} there would be that issue. It is fixed now on latest version. It is now working on Opera 11, so if you can test latest version of AdminBar in Opera 10 and your site I would be thankful.

Qwertyee: Good idea. I have been thinking about something similar, just not sure yet what would be best way to implement this. Something like this will definitely come in the future.

Antonio: thanks for this! I actually didn't realize that title field can be changed. I am pretty sure that I'll find an easy way to fix this.

Share this post


Link to post
Share on other sites

Now, changing the "title" field's name to anything else threw the error:

Obviously there's no real advantage in changing that name (I can understand where this issue comes from) but I thought I'd point this out.

This is now fixed, thanks again for reporting this Antonio.

https://github.com/apeisa/AdminBar/commit/d4f79e2afecd509f336bef11c480588fa8b0aee6

Share this post


Link to post
Share on other sites

The title field will likely get locked down (required field name) in the near future, just because I think it'll make life a little more difficult for module developers if we don't... for example, without a known title field, there would be no way to identify what the actual title of a page is, just the URL name. As a result, I don't recommend changing the name of the title field.

Share this post


Link to post
Share on other sites

The title field will likely get locked down (required field name) in the near future, just because I think it'll make life a little more difficult for module developers if we don't... for example, without a known title field, there would be no way to identify what the actual title of a page is, just the URL name. As a result, I don't recommend changing the name of the title field.

Yes, I though something like this.

Share this post


Link to post
Share on other sites

Ragnar: started to edit css today, but noticed that the bug you reporter is not in tooltip css, it is because AdminBar didn't clear margins on lists. So if your site css didn't have something like ul, li {margin: 0} there would be that issue. It is fixed now on latest version. It is now working on Opera 11, so if you can test latest version of AdminBar in Opera 10 and your site I would be thankful.

Indeed, I have literally just noticed that this very minute. I believe it was due to the blueprint css framework which I am using on the site.

Unfortunately I've just upgraded to Opera 11 so can't check v10 for you. IE9, FF3, Safari and Chrome all look good as well.

Share this post


Link to post
Share on other sites

First of all, Adminbar is AWESOME, very nice implementation of front-end editing!

Found an issue in IE8

Clicking on the "dark side" doesn't close the modal. Maybe it would be good to add a 'close' button in top right, so the modal close can be forced if needed?

Once again, nice work guys

Sylvio

Share this post


Link to post
Share on other sites

Scarota: thanks for the nice feedback and bug report. And welcome to the forums!

I got the exact same request from people at our company, so nice little close-button will be next thing coming.

Share this post


Link to post
Share on other sites

Found an issue in IE8

Clicking on the "dark side" doesn't close the modal. Maybe it would be good to add a 'close' button in top right, so the modal close can be forced if needed?

Just pushed latest version to Github. There is now close-button on top of the modal, which should work on IE8 also. I want of course to fix that original IE8 problem and will get into that when I get to work (no IE8 at home). Does it show modal at all in IE8? Probably some css problem there...

I actually positioned the close button to top left. i think it is prettier and closer there, but please let me know if that is unnatural for you guys...

Share this post


Link to post
Share on other sites

Super, thanks for the quick fix!

The positioning of the close button works for me!

I agree on fixing the original IE8 problem :)

I am using IE 8.0.6001.18702, I didn't really test other IE8 releases, I also use IE out of necessity @work ;)

Share this post


Link to post
Share on other sites

Does anyone have this problem with a sitemap?

k2pg9s91tt87t0ekrbg71z095sshd5zct5vkh4jm.png

I solved it only in this way -

file: /public_html/site/modules/AdminBar/AdminBar.module

220:  <li><a href='{$this->config->urls->admin}adminbar/ab-sitemap/?curPageId={$this->page->id}{$modalGet}' class='{$modalClass} pages'>View sitemap</a></li>

delete: ab-sitemap/

220: <li><a href='{$this->config->urls->admin}adminbar/?curPageId={$this->page->id}{$modalGet}' class='{$modalClass} pages'>View sitemap</a></li>

So now it works fine

26duwkvx9nsor8jyaep0eefrwl2dtk1xwr9gwni9.png

Share this post


Link to post
Share on other sites

Zlojkashtan: welcome to the forums. Strange error and I couldn't produce it here. Do you have page Admin -> adminbar -> ab-sitemap ? If not it should work if you create that page and give it template "adminbar".

I should also make uninstall method so that Adminbar cleans everything if you uninstall it (it would be easier to re-install if something goes wrong).

Share this post


Link to post
Share on other sites

Nice advice.

After global cleaning and re-installation everything work correct!!

Thanks a lot.

Share this post


Link to post
Share on other sites

I took a look if AdminBar works with upcoming 2.1 release. It does, almost. Only thing that is not working is sitemap, and that is probably because of the changes in access management.

It is strange since when you browse admin/adminbar/ and /admin/adminbar/ab-sitemap/ pages through normal admin, there is no "view" link on them. The error I got when trying to view sitemap is:

Not Found

The requested URL /ot/processwire/&modal=1 was not found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

But if I change so that adminbar-template manages access and shows 404 error when user has no access, then it actually shows 404 page in modal. I think this is probably something like "trying to use non-Process page inside Admin"? Admin-template seems to be special one, since there is less options on access tab than other templates have.

Any clues Ryan where to go with this? Not in hurry with this one, no need to get this working before we have stable 2.1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By bernhard
      --- Please use RockFinder3 ---
    • By MoritzLost
      Cacheable Placeholders
      This module allows you to have pieces of dynamic content inside cached output. This aims to solve the common problem of having a mostly cacheable site, but with pieces of dynamic output here and there.  Consider this simple example, where you want to output a custom greeting to the current user:
      <h1>Good morning, <?= ucfirst($user->name) ?></h1> This snippet means you can't use the template cache (at least for logged-in users), because each user has a different name. Even if 99% of your output is static, you can only cache the pieces that you know won't include this personal greeting. A more common example would be CSRF tokens for HTML forms - those need to be unique by definition, so you can't cache the form wholesale.
      This module solves this problem by introducing cacheable placeholders - small placeholder tokens that get replaced during every request. The replacement is done inside a Page::render hook so it runs during every request, even if the response is served from the template cache. So you can use something like this:
      <h1>Good morning, {{{greeting}}}</h1> Replacement tokens are defined with a callback function that produces the appropriate output and added to the module through a simple hook:
      // site/ready.php wire()->addHookAfter('CachePlaceholders::getTokens', function (HookEvent $e) { $tokens = $e->return; $tokens['greeting'] = [ 'callback' => function (array $tokenData) { return ucfirst(wire('user')->name); } ]; $e->return = $tokens; }); Tokens can also include parameters that are parsed and passed to the callback function. There are more fully annotated examples and step-by-step instructions in the README on Github!
      Features
      A simple and fast token parser that calls the appropriate callback and runs automatically. Tokens may include multiple named or positional parameters, as well as multi-value parameters. A manual mode that allows you to replace tokens in custom pieces of cached content (useful if you're using the $cache API). Some built-in tokens for common use-cases: CSRF-Tokens, replacing values from superglobals and producing random hexadecimal strings. The token format is completely customizable, all delimiters can be changed to avoid collisions with existing tag parsers or template languages. Links
      Github Repository & documentation Module directory (pending approval) If you are interested in learning more, the README is very extensive, with more usage examples, code samples and usage instructions!
    • By Craig
      I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it.
      WayFathomAnalytics
      WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages.
      Links
      GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics?
      Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses.

      Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business.
      Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more
    • By daniels
      This is a lightweight alternative to other newsletter & newsletter-subscription modules.
      You can find the Module in the Modules directory and on Github
      It can subscribe, update, unsubscribe & delete a user in a list in Mailchimp with MailChimp API 3.0. It does not provide any forms or validation, so you can feel free to use your own. To protect your users, it does not save any user data in logs or sends them to an admin.
      This module fits your needs if you...
      ...use Mailchimp as your newsletter / email-automation tool ...want to let users subscribe to your newsletter on your website ...want to use your own form, validation and messages (with or without the wire forms) ...don't want any personal user data saved in any way in your ProcessWire environment (cf. EU data regulation terms) ...like to subscribe, update, unsubscribe or delete users to/from different lists ...like the Mailchimp UI for creating / sending / reviewing email campaigns *I have only tested it with PHP 7.x so far, so use on owners risk
      EDIT:
      Since 0.0.4, instructions and changelog can be found in the README only. You can find it here  🙂
      If you have questions or like to contribute, just post a reply or create an issue or pr on github, thanks!
    • By MoritzLost
      Sorry for the convoluted title. I have a problem with Process modules that define a custom page using the page key through getModuleInfo (as demonstrated in this excellent tutorial by @bernhard). Those pages are created automatically when the module is installed. The problem is that the title of the page only gets set in the current language. That's not a problem if the current language (language of the superuser who is installing the module) is the default language; if it isn't, the Process page is missing a title in the default language. This has the very awkward effect that a user using the backend in the default language (or any other language) will see an empty entry in the setup menu:

      This screenshot comes from my Cache Control module which includes a Process page. Now I realize the description sounds obscure, but for us it's a common setup: We a multiple bilingual sites where the default language is German and the second language is English. While the clients use the CMS in German, as a developer I prefer the English interface, so whenever I install a Process module I get this problem.
      As a module author, is there a way to handle this situation? I guess it would be possible to use post-installation hooks or create the pages manually, but I very much prefer the declarative approach. The page title is already translatable (through the __ function), but of course at the time of installation there is no translation, and as far as I'm aware it's not possible to ship translations with a module so they are used automatically. Could this situation be handled better in the core? I would prefer if the module installation process would always set the title of the Process page in the default language, instead of the language of the current user.
×
×
  • Create New...