Releases feedback

Re: Testing 2.0a2

Thanks for the reply :)

Topic


Re: Testing 2.0a2

  • 2013/5/20 5:41:50
  • Will

Quote:

Wouldn't it be nice to make the whole theme (front and back end) responsive and with fluid layouts?



It is responsive.

As far as fluid - that is a matter of taste - and as I am the sole contributor to the new UI at this point the UI pretty much reflects my taste. Thus, not fluid. I could see the benefit to a wordpress-like admin panel, which is what I assume you have in mind - and I have given you the tools to accomplish it quite easily.

So pull up a branch, and share your vision. You can accomplish this part with a simple skin

Topic


Re: Testing 2.0a2

Thanks for the input, @Eyekeeper

Quote:


Eyekeeper wrote:
I was testing a little on the interface.
I'd like to ask two things...

Wouldn't it be nice to make the whole theme (front and back end) responsive and with fluid layouts?



Since Bootstrap.js is at the heart of the UI refactoring, I think this is already being implemented. Look into themes/core/theme.html and themes/core/theme_settings.html for hints

Quote:


Further I think the control panel blocks and module icons wouldn't actually need to be in a block using icons but all the functions could be inserted into a left column in an accordion menu to save space and to create a more modern approach to the admin...

For the remaining space we could have a dashboard with recent interactions or some useful stats as site access, pendind actions, quick posts or something similar...

Just my 2 cents



Way back when ... Incama shared some ideas for this

More than just ideas - a few more people rolling up their sleeves, creating branches in git for the UI, and adding their ideas will move this along.



Re: Testing 2.0a2

I was testing a little on the interface.
I'd like to ask two things...

Wouldn't it be nice to make the whole theme (front and back end) responsive and with fluid layouts?

Further I think the control panel blocks and module icons wouldn't actually need to be in a block using icons but all the functions could be inserted into a left column in an accordion menu to save space and to create a more modern approach to the admin...

For the remaining space we could have a dashboard with recent interactions or some useful stats as site access, pendind actions, quick posts or something similar...

Just my 2 cents



Re: Testing 2.0a2

Hi Simon,
created tickets 713,714,715.



Re: Testing 2.0a2

  • 2013/5/16 12:47:39
  • Will

Quote:

* Admin panel - the top menu text is a bit too small for an old man like me to read.



All Css :)

/libraries/jscore/app/modules/adminMenu/adminMenu.css

Line 10

Maybe 11px?



Re: Testing 2.0a2

Just started digging through it, looks great. A few suggestions:

* Found a problem in /libraries/icms/core/DataFilter.php that was inserting additional line breaks into legacy content (ticket 712).

* Admin panel - the top menu text is a bit too small for an old man like me to read.

* Module admin, would be good if the module logos were clickable in addition to the titles.

* Module info pop up, the 'close' link doesn't work and is also redundant as there is a close button.

* Module admin menus - I get a bullet list now, no tabs, not sure if this is intended or not.

Had a quick look at compatibility with Gone Native modules, they will need some adjustment to work but I don't think it will be a big deal. Some approaches I had relied on quite a bit like getting the object handler name using basename(dirname(__FILE__ etc don't seem to work anymore, as it is returning the system module even when it looks like I am in some other module directory.

More to come.



Re: Testing 2.0a2

Found the issue with IPF table in Firefox as mentioned above.

In the form of imLinks (admin/links.php) there's this line:

$objectTable -> addHeader( '<span style="float: left; font-size: 12px; font-weight: bold; color: #0A3760;">' . _AM_IMLINKS_MINDEX_PUBLISHEDLINK . '</span>' );

It seems that the float-statement is causing the issue in Firefox.
Question is why it's an issue for Firefox and not for browsers like IE10 and Opera?



Re: 2.0a2 and themes

I have done some test using themes for 1.3.x in alpha 2.
All works fine; just two minor issues:
1.- Admin menu: in "classic" themes I get two admin menus: "normal" and for mobile devices.
CSS to add for fix it:

.admin .mobileMenu, .mobileMenu {display: none }

for responsive themes
@media only screen and ( max-width: 640px) { .admin .mobileMenu, .mobileMenu { display: block; } .toSel {display: none;} .mobileMenu {max-width: 100%; width: 98%; background-color: #FFFFFF; border: 1px solid #CCCCCC;height: 30px; line-height: 30px; border-radius: 4px 4px 4px 4px; font-size: 14px; padding: 4px 6px; vertical-align: middle;font-weight: normal;margin: 5px 1%;}

The CSS code in core theme is in /skins/v1/media/css/responsive/
and it depends of core theme; for "classic" themes display none for mobilemenu class would be in a CSS file out of core theme too. Right?

2.- User and Main Menu blocks. Now the id are mainMenu and userMenu. Old were mainmenu and usermenu. Special CSS code in old themes is lost in alpha2.



Re: Will phpmailer get updated as well?

What is the specific application you have that requires multiple pages for the form?

Formulize has the ability to create multi-page forms. So does the Profile module.



Re: Will phpmailer get updated as well?

Hi Thomas,
updating the libraries is in the ticket list, so that will be taken care of, sooner rather than later.

What do you mean exactly with a 'multistep form set'?



Will phpmailer get updated as well?

## Version 5.2.6 (April 11th 2013)

I wish there was a way to include a multistep form set up in core.



Re: 2.0a2 and themes

merge request was applied.

Thanks for the report and quick fix.



Re: 2.0a2 and themes

  • 2013/5/8 16:59:51
  • Will

Committed fix and requested merge into 2.0: https://www.assembla.com/code/impresscms/git/merge_requests/280093



Re: Testing 2.0a2

Found that the issue with the imLinks submit forms is caused by the insertBreak().

insertBreak() causes the Fatal error: Call to a member function isRequired() on a non-object in ...\libraries\icms\form\Theme.php on line 58.



2.0a2 and themes

About how work previous themes in this release, I am making some tests and later I will post the results.
Just an issue: in style_icms.css file there are code for #mainmenu and
#usermenu (classics in iCMS), but in system_block_mainmenu.html

<div id="mainMenu">
<li clas="menuMain<
(typo error "clas")



Re: 2.0a2: calendar-datepicker

We need to figure out how to migrate to langcode if you ask me. There are too many inconsistencies in the current way it is handled.

for example : one module is translated in 'dutch', the other one is translated in 'nederlands'. It's the same language, but described in english and the other in dutch.

However, how far do we go. Just 'en', or 'en-gb' as well, considering 'en' a generic replacement for all 'en-xx' languages as we go along?

The translation table isn't a bad idea at all.



Re: 2.0a2: calendar-datepicker

I have used in elFinder this:

lang: "' . _LANGCODE . '",

but I do not know if it is useful for you (my skills are very limited)



Re: 2.0 and plugins

There is an error in mentions, but I'll fix today. Hashtags works, without any changes. Just had to enable them both in the control panel

Ticket 709



Re: 2.0a2: calendar-datepicker

  • 2013/5/7 6:42:13
  • Will

The reason for this is that ui uses the langcode - and icms does not. This makes !i8n difficult as langcode is the accepted format for most everything.

I was considering making a mapping to convert the icms langterm to the accepted langcode format.

Something like:

var lang = {
'english': 'en'
, 'spanish': 'es'
}

Then we would have both at our disposal - and this should help solve the calendar issue.

All that old calendar code is going to be ripped out - as the ui version now handles jalali.




 Top