Discuss: Joomla 1.6 Alpha 2 Released

[mic]

1. get rid of the administrator folder (dynamically renaming within the configuration)

I'm not sure I understand?

As another poster wrote in the meantime, renaming the folder 'administrator' (after/or during installation and/or after installation inside the configuration [backend]) would be good because of serveral reasons.
Of course, 3PD have to rework 'some', but that is live ...

2. renaming of the installation folder (like _timestamp_installation) and assigning new permission (0644) after installation

You could. I still think it's better to teach people to get rid of it. There are some other technical issues about renaming a folder that is executing the code within that folder.

What are the reasons(s) against renaming after the successful installation?
Now each admin has to open again his FTP program and doing this - personally i cannot see any technical reason which speaks against.

3. get rid of the # 62 for the super admin (since we have this since Mambo and that is nearly 10 years)

I changed it to 42 in 1.6 Actually, it could be randomised easily if you really wanted to.

Probably best to follow these up on the CMS developer list.

I do, maybe i have overseen something ...
But, what is the true reason why this id has to be 'something else' than 1 (first of row) or other (randomized)?

[masterchief]

What are the reasons(s) against renaming after the successful installation?
Now each admin has to open again his FTP program and doing this - personally i cannot see any technical reason which speaks against.

I don't think the FTP reason is a big deal because they should already have some file transfer program open (or CPanel, or whatever). If they don't and are using Fantastico or something, it will take care of it anyway.

I think renaming the folder is less of a problem than automatically deleting the folder, which has already been suggested on the dev list, but similar problems exist.

1. It's inconvenient to test (not the end of the world but when you are working in a code repository it'll mess that up the .svn folders as things are renamed - randomly).

2. If you get a failure in the move operation, it is possible that when posting to the next page, it doesn't exist (because it thought it was going to post to the new folder, or something).

As I said on list, I'm not against the idea, but I believe there are functional problems to overcome. In other words, can the process recover gracefully if something stuffs up. If someone wants to take up the challenge, we can certainly look at it.

And, as I said, renaming does give you a false sense of security. The installation folder could be accidentally or brute-force accessed. Is that a big deal? No, not until a vulnerability is found in the installation application.

But, hey, throw some working into coding it and people can take a look.

I do, maybe i have overseen something ...
But, what is the true reason why this id has to be 'something else' than 1 (first of row) or other (randomized)?

I did some research into "why 62" a while back. You can read it here:

http://community.joomla.org/featured-ar ... id-62.html

I changed it to 42 because it's the answer to life, the universe and everything Honestly, it could be 1, it really doesn't matter. Randomising it would help on the off chance an attacker found an SQL injection vulnerability (probably in a 3rd party extension), but even with randomising you have to have a range and that can be traverse via brute-force methods.

Edit: fixed link.

[kjcbq]

Hi Guys, congrats for your hard work.
Did anybody thinking about a core Banner Component with timing possibilities. Banners can have a publication start day, and also an end date for each banner. Like in Articles Manager...
It would be very great to have this feature in 1.6.
Can we hope for something of this?

THX
John

[masterchief]

Did anybody thinking about a core Banner Component with timing possibilities. Banners can have a publication start day, and also an end date for each banner. Like in Articles Manager...
It would be very great to have this feature in 1.6.

I can look into that.

[akede]

Hi John,

I added a note in our development wiki http://docs.joomla.org/Banner_component .

May be you can add some more notes about what you like to get into this feature so that the devs can more easily work on this.

Cheers

Alex

[EdPh]

The www.joomla.org front page has a notice about J1.6 updates, but demands a login. Why? All other J1.6 info has been open - did someone forget to change the status to Public after editing?

[masterchief]

The http://www.joomla.org front page has a notice about J1.6 updates, but demands a login. Why? All other J1.6 info has been open - did someone forget to change the status to Public after editing?

Yep. Try now.

[EdPh]

The http://www.joomla.org front page has a notice about J1.6 updates, but demands a login. Why? All other J1.6 info has been open - did someone forget to change the status to Public after editing?

Yep. Try now.

Thanks. Useful page!

[kjcbq]

I added a note in our development wiki http://docs.joomla.org/Banner_component .
May be you can add some more notes about what you like to get into this feature so that the devs can more easily work on this.

Dear Alex,
Thx for your kindly answer. I think it's a very important feature to working on.
I asked it also in the hungarian forum site (http://forum.joomla.org.hu/vita-megjele ... tml#p38543), and got an answer, that this feature will be achieved in 1.6 Beta. But I can't find any info about this in the developer sites, or in Joomla! 1.6 Tasks. Where can we look for this? Is the banner publication and end dates only a wish, or a really planned development goal?

What I wish to suggest for Devs, only that in the banner component thing can working like in the article manager. Banners maybe can have a publication start and end date, just like in an article. Not just publish or unpublish. I hope that this explanation was more detailed, and somebody in the dev group will be working on it.
Greetings,
John

[masterchief]

But I can't find any info about this in the developer sites, or in Joomla! 1.6 Tasks. Where can we look for this? Is the banner publication and end dates only a wish, or a really planned development goal?

Christophe doesn't think it will be a problem. See: http://groups.google.com/group/joomla-d ... 44f58fafc7

Hope this helps.

[szaboz]

Prior to MySQL 5.0.3, a VARCHAR column with a length specification greater than 255 is converted to the smallest TEXT type that can hold values of the given length. For example, VARCHAR(500) is converted to TEXT, and VARCHAR(200000) is converted to MEDIUMTEXT. However, this conversion affects trailing-space removal.

uh forgot to say you guys are rock regardless this
respect

[bidsro]

SVN 13602

Cannot add new group, Group Parent cannot be selected

Article Manager: Created by show user id instead of dropdown with user name

I'm not very sure, but i think none of Basic Options are not working well. For example, i cannot hide email and/or print, cannot display "Alternative Page Title", Date Modified and so on

Article Access Rules: sorry to ask again, but can i deny/allow group actions in articles? For example, i don't want Managers to delete a certain article. I set Deny to Delete tab but nothing happened after press Save. Then i go to Global Configuration and choose Deny from here, but this is not what i want... (same problem for Edit and Edit State also)

<meta name="robots" content="3" /> mean noindex, nofollow? This is what i choose in article

[Stu-Icon]

What are the reasons(s) against renaming after the successful installation?
Now each admin has to open again his FTP program and doing this - personally i cannot see any technical reason which speaks against.

I don't think the FTP reason is a big deal because they should already have some file transfer program open (or CPanel, or whatever). If they don't and are using Fantastico or something, it will take care of it anyway.

I think renaming the folder is less of a problem than automatically deleting the folder, which has already been suggested on the dev list, but similar problems exist.

1. It's inconvenient to test (not the end of the world but when you are working in a code repository it'll mess that up the .svn folders as things are renamed - randomly).

2. If you get a failure in the move operation, it is possible that when posting to the next page, it doesn't exist (because it thought it was going to post to the new folder, or something).

As I said on list, I'm not against the idea, but I believe there are functional problems to overcome. In other words, can the process recover gracefully if something stuffs up. If someone wants to take up the challenge, we can certainly look at it.

And, as I said, renaming does give you a false sense of security. The installation folder could be accidentally or brute-force accessed. Is that a big deal? No, not until a vulnerability is found in the installation application.

But, hey, throw some working into coding it and people can take a look.

Would it be possible to zip-archive the installation folder when completed? This could be done by automatic forwarding to a special firstrun.php file in the root. firstrun.php could handle the zipping and deletion of the folder and then provide the links onwards to Admin or Client.

Speaking of Admin, moving the Admin folder would probably be best handled within the Configuration.php file
ie
var $adminpath = 'hiddenadminfolder';

If the location of the folder is held somewhere accessible by the application then it would not be difficult, otherwise the next best and probably more secure approach would be to make sure that all path referencing is done dynamically by getting the path to the active file and chopping off the filename.

[k4lch]

Fatal error: Call to a member function startPane() on a non-object in C:\xampp\htdocs\j16\administrator\components\com_contact\views\contact\tmpl\edit.php on line 67

I installed 1.6a2 on windows 7 with xampp 1.7.2 using php 5.3 and get this error when editing contact

[Dangerous Boy]

Fatal error: Call to a member function startPane() on a non-object in C:\xampp\htdocs\j16\administrator\components\com_contact\views\contact\tmpl\edit.php on line 67

I installed 1.6a2 on windows 7 with xampp 1.7.2 using php 5.3 and get this error when editing contact

I use Win7 aswell but instead of xampp I use wampserver for me has been the best choise for local servers, as for the PHP I'd suggest to use PHP 5.2.x...
as for the error I'm sorry but I can't help you on that...

[masterchief]

SVN 13602

Cannot add new group, Group Parent cannot be selected

Fixed now in 13603 (silly mistake on my part). Thanks for that.

Article Manager: Created by show user id instead of dropdown with user name

Correct. I need to change that to a modal popup selector like you have in the menu item that displays a single article.

I'm not very sure, but i think none of Basic Options are not working well. For example, i cannot hide email and/or print, cannot display "Alternative Page Title", Date Modified and so on

Nothing like that works properly on the frontend yet. Sorry.

Article Access Rules: sorry to ask again, but can i deny/allow group actions in articles? For example, i don't want Managers to delete a certain article. I set Deny to Delete tab but nothing happened after press Save. Then i go to Global Configuration and choose Deny from here, but this is not what i want... (same problem for Edit and Edit State also)

That's supposed to be possible. Might be a bug somewhere in the logical. I'll keep my eye out for it.

[masterchief]

Would it be possible to zip-archive the installation folder when completed? This could be done by automatic forwarding to a special firstrun.php file in the root. firstrun.php could handle the zipping and deletion of the folder and then provide the links onwards to Admin or Client.

Yes, that's the type of thing you'd need to do. But then you have to weigh up the complexity of the problem you are trying to solve and the extra "stuff" being added just to save someone having to reopen their FTP client. I'm not convinced we are solving the right problem.

Speaking of Admin, moving the Admin folder would probably be best handled within the Configuration.php file
ie
var $adminpath = 'hiddenadminfolder';

If the location of the folder is held somewhere accessible by the application then it would not be difficult, otherwise the next best and probably more secure approach would be to make sure that all path referencing is done dynamically by getting the path to the active file and chopping off the filename.

Actually, I'd work the other way and have the administrator look at a folder of different configuration files and give you are choice of which site you want to log into.

[masterchief]

Fatal error: Call to a member function startPane() on a non-object in C:\xampp\htdocs\j16\administrator\components\com_contact\views\contact\tmpl\edit.php on line 67

I installed 1.6a2 on windows 7 with xampp 1.7.2 using php 5.3 and get this error when editing contact

Contacts component is not up to date but is being worked on at the moment. Hopefully won't be too long before that is resolved.

[mcsmom]

@k4itch

looks like


jimport('joomla.html.pane');
$pane = &JPane::getInstance('sliders');



was deleted from edit.php. I think if you put it back it works.

also you'll need to restore

<?php echo $pane->endPanel(); ?>

around line 106 (just before the new pane is started).

I think that it's being modernized, but that will make it work until the other stuff is done.

[Tonie]

Maybe to do with these commits by Louis recently?

+ Added JHtmlSliders
+ Added JHtmlTabs
! JPane and child classes has been deprecated in favor of JHtml helpers.

[Transwarp]

I have been playing around with alfa2 for a few days now and I am loving what I see!

The lack luster permissions of previous versions and the cost and complexity of 3rd party ACL programs have kept me from using Joomla for a majority of my clients.

The one thing I hope is on the road map for this feature is the ability to deny/allow extensions.
A lot of my customers want to restrict certain functions like photo galleries, private messaging and chat rooms to paying members or other special groups.

If this versions permissions work out the way I believe they could I will be actively converting as many of my clients as I can because I have long believed that Joomla is the best CMS and you guys and gals on the dev team rock big time.

TW

[mcsmom]

@Transwarp: you are so right. And absolutely as long as an extension developer incoporates the code, it's there for all extensions. How to do that will be a big topic at the developer conference next week.

@Tonie,

You are absolutely correct, and I think that is so cool.
This is how it should look I believe (although I am sure someone else will do it better)

http://joomla.pastebin.com/m6b5d82ab

There is a still a problem with some of the parameters but at least the page will render.

[chdemko]

Hi John,

I added a note in our development wiki http://docs.joomla.org/Banner_component .

May be you can add some more notes about what you like to get into this feature so that the devs can more easily work on this.

Cheers

Alex

Hi,

I'm actually developing the new com_banners component. I need some community feedback in
http://groups.google.fr/group/joomla-de ... 44f58fafc7

You can test it with

Code: Select all

svn checkout http://joomlacode.org/svn/joomla/development/branches/chdemko

Ch.D

[df23]

just about to dive into trying out the ACL in Alpha2. From reading the tutorial (which is very good) i cant wait to get going with it

One initial thought i have from looking at the various permission setting pages is that many of these configs will remain set at "Inherit". On a large site it can take time to identify what the inherited setting is. This would be useful to know when setting up a site and/or diagnosing where a config needs to be corrected (I know i'm not going to get all of them right first time!).

Would there be some way of indicating this on the config screens? May be with a red/green coloured square in front of each drop down list to show the value that will be used if that item is set to inherited. I know this would add an overhead to building each permission config page but they are not going to be used too often once a site is set up and it could save admins some valuable time.

Could this be done?

thanks
Dave

[masterchief]

One initial thought i have from looking at the various permission setting pages is that many of these configs will remain set at "Inherit". On a large site it can take time to identify what the inherited setting is. This would be useful to know when setting up a site and/or diagnosing where a config needs to be corrected (I know i'm not going to get all of them right first time!).

Yes, one thing I don't think people realise is that greater access control means greater work and there is little we can actually do about that. If you want the granularity, you have to be prepared to micro-manage it. That said, yes, I've thought about some sort of "report" but to date I've not really come up with an elegant solution. It would probably come under the umbrella of what could be called an "Asset Browser" but I'd probably need a few keen folk to just on the dev list and throw a few ideas around.

[ametzler]

I'm really impressed with the progress and just drooling waiting for the RC, though I know it will still be a bit. Our school district is still running on 1.0 because I have a nice ACL component added to it but it takes forever to setup permissions, plus it's an addon so it doesn't have full integration. I haven't been able to take our school districts website to 1.5 because of the ACL piece but 1.6 is going to make my life sooooo much easier. I am actually presenting to our tech committee tomorrow and talk to them about the new features we will be able to add and get feedback on new stuff to add since what we can do will open up so much more stepping up to 1.6.

Anyway, keep up the great work!!

[MamboLives]

Unlike others here i'm NOT impressed by J1.6 alpha2 :

- i can't see any real CCK nor custom fields nor anything comparable to Drupal or Typo3
- the ACL leaves a lot to be desired
- addons for J1.5 will need to be fixed or rewritten from scratch
- profile fields can't be much customized so far
- no SEF improvements

Then the lead dev tells us to not worry because in J1.7 there'll be a real super duper
CCK and more API hacks so once again we'll have to rewrite our scripts and addons,
and be ready for J2.0 with a whole new architecture totally incompatible with anything
for J1.xx

And if you dare to complain you'll be told to write your own CMS yourself.

Now, is it me or the whole joomla project is leading nowhere ?
I mean, it's sad to say this but nowadays even Wordpress beats Joomla in many fields.

I'm sticking with J1.5.xx because customers asked so, but i'm definitely looking out
for TYPO3 if i need a serious solution for complex portals and medium complex web sites.

This discussion is very informative as we can hear from the horse's mouth that
Joomla will always stay as a perpetual work-in-progress kept together with duct tape.

[Reind]

I saw there is an comment system implemented into 1.6 and i have just one thing to mention...

Please, please, please make an auto close function for this comment system. It lacks on most other comment systems out there and it's someting big news sites like mine would shurely apriciate.

Why should there be an "auto close function" for the comment system? Simple, because you dont want people to comment on old articles that nobody reads anymore or because the article is out of date...

ps, pardon my french... i'm dutch

[masterchief]

Unlike others here i'm NOT impressed by J1.6 alpha2 :

No harm in admitting that. If everyone says "hey it's cool" we are none the wiser as to why they think it is. Likewise, negative feedback is also useful when you give reasons (that's something you could actually work on though - see comments below).

- i can't see any real CCK nor custom fields nor anything comparable to Drupal or Typo3

No you can't because it's not there. What has been advertised is that the JForm API should help CCK-like apps if they choose to use it.

- the ACL leaves a lot to be desired

Really? Tell us why. As a developer (assuming you are from other comments) what would you do better in terms of the schema, API and the UI?

- addons for J1.5 will need to be fixed or rewritten from scratch

That depends on the individual extension. As I've said before, if you rely on Legacy Mode you are dead in the water. If you run on the native API you are in an extremely good place. If you are in between, you are on your own. What extensions do you currently write? I can maybe give you some advice on where you fit along that scale.

- profile fields can't be much customized so far

Correct. It's currently advertised as a proof-of-concept on how to do it. Anyone is welcome to contribute a more advanced example.

- no SEF improvements

Really? Why do you say that?

Then the lead dev tells us to not worry because in J1.7 there'll be a real super duper
CCK and more API hacks so once again we'll have to rewrite our scripts and addons,
and be ready for J2.0 with a whole new architecture totally incompatible with anything
for J1.xx

Maybe there will, maybe there won't. Depends on the input from the developer community.

And if you dare to complain you'll be told to write your own CMS yourself.

Only if you complain when expecting someone else to do all the work you personally want :P As I inferred above, complaining isn't a problem providing "you" do it with the attitude that you want things improved and are willing to engage. Complaining for complaining's sake is of no real value to anyone. Anyone who has kids knows this simple fact of life

Now, is it me or the whole joomla project is leading nowhere ?
I mean, it's sad to say this but nowadays even Wordpress beats Joomla in many fields.

Wordpress does in the things it's best at as does Joomla. I don't think anyone who knows the two systems would dispute that. You need to remember Wordpress is a subset of Joomla possible features so it's logical that it might micro-manage what it specialises in better than Joomla.

I'm sticking with J1.5.xx because customers asked so, but i'm definitely looking out for TYPO3 if i need a serious solution for complex portals and medium complex web sites.

You are perfectly at liberty to stick with 1.5 - for some people that will make a lot of sense and if your customers are requesting that it would behove you to listen to them. Good luck with TYPO3 though. Even Kasper will tell you Joomla fits in a space below where TYPO3 starts. T3 is a great system for what it's best at. If that suits your needs, and you have what it takes to train your customers to use it, go for it. Thought, I warn you, if you can't teach you customers Joomla, then T3 is going to be an extreme uphill battle for you.

This discussion is very informative as we can hear from the horse's mouth that
Joomla will always stay as a perpetual work-in-progress kept together with duct tape.

With respect, of course it's a perpetual work-in-progress. Software that isn't is called "abandonware".

[masterchief]

I saw there is an comment system implemented into 1.6 and i have just one thing to mention...

Please, please, please make an auto close function for this comment system. It lacks on most other comment systems out there and it's someting big news sites like mine would shurely apriciate.

There won't be an auto-close function out of the box. It's a good idea. Hopefully someone will want to pick up actually doing that.