[ANNOUNCE] TightBlog 3.0 released!

[Glen Mazza]

https://github.com/gmazza/tightblog

My third annual release.  TightBlog is a bottom-to-(nearly)-top rewrite 
of Apache Roller, featuring a greatly modernized and streamlined source 
code base (Java class files dropped from ~493 in Roller 5.1 to 119 in 
TB3) and data model (33 database tables with Roller to just 12 with 
TB3.)  It is presently used to power my own blog at glenmazza.net.


TightBlog 3.0's highlights are a switch from Velocity to Thymeleaf for 
blog templates, better Tag and Category statistics and management, as 
well as the option to use Google Authenticator for two factor 
authentication to log into your blog (enabled by default).  Please see 
the README (https://github.com/gmazza/tightblog/blob/master/README.md) 
for new functionality TightBlog has added since branching off from 
Roller in 2015 (please note though that much low/no demand functionality 
in Roller has been removed from TB, so good to run the demo locally as 
given in the README to determine if TB meets your needs).


This is a Roller list, so any deployment questions, etc., please create 
a GitHub issue at https://github.com/gmazza/tightblog or contact me at 
gmazza at apache dot org.

Re: Roller 5.2.0-rc-4 available for review

[Glen Mazza]

When I was about to deploy TightBlog on Linode, I noticed the Linode 
terms (if I recall correctly) required any email sending system to 
provide an ability for people who have signed up for something to 
unsubscribe for what they signed up for, something quite reasonable that 
I had overlooked in my Roller fork.  As a result, I had to make a patch 
release of TB to provide an unsubscribe link in notification emails for 
those who checked "notify me" for blog comments before I could deploy 
it.  Roller may wish to add similar functionality in its own product, as 
it is otherwise a show-stopper for hosting providers having similar 
requirements.


Glen


On 10/14/2017 05:04 PM, Dave wrote:

I've prepared a fourth release candidate for Roller 5.2.0. This release is
primarily a bug fix release, with lots of fixes from Kohei and others. I
have created a release candidate which you can find here:

 https://dist.apache.org/repos/dist/dev/roller/roller-5.2/v5.2.0-rc-4/

And the list of issues resolved in 5.2.0 is here:


https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310906&version=12340980

Thanks again to Greg and Kohei for finding some issues in the previous RCs.
I believe I have fixed all the problems found so far. Here's what has
changed since rc-3:

1. Added missing Struts action names to struts.xml
2. Explicity list directories to be included in release (removes
extraneous files)
3. Removed duplicate ROME fetcher dependency
4. Fixed Maven Resource "filtering" problem in roller.properties
5. Add missing log4j-core dependency, needed by Log4J2
6. Reduce Log4j2 logging level to "warn" for Struts2


I'm currently running this code on rollerweblogger.org and it seems to be
working well.

Please take a look when you get a chance and I will call for a vote in 3-4
days.

Thanks,
Dave

exiting project

[Glen Mazza]

Hi Dave,

I'm resigning my Roller committership, would you please remove my 
karma?  I no longer need write access to its source code.


Thanks!
Glen

Leaving Roller PMC

[Glen Mazza]

Hi Team,

I've decided to resign from the Apache Roller PMC while still retaining 
Roller committership.  I'm thinking right now of forking Roller and 
going my own way, as full control would allow me to focus on coding 
instead of persuading, as with many projects the 80% where we're all in 
agreement has already been done, it's that last 20% where we have 
different, incompatible, directions we'd like to go that we're now in.  
Building an alternative product would put me in a conflict of interest 
situation if I were to remain on the PMC, so I think it would be best to 
leave it.


I've unsubscribed from the Roller private list and updated the website 
team list.  Dave, if there's anybody you need to notify that I'm no 
longer on the PMC please do so.


Thanks,
Glen

Re: svn commit: r1669020 - /roller/cmssite/trunk/content/downloads/downloads.mdtext

[Glen Mazza]

Remember, you got to hit the "publish site" at Step #5 here:
http://roller.apache.org/getinvolved/edit_website.html for the changes to
go (immediately) live.

Note the staging website linked to at Step #4 may not seem to have the
updates but that is because the links to the download page are hardcoded to
http://roller.apache.org/downloads/downloads.html.  Manually changing the
URL in your browser to http://roller.staging.apache.org/... will show that
it has updated and will move to http://roller.apache.org/... once you hit
the publish site button.

Glen

On Tue, Mar 24, 2015 at 7:09 PM,  wrote:

> Author: snoopdave
> Date: Tue Mar 24 23:09:59 2015
> New Revision: 1669020
>
> URL: http://svn.apache.org/r1669020
> Log:
> Update site to point to 5.1.2
>
> Modified:
> roller/cmssite/trunk/content/downloads/downloads.mdtext
>
> Modified: roller/cmssite/trunk/content/downloads/downloads.mdtext
> URL:
> http://svn.apache.org/viewvc/roller/cmssite/trunk/content/downloads/downloads.mdtext?rev=1669020&r1=1669019&r2=1669020&view=diff
>
> ==
> --- roller/cmssite/trunk/content/downloads/downloads.mdtext (original)
> +++ roller/cmssite/trunk/content/downloads/downloads.mdtext Tue Mar 24
> 23:09:59 2015
> @@ -8,7 +8,7 @@ general public at no charge, under the
>  in both binary and source distributions.
>
>  General Availability (GA) Releases - Ready for Prime
> Time!
> - href="http://www.apache.org/dyn/closer.cgi/roller/roller-5.1/v5.1.1/";>Roller
> 5.1.1 (Released 1 October 2014)
> + href="http://www.apache.org/dyn/closer.cgi/roller/roller-5.1/v5.1.2/";>Roller
> 5.1.2 ("best available")
>
>  Previous source and binary distributions, including documentation,
>  are available in the
> @@ -28,7 +28,7 @@ support options hosted by the Apache Rol
>
>  Note: When downloading from a mirror, please be sure to verify that
> checksums and signatures are correct.
>  To do so, use the checksum and signature files from the main Apache site
> at
> -http://www.apache.org/dist/roller/roller-5.1/v5.1.1/bin/";>
> http://www.apache.org/dist/roller/roller-5.1/v5.1.1/bin/
> +http://www.apache.org/dyn/closer.cgi/roller/roller-5.1/v5.1.2/bin/";>
> http://www.apache.org/dyn/closer.cgi/roller/roller-5.1/v5.1.2/bin/
>  Find here the KEYS file, which contains all OpenPGP keys we use to sign
> releases:
>  http://www.apache.org/dist/roller/";>
> http://www.apache.org/dist/roller/
>
>
>
>

Re: [VOTE] Release Roller 5.1.2

[Glen Mazza]

My blog's been humming along fine with it.  +1.

Thanks for getting this release together.

Glen

On 03/15/2015 04:56 PM, Dave wrote:

Hi Roller fans,

I'm re-opening the voting on RC1. I thought there were enough issues to
hold back the release but I think I was wrong. So...

I would like to propose that we release Roller 5.1.2 based on the code at
Subversion tag roller_5.1.2-rc1. You can download the source release,
convenience binaries and signatures for the release here:

https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.2/

The release contains a variety of mostly minor fixes which you can find
listed here:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20ROL%20AND%20fixVersion%20%3D%205.1.2%20AND%20updated%20%3E%3D%20-20w%20ORDER%20BY%20updated%20DESC

Please vote within the next 72 hours.

I'm voting  +1

Thanks,
Dave

Re: [CANCELLED] Release Roller 5.1.2

[Glen Mazza]

Dave, I tested the app and even upgraded my blog to 5.1.2 RC1, it's 
running fine.  Unless *you* want to create an RC2, I would just reopen 
ROL-2063 for later analysis and release the current RC. Here's my +1 for 
RC1.


Regards,
Glen

On 03/05/2015 12:58 PM, Dave wrote:

Consensus seems to be that we'll need at least one more release candidate
to get this right, so I"m going to cancel this vote. Thanks for the reviews
and comments.

- Dave

Re: [VOTE] Release Roller 5.1.2

[Glen Mazza]

Hi Kohei, I commented on it, I'm not sure Dave needs to do a new build 
just for this issue, your older patch fixed 90% of the problem and it's 
not that much for someone having a problem with the other 10% to make a 
manual change to their database to fix the issue.  For a more permanent 
solution, I might recommend just changing the database widths from 2 to 
3 in our createdb script (i.e., just keep the JIRA item open for now) so 
brand new users are fine but not bother creating 5.1.1->5.1.2 migration 
scripts for something as minimal as that.  For the half-dozen who might 
bark at us we can tell them to just manually make the width change in 
their own databases.


Unless Dave is certain he wants to create a new RC, I plan on testing 
the current one and approving it if it works for me.


Glen

On 03/01/2015 08:04 PM, Kohei Nozaki wrote:

Sorry I just found a problem to my patch which accepted in 
https://issues.apache.org/jira/browse/ROL-2063 . could you take a look at my 
new patch ROL-2063_update1.patch and comment in that JIRA?

ROL-2063_update1.patch


On Mar 2, 2015, at 4:56, Dave  wrote:


Hi Roller fans,

I would like to propose that we release Roller 5.1.2 based on the code at
Subversion tag roller_5.1.2-rc1. You can download the source release,
convenience binaries and signatures for the release here:

   https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.2/

The release contains a variety of mostly minor fixes which you can find
listed here:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20ROL%20AND%20fixVersion%20%3D%205.1.2%20AND%20updated%20%3E%3D%20-20w%20ORDER%20BY%20updated%20DESC

Please vote within the next 72 hours.

I'm voting  +1

Thanks,
Dave

Re: [CANCELLED] Release Roller 5.1.2

[Glen Mazza]

OK, there's a draft entry on our team blog that lists each of the JIRA 
items closed for 5.1.2, when you're ready for the announcement email you 
can just copy it into a new blog post (so the post will have your name 
on it) and then just write whatever blurb/sales pitch above it.


Glen

On 03/05/2015 12:58 PM, Dave wrote:

Consensus seems to be that we'll need at least one more release candidate
to get this right, so I"m going to cancel this vote. Thanks for the reviews
and comments.

- Dave

Re: [VOTE] Release Roller 5.1.2

[Glen Mazza]

If I could be given this weekend to test the build before voting that 
would be very helpful for me, I'm busy at work this week.  I just want 
to test locally, and then deploy my blog using the RC, and that will be 
enough for my +1.  I created a skeleton draft entry on the team blog 
announcing 5.1.2 a couple of months ago, normally it has a table listing 
the fixed JIRA items, I'll go ahead and update that table this weekend, 
and Dave can use that (adding whatever blurb above it) when he does the 
announcement blog entry.


I'm hoping that Kohei's recent change to the salt code will fix 
https://issues.apache.org/jira/browse/ROL-1818.  Greg/Kohei, could there 
be a relation?  With my blog, I'll start a draft entry, wait 20 minutes, 
and try to save it, if the problem exists with 5.1.1 but not with 
5.1.2-RC1 I think we can close the matter as resolved.


Glen


On 03/01/2015 08:04 PM, Kohei Nozaki wrote:

Sorry I just found a problem to my patch which accepted in 
https://issues.apache.org/jira/browse/ROL-2063 . could you take a look at my 
new patch ROL-2063_update1.patch and comment in that JIRA?

ROL-2063_update1.patch


On Mar 2, 2015, at 4:56, Dave  wrote:


Hi Roller fans,

I would like to propose that we release Roller 5.1.2 based on the code at
Subversion tag roller_5.1.2-rc1. You can download the source release,
convenience binaries and signatures for the release here:

   https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.2/

The release contains a variety of mostly minor fixes which you can find
listed here:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20ROL%20AND%20fixVersion%20%3D%205.1.2%20AND%20updated%20%3E%3D%20-20w%20ORDER%20BY%20updated%20DESC

Please vote within the next 72 hours.

I'm voting  +1

Thanks,
Dave

Nice new logo!

[Glen Mazza]

Hi Dave, thanks for updating the Roller logo on Twitter and the team 
blog, switching from 5.0 --> 5: https://twitter.com/apache_roller.  This 
will allow us to close ROL-2048.  To update the logo on our website, 
just follow this process:  
http://roller.apache.org/getinvolved/edit_website.html, skip step #2, 
commit at step #3, look at the change on the staging website given at 
step #4, and if it looks good then publish the change to our main site 
using the button at step
#5.  I can take care of this for you but probably good for you to go 
through the process if you haven't updated our website lately.


Glen

Re: [VOTE] Release Roller 5.1.2

[Glen Mazza]

We presently have indexes on the entryid in roller_comment (line 236) 
and on website_id in weblogentry (line 174): 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/resources/sql/createdb.vm?revision=1625869&view=markup. 
It wouldn't be a disaster, but I'm inclined against denormalization 
(duplicating website ids in the roller_comment table) as I believe a 
relational model is a strong selling point for Roller, it's better to 
let heavy users do what tweaking--whatever indexes or database 
changes--they need to do to support their custom needs.


Since Matt's blog is the only blog on his instance, he can also do some 
of the same comment management on the global comment management screen, 
which doesn't have that join.  Actually, it would be good for him to do 
that just to see if the problem goes away there (i.e., it's a database 
join issue), or if it doesn't then it might be a memory problem 
unrelated to the join.


The indexes could also possibly be hurting him because there's only one 
website id for his blog server and it's inefficient to go to indexes 
instead of the tables directly when every record they would find would 
be fitting anyway.


Matt can also remove the join from the .orm.xml file, do an mvn clean 
install to get a custom build and then deploy that.  His blog comment 
management page would list all comments, but that wouldn't matter as he 
just has one blog.  I think Matt had earlier stated he has a 
non-standard Roller installation that doesn't lend itself to an 
automatic upgrade so some hacking on his part is probably going to be 
needed anyway if he wishes to upgrade.


Glen

On 03/03/2015 03:29 AM, Greg Huber wrote:

SELECT c FROM WeblogEntryComment c  WHERE c.weblogEntry.website = ?1 ORDER
BY c.postTime DESC

Could experiment with some indexes. or add websiteid to the
roller_comment so it does not have to do the join with weblogEntry to get
the website parameter #1.  The websiteid does not change.

On 2 March 2015 at 19:29, Matt Raible  wrote:


Is it possible to optimize the query that loads the comments in the Admin
UI? When I click on the "comments" section (in the Admin UI), it takes a
really long time to load and I sometimes see the following error. The
sysadmin at my ISP (kgbinternet.com) said this SQL takes a long time to
run
and is sometimes killed by the server.


https://drive.google.com/file/d/0B9kkDCT2WDMXNE9XZl9LSXVHbmVjeklyVnBGNm9jd3p4R0gw/view?usp=sharing

My blog has 3193 entries and 13,799 comments (since 2002).

Thanks,

Matt

On Sun, Mar 1, 2015 at 6:04 PM, Kohei Nozaki 
wrote:


Sorry I just found a problem to my patch which accepted in
https://issues.apache.org/jira/browse/ROL-2063 . could you take a look

at

my new patch ROL-2063_update1.patch and comment in that JIRA?

ROL-2063_update1.patch


On Mar 2, 2015, at 4:56, Dave  wrote:


Hi Roller fans,

I would like to propose that we release Roller 5.1.2 based on the code

at

Subversion tag roller_5.1.2-rc1. You can download the source release,
convenience binaries and signatures for the release here:

   https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.2/

The release contains a variety of mostly minor fixes which you can find
listed here:



https://issues.apache.org/jira/issues/?jql=project%20%3D%20ROL%20AND%20fixVersion%20%3D%205.1.2%20AND%20updated%20%3E%3D%20-20w%20ORDER%20BY%20updated%20DESC

Please vote within the next 72 hours.

I'm voting  +1

Thanks,
Dave

Re: Fwd: Jenkins build is back to normal : Roller #1498

[Glen Mazza]

I'm unsure what the other projects do but I think the status quo is OK.  
We only get a message that everything is OK after a failure, and 
sometimes it's good to get failures because they point to problems 
outside of the code but in the Jenkins process.  We may go another three 
weeks with no emails due to consecutive success builds.


Glen

On 01/23/2015 03:59 AM, Greg Huber wrote:

Can we not poll the SCM and if there are changes do the build, rather than
running it every day regardless of changes?

Cheers Greg.


-- Forwarded message --
From: Apache Jenkins Server 
Date: 23 January 2015 at 08:55
Subject: Jenkins build is back to normal : Roller #1498
To: dev@roller.apache.org, glen.ma...@gmail.com


See 

Re: Shiro not Spring

[Glen Mazza]

Hi Matt, I liked your AppFuse comment "I think the biggest value that 
AppFuse provides now is a learning tool for those who work on it."  
That's been my experience with volunteering on Apache Roller, a largely 
sleepy project but I've found two nice positions so far as a result of 
volunteering on it.


Glen


On 12/23/2014 10:20 PM, Matt Raible wrote:

Nice work Dave! I know Spring Security better than Shiro because I find it
a lot more on client projects. However, I worked with it a few years ago[1]
and found the experience to be enjoyable.

I think Roller is in a similar boat to AppFuse these days in that the
primary goal should be making it easier to maintain[2]. I doubt we'll
attract a lot of new users with all the blogging platforms available today,
but that doesn't mean it can't be fun to work on. ;)

Happy Holidays!

Matt

[1] http://raibledesigns.com/rd/entry/java_web_application_security_part2
[2] http://raibledesigns.com/rd/entry/appfuse_reduced

On Tue, Dec 23, 2014 at 3:56 PM, Dave  wrote:


I'm learning about Apache Shiro, so I decided to see how hard it would be
to replace Spring Security in Roller with Shiro. It was a little painful,
but I eventually got it working. Shiro seems a lot easier to deal with, and
it allowed me to complete remove all Spring dependencies from my fork of
Roller.

You can see my DIFFs here:
https://github.com/snoopdave/rollarcus/compare/shiro_not_spring?expand=1

And the shiro.ini config file is here:

https://github.com/snoopdave/rollarcus/blob/shiro_not_spring/app/src/main/resources/shiro.ini

Most of the changes are removal of Spring specific code. However, my branch
does not support LDAP or OpenID yet, so I would expect that some Shiro
specific code would have to be added to enable those things.

I'm not convinced that Roller should switched to Shiro, but this is some
food for thought...

- Dave

Re: Jenkins build is still unstable: Roller » Roller webapp #1484

[Glen Mazza]

I changed the instructions to mvn clean install, and started a new build
right now.  We'll see if that helps.

On Thu, Jan 15, 2015 at 2:44 AM, Greg Huber  wrote:

> Glen,
>
> Thinking about this, I think it the fact that the directory is too big or
> has too many files.  If you download the target.zip all the files have a
> date before 2015.
>
> We need to add a clean to the Jenkins build:
>
> mvn clean install
>
> or find out why it is not clearing the target directory.
>
> Cheers Greg
>
>
> On 15 January 2015 at 01:14, Glen Mazza  wrote:
>
> > Greg, thanks for looking into this.  You may wish to ask Infra for
> > configuration access to the Roller project at: https://builds.apache.org
> > (Dave and I both have it already) so you can immediately check our
> > configuration.  I can't see a user.dir there either, but there may be
> other
> > issues, we've configured Jenkins to use Maven 3.0.5 for example, but I
> have
> > 3.1.1 on my machine.
> >
> > What you have below is excellent debugging to send off to the infra@
> > mailing list or add as an Infra JIRA ticket for somebody, either Roller
> or
> > Infra to track and fix someday.
> >
> > (Hmm, I had updated some Roller dependencies recently, I wonder if this
> is
> > related to it...)
> >
> > Glen
> >
> >
> > On 01/14/2015 08:49 AM, Greg Huber wrote:
> >
> >> There does not seem to be any thing wrong with the roller itself, but
> >> there
> >> is a difference between the two builds:
> >>
> >> user.dir=/x1/jenkins/jenkins-slave/workspace/Roller
> >> user.dir=/home/jenkins/jenkins-slave/workspace/Roller
> >>
> >>
> >> last successful build:
> >>
> >> main:
> >> /home/jenkins/jenkins-slave/workspace/Roller/app/src/main/resources/sql
> >>  [texen] Using contextProperties file:
> >> /home/jenkins/jenkins-slave/workspace/Roller/app/src/main/
> >> resources/sql/dbscripts.properties
> >>  [texen] Generating to file
> >> /x1/jenkins/jenkins-slave/workspace/Roller/app/target/
> >> dbscripts/README.txt
> >> [INFO] Executed tasks
> >> ..
> >> user.dir=/x1/jenkins/jenkins-slave/workspace/Roller
> >>
> >> latest build:
> >>
> >> main:
> >> /home/jenkins/jenkins-slave/workspace/Roller/app/src/main/resources/sql
> >>  [texen] Using contextProperties file:
> >> /home/jenkins/jenkins-slave/workspace/Roller/app/src/main/
> >> resources/sql/dbscripts.properties
> >>  [texen] Generating to file
> >> /home/jenkins/jenkins-slave/workspace/Roller/app/target/
> >> dbscripts/README.txt
> >> [INFO] Executed tasks
> >> ..
> >> user.dir=/home/jenkins/jenkins-slave/workspace/Roller
> >>
> >>
> >> I had a look at my local jenkins but could not find any user.dir
> property.
> >>
> >> On 14 January 2015 at 11:36, Apache Jenkins Server <
> >> jenk...@builds.apache.org> wrote:
> >>
> >>  See <
> >>> https://builds.apache.org/job/Roller/org.apache.roller$
> >>> roller-webapp/changes
> >>>
> >>>
> >
>

Re: Jenkins build is still unstable: Roller » Roller webapp #1484

[Glen Mazza]

Greg, thanks for looking into this.  You may wish to ask Infra for 
configuration access to the Roller project at: https://builds.apache.org 
(Dave and I both have it already) so you can immediately check our 
configuration.  I can't see a user.dir there either, but there may be 
other issues, we've configured Jenkins to use Maven 3.0.5 for example, 
but I have 3.1.1 on my machine.


What you have below is excellent debugging to send off to the infra@ 
mailing list or add as an Infra JIRA ticket for somebody, either Roller 
or Infra to track and fix someday.


(Hmm, I had updated some Roller dependencies recently, I wonder if this 
is related to it...)


Glen


On 01/14/2015 08:49 AM, Greg Huber wrote:

There does not seem to be any thing wrong with the roller itself, but there
is a difference between the two builds:

user.dir=/x1/jenkins/jenkins-slave/workspace/Roller
user.dir=/home/jenkins/jenkins-slave/workspace/Roller


last successful build:

main:
/home/jenkins/jenkins-slave/workspace/Roller/app/src/main/resources/sql
 [texen] Using contextProperties file:
/home/jenkins/jenkins-slave/workspace/Roller/app/src/main/resources/sql/dbscripts.properties
 [texen] Generating to file
/x1/jenkins/jenkins-slave/workspace/Roller/app/target/dbscripts/README.txt
[INFO] Executed tasks
..
user.dir=/x1/jenkins/jenkins-slave/workspace/Roller

latest build:

main:
/home/jenkins/jenkins-slave/workspace/Roller/app/src/main/resources/sql
 [texen] Using contextProperties file:
/home/jenkins/jenkins-slave/workspace/Roller/app/src/main/resources/sql/dbscripts.properties
 [texen] Generating to file
/home/jenkins/jenkins-slave/workspace/Roller/app/target/dbscripts/README.txt
[INFO] Executed tasks
..
user.dir=/home/jenkins/jenkins-slave/workspace/Roller


I had a look at my local jenkins but could not find any user.dir property.

On 14 January 2015 at 11:36, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:


See <
https://builds.apache.org/job/Roller/org.apache.roller$roller-webapp/changes

Re: next ideas for Roller...

[Glen Mazza]

Hi David, our OOTB roles and the permissions assigned to them are listed 
here: 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/resources/org/apache/roller/weblogger/config/roller.properties?annotate=1618360#l353 
(lines 354-356).


As it shows, we ship with only two roles:  editor (i.e., a standard 
blogger) and admin (someone who has full control of the blog server 
including all blogs.)  While there are four permissions: login, comment, 
weblog, and admin, we don't yet bother maintaining a role for someone 
who can just login or someone who can just login and make comments.  
Further, the permissions are "Russian doll" like as each higher 
permission automatically includes the lower ones, so there's not really 
16 possible permutations but just four (L, L&C, L&C&W, L&C&W&A).  But 
even if an integrator wanted to add a new role that just does C&A for 
example, there's nothing stopping him.  Roller probably can't support 
that (they'd have to hack the code--how can you be an admin if you can't 
log in?) but you can add such a role to the configuration file.  With so 
few permissions and few sensible permutations, you can understand my 
position that we don't need to support multiple roles per user, that one 
is sufficient.  Strictly speaking, we could get away with roles entirely 
and just have a boolean "isAdmin" in the user table and 98% wouldn't 
notice the difference, given that for virtually all installations one is 
either an admin or an editor.  But allowing a single role with 
configurable permissions allows customizers some flexibility they might 
like.


To answer your question, Roller presently stores two roles (editor and 
admin) in the user_role table for admins (redundant because why bother 
adding editor when admin already includes the editor's permissions, 
suggesting a possible problem that Roller might be checking for roles 
when it should be checking for permissions) so we would not be able to 
put such a constraint in now.  Still, we have migration script 
possibilities to just store the higher of the two roles in the 
rolleruser table and just get rid of the user_role table, my preference 
of course.  Then again, I would need more support from the team before 
doing this and also time to get it done.  :)


Glen

On 12/26/2014 08:32 PM, David Jencks wrote:

I haven't looked at Roller's security model for many years, so there's a good 
chance my comments are nonsense.

If there are really only 4 permissions then there are only 16 possible roles.   
The point of roles is usually to simplify assigning sets of permissions to 
users.  If there are only 16 possible roles multiple assignments seem sort of  
excessive.  Certainly in this case I'd expect to be able to view which of the 4 
permissions a user had.

That being said, could the one-role-per user be enforced by simple adding a 
uniqueness constraint on the user-role association table for the user id?

thanks
david jencks

On Dec 26, 2014, at 5:39 PM, Glen Mazza  wrote:


On 12/26/2014 09:30 AM, Dave wrote:

On Thu, Dec 25, 2014 at 9:42 PM, Glen Mazza  wrote:


For the next release of Roller, I have some suggestions that I think will
increase adoption of Roller in corporate multi-blogger environments:

1.) I've brought this up before, but with 5.1 now out, I'd like to revisit
it.  I'd like us to tighten up our security subsystem by moving from
multiple roles per user to just a single role (presently ADMIN, EDITOR, or
whatever custom role an integrator may choose to create.) Specifically the
userrole table (lines 28-32 here: http://svn.apache.org/viewvc/
roller/trunk/app/src/main/resources/sql/createdb.vm?
revision=1625869&view=markup) would be dropped, and the rolename column
moved to the roller_user table.

Roller is not the Oracle RDBMS, we do not have nearly enough permissions
(just 3 or so) to assign to those roles to warrant needing to store
multiple roles with each user, and code needing to maintain and query
multiple roles per user is much more confusing/complex and prone to
security holes.  The current over-functional security architecture does not
provide easy confidence to integrators that Roller is secure to use,
harming adoption IMO.

By way of analogy, if you're crossing a stream via a footbridge very high
up, you don't care about all the bells and whistles the footbridge has, you
just want it to be clearly strong and solid, even if it's plain-looking,
else you won't walk on it.  Excessive bells and whistles may be great with
functionality but backfire with security as you lose confidence in the
product's ability to accurately calculate the proper permissions for each
user.


I think that is an unnecessary change that will have zero impact on
adoption, will cause and schema churn and introduce bugs. I would be better
to stick with the simple and conventional 

Re: next ideas for Roller...

[Glen Mazza]

On 12/26/2014 09:30 AM, Dave wrote:

On Thu, Dec 25, 2014 at 9:42 PM, Glen Mazza  wrote:


For the next release of Roller, I have some suggestions that I think will
increase adoption of Roller in corporate multi-blogger environments:

1.) I've brought this up before, but with 5.1 now out, I'd like to revisit
it.  I'd like us to tighten up our security subsystem by moving from
multiple roles per user to just a single role (presently ADMIN, EDITOR, or
whatever custom role an integrator may choose to create.) Specifically the
userrole table (lines 28-32 here: http://svn.apache.org/viewvc/
roller/trunk/app/src/main/resources/sql/createdb.vm?
revision=1625869&view=markup) would be dropped, and the rolename column
moved to the roller_user table.

Roller is not the Oracle RDBMS, we do not have nearly enough permissions
(just 3 or so) to assign to those roles to warrant needing to store
multiple roles with each user, and code needing to maintain and query
multiple roles per user is much more confusing/complex and prone to
security holes.  The current over-functional security architecture does not
provide easy confidence to integrators that Roller is secure to use,
harming adoption IMO.

By way of analogy, if you're crossing a stream via a footbridge very high
up, you don't care about all the bells and whistles the footbridge has, you
just want it to be clearly strong and solid, even if it's plain-looking,
else you won't walk on it.  Excessive bells and whistles may be great with
functionality but backfire with security as you lose confidence in the
product's ability to accurately calculate the proper permissions for each
user.


I think that is an unnecessary change that will have zero impact on
adoption, will cause and schema churn and introduce bugs. I would be better
to stick with the simple and conventional model, which is users have roles.


I see it oppositely -- in my evalution, the presence of the userrole 
table is the biggest handicap for Roller for getting greater usage in 
companies today, the unwarranted clumsiness it adds to the security 
model makes it that much harder for a security expert to analyze and 
assure that it's secure--namely, that unwarranted roles are not getting 
attached to users.  There's little I can do for increasing Roller 
adoption, especially within companies, so long as we keep that table.  
I'm thinking about forking Roller over this very issue.  That said, I 
have very little time to add to the project now anyway due to work 
constraints, so I doubt I'll be going my own way on this.  If you guys 
want to keep this table, we'll keep it, but I think it's a unfortunate 
decision.






2.) Once that is done, it will be easier to determine who's an Admin, and

we have JIRAs already to allow Admins to drop users as well as obtain email
notifications of when users create or drop blogs.  I think blog admins
would like this increased "driver's seat" functionality and it would make
them more likely to adopt Roller within their company.


The change will not make it easier to determine who is an admin. What could
be easier than userManager.hasRole("admin", users)?



Oh, the call is simple, but what does it mean when someone has both the 
EDITOR and the ADMIN role when they have no reason to have both, as the 
latter covers the former?  "Well, just make them admin!"  But what if it 
was the ADMIN and not the EDITOR role which was erroneously given?  
There's your security hole, borne from unnecessarily allowing multiple 
roles for a user.


The problem with allowing multiple roles to be assigned to a user is 
that while you think you've tightened up the security for a user by 
granting him just EDITOR, if he happens to still have ADMIN in the 
userrole table he remains an admin.  And we don't have the user 
interface that makes it clear if a user has multiple roles.


Another problem is that the above check 
"userManager.hasRole("admin",...)" is inaccurate because it is the 
permissions that comprise the role that matter (indeed, we allow users 
to create their own roles with whatever permissions attached.)  If you 
give admin permission to an EDITOR role or take away admin permission 
from the ADMIN role the call above is inaccurate.  We're supposed to be 
checking permissions, not roles--the role is just to be consulted to see 
which of the four permissions the user has.  You already have the level 
of indirection between permissions and a role allowing for convenient 
assignment of permissions to users, given that we have just 3-4 
permissions, multiple roles is unnecessary and a source of confusion and 
bugs.




3.) (I've brought this up before, but I think I had bad replacement

suggestions at the time.)  The titles of the three blog
permissions--LIMITED, AUTHOR, and ADMIN--may be harming Roller adoption in
companies

next ideas for Roller...

[Glen Mazza]

Hi Team,

For the next release of Roller, I have some suggestions that I think 
will increase adoption of Roller in corporate multi-blogger environments:


1.) I've brought this up before, but with 5.1 now out, I'd like to 
revisit it.  I'd like us to tighten up our security subsystem by moving 
from multiple roles per user to just a single role (presently ADMIN, 
EDITOR, or whatever custom role an integrator may choose to create.) 
Specifically the userrole table (lines 28-32 here: 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/resources/sql/createdb.vm?revision=1625869&view=markup) 
would be dropped, and the rolename column moved to the roller_user table.


Roller is not the Oracle RDBMS, we do not have nearly enough permissions 
(just 3 or so) to assign to those roles to warrant needing to store 
multiple roles with each user, and code needing to maintain and query 
multiple roles per user is much more confusing/complex and prone to 
security holes.  The current over-functional security architecture does 
not provide easy confidence to integrators that Roller is secure to use, 
harming adoption IMO.


By way of analogy, if you're crossing a stream via a footbridge very 
high up, you don't care about all the bells and whistles the footbridge 
has, you just want it to be clearly strong and solid, even if it's 
plain-looking, else you won't walk on it.  Excessive bells and whistles 
may be great with functionality but backfire with security as you lose 
confidence in the product's ability to accurately calculate the proper 
permissions for each user.


2.) Once that is done, it will be easier to determine who's an Admin, 
and we have JIRAs already to allow Admins to drop users as well as 
obtain email notifications of when users create or drop blogs.  I think 
blog admins would like this increased "driver's seat" functionality and 
it would make them more likely to adopt Roller within their company.


3.) (I've brought this up before, but I think I had bad replacement 
suggestions at the time.)  The titles of the three blog 
permissions--LIMITED, AUTHOR, and ADMIN--may be harming Roller adoption 
in companies.  The permissions they contain is not the problem, it's 
just their titles.  "LIMITED" can be taking as degrading to any user 
granted that role and if I were a boss I'd be concerned about getting 
two week notices from employees given that ranking.  "AUTHOR" has the 
problem in that the person with that role frequently isn't the author 
but just sanity-checking and publishing the blog article done by the 
person with the LIMITED role, further irritating the latter.  ADMIN is 
less polished a title for the blog owner, and it conflicts with the 
title we give the blog server administrator.


Perhaps we should switch to CONTRIBUTOR, PUBLISHER, and OWNER (or 
CO-OWNER)?  CONTRIBUTOR has no negative connotation and can fully imply 
authorship of the submitted blog articles.  PUBLISHER is win/win, not 
only is it a grander term than AUTHOR, at the same time it doesn't cause 
offense to the CONTRIBUTOR by implying authorship in those cases where 
the Publisher is just hitting the "Publish" button.  OWNER (CO-OWNER on 
the permissions assignment page) is a more polished term than ADMIN 
while at the same time reserving the latter term for those special 
people at the top, the blog server admins who choose to install Roller 
in their companies.


WDYT?

Regards,
Glen

Re: Shiro not Spring

[Glen Mazza]

I'm happy with Spring Security, it's easier to get volunteers to be 
willing to work with it as it's a more marketable skill as well get more 
integrators willing to adopt Roller into their environment as presumably 
they've used Spring elsewhere (or don't mind learning it themselves).  
That said, I suspect the Roller WAR would be trimmer switching from 
Spring to Shiro due to the latter's smaller JARs (is that the case?), 
also, the Shiro configuration style holds out the hope that it can 
someday be directly incorporated into the roller-custom.properties files 
without needing "WAR surgery" of opening up the WAR and modifying the 
security.xml file as we presently have to do with Spring.


At any rate, Shiro is an acceptable security solution, so I'm -0 on it.  
However, if you wish to switch to it, (1) LDAP[1] and Open ID (both open 
ID only and Dual open ID <-> password authentication) would need to be 
working prior to updating Roller with it, i.e., we should have the same 
basic capabilities with Shiro that we have with Spring Security (2) 
We'll need to update Roller's version to 5.2 as it's no longer a minor 
version release, (3) the comments in the current Spring security.xml 
explaining how to switch to LDAP or Open ID will need to carry over to 
the Shiro equivalent so people know how to get their LDAP or Open ID 
activated, and do a search in the Roller install guide's for 
"security.xml" and update it accordingly with Shiro info.


Glen

[1] https://cwiki.apache.org/confluence/display/ROLLER/Roller+5.1+with+LDAP

On 12/23/2014 05:56 PM, Dave wrote:

I'm learning about Apache Shiro, so I decided to see how hard it would be
to replace Spring Security in Roller with Shiro. It was a little painful,
but I eventually got it working. Shiro seems a lot easier to deal with, and
it allowed me to complete remove all Spring dependencies from my fork of
Roller.

You can see my DIFFs here:
https://github.com/snoopdave/rollarcus/compare/shiro_not_spring?expand=1

And the shiro.ini config file is here:
https://github.com/snoopdave/rollarcus/blob/shiro_not_spring/app/src/main/resources/shiro.ini

Most of the changes are removal of Spring specific code. However, my branch
does not support LDAP or OpenID yet, so I would expect that some Shiro
specific code would have to be added to enable those things.

I'm not convinced that Roller should switched to Shiro, but this is some
food for thought...

- Dave

Re: svn commit: r1642435 - /roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/MediaFileView.jsp

[Glen Mazza]

I could never figure out how to get those settings right.  :)  BTW, 
haven't forgotten the 5.1.1 bug to get mvn jetty:run working again (I 
updated to the latest Jetty without testing it first), still on my list.


Glen

On 11/29/2014 10:16 AM, snoopd...@apache.org wrote:

Author: snoopdave
Date: Sat Nov 29 15:16:20 2014
New Revision: 1642435

URL: http://svn.apache.org/r1642435
Log:
Restoring media title truncation at 47 characters to avoid having picture title 
overflow into adjacent cells of the media grid. Looks good on Firefox, Chome 
and Safari.

Modified:
 roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/MediaFileView.jsp

Modified: roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/MediaFileView.jsp
URL: 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/MediaFileView.jsp?rev=1642435&r1=1642434&r2=1642435&view=diff
==
--- roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/MediaFileView.jsp 
(original)
+++ roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/MediaFileView.jsp Sat 
Nov 29 15:16:20 2014
@@ -305,7 +305,7 @@
  
  
-

+
  
  
  

Re: About Apache Roller

[Glen Mazza]

Yes, we have an Apache Roller installation guide -- just look on our 
home page for the documentation download link.


Glen

On 11/11/2014 06:57 AM, Tarun Kumar Agrawal wrote:

Hello Sir,
I have my testing server which have apache tomcat as web server and mysql for 
database, but my application also have some blog(Discussion forum, 
Announcements ) functionality .
Can you help me in configuration of apache roller please elaborate me in 
details.
RegardsTarun Kumar AgrawalCo: 07756065022  09997985011  

Re: [ANNOUNCE] Apache Roller 5.1.1 released

[Glen Mazza]

Same with my smartphone.  Checking the Roller weblog's "weblog" 
template, I noticed the "mobile" tab is all blank, so that would 
probably account for the difficulties.  I would manually delete the 
"mobile" renditions in the custom_template_rendition table in all cases 
where you are not using a dual theme.  Try just on one blog at a time 
though.  :)


Glen

On 10/12/2014 06:39 PM, Dave wrote:

On Fri, Oct 3, 2014 at 6:52 AM, Glen Mazza  wrote:


As responded to earlier (albeit on the user thread), Dave's blog--the team
blog--is still running 5.1, not 5.1.1.  I can add blog entries, but don't
have control over updating the Roller version.  (Nor do I want that.)


Sorry about the delay.

I just upgraded the rollerweblogger.org site to latest 5.1.2-SNAPSHOT. It
seems to work fine on my desktop computer and my iPad, but the site does
not display pages on my iPhone. I'm going to take a closer look at my the
themes I have in place.

- Dave

Re: [ANNOUNCE] Apache Roller 5.1.1 released

[Glen Mazza]

As responded to earlier (albeit on the user thread), Dave's blog--the 
team blog--is still running 5.1, not 5.1.1.  I can add blog entries, but 
don't have control over updating the Roller version.  (Nor do I want that.)


Glen

On 10/03/2014 02:54 AM, Greg Huber wrote:

This is an entry?
http://rollerweblogger.org/project/entry/apache-roller-5-1-1, possibly this
webapp has not been updated to 5.1.1?

This should be fixed in 5.1.1.


On 2 October 2014 14:22, Matt Raible  wrote:


The link below renders as a blank page on my iPhone. Is this a known issue?




On Oct 1, 2014, at 22:03, Glen Mazza  wrote:

Blog article listing improvements over Version 5.1:

http://rollerweblogger.org/project/entry/apache-roller-5-1-1 .

It will take up to a half day though for all Apache mirrors to have this

new version available.

Regards,
Glen
Apache Roller Team

[ANNOUNCE] Apache Roller 5.1.1 released

[Glen Mazza]

Blog article listing improvements over Version 5.1: 
http://rollerweblogger.org/project/entry/apache-roller-5-1-1 .


It will take up to a half day though for all Apache mirrors to have this 
new version available.


Regards,
Glen
Apache Roller Team

Re: [VOTE RESUMED] Re: [VOTE] Release Roller 5.1.1

[Glen Mazza]

Perhaps we can add a warning on the stylesheet tab, just like we have on 
the templates tab, to back up your stylesheets before switching between 
custom and shared.


I wanted to make sure with that JIRA that when a user chooses shared 
theme X he gets shared theme X and not shared theme X looking funny 
because it's still using custom stylesheet Y.  Under the old system, if 
the user hit the stylesheet page after switching to a shared theme the 
old stylesheet gets activated causing the blog to look funny.


As a practical matter, those on custom rarely flip back to shared, 
because they already have their custom stuff they want in their custom 
theme.  Further, many/most of the custom themes provide an option of 
doing your stylesheet config on the templates tab and ignoring the 
custom stylesheet on the stylesheet tab (fauxcoly and gaurav for 
example), those would be saved between custom/shared switches.


Glen

On 09/30/2014 04:17 AM, Greg Huber wrote:

+1

The only thing is on ROL-2052
<https://issues.apache.org/jira/browse/ROL-2052> #2 switching back to a
shared theme now overwrites your custom style sheet without any warnings,
if you have not made a backup your changes will be lost.  Automatically
overwriting against having to manually delete it, the latter seems the
safest way.   Possibly add a warning message saying to delete your custom
style sheet?


On 30 September 2014 01:48, Glen Mazza  wrote:


I'll look into those issues for the current trunk but, absent any negative
votes for the next three hours, will go ahead and release Roller 5.1.1,
probably on Thursday.

Thanks,
Glen

On 09/29/2014 04:14 PM, Dave wrote:


I was able to download the release files, validate the signatures and run
the tests successfully. I did notice that there is a script "copy.sh" in
the root directory of the source release, that may have been committed
accidentally. Also, the "mvn jetty:run" command did start Roller properly
as it once did. I don't think either of those things should hold back the
release.

- Dave


On Fri, Sep 26, 2014 at 6:04 PM, Glen Mazza  wrote:

  OK, team, I'm happy to report that ROL-2051 has been fixed also for

custom
themes, so we're good to go to vote again.  The link below to the
distributions are the same, except they now have RC2 in them.

To test the blogs with mobile/tablet devices, try your own smartphone or
hit F12 from Google Chrome.  Some sample blogs using RC2:

http://web-gmazza.rhcloud.com/blog/
http://web-gmazza.rhcloud.com/frontpage/
http://web-gmazza.rhcloud.com/fauxcoly/
http://web-gmazza.rhcloud.com/testdual/
http://web-gmazza.rhcloud.com/gaurav/
http://web-gmazza.rhcloud.com/basic/

Here's my +1.  Vote will be held through the end of Monday Eastern USA
time.

Regards,
Glen


On 09/26/2014 09:12 AM, Glen Mazza wrote:

  Hi team, I think I've figured out the problem in ROL-2051, if the theme

is custom it will still have problems rendering on smart phones, shared
themes work fine now but custom still needs fixing. So I'll have to -1
this, fix the problem and get an RC2 out.   :(

Please be careful/conservative with any commits you make in the interim
as they will end up going into the upcoming Roller 5.1.1.

Glen

On 09/26/2014 09:04 AM, Glen Mazza wrote:

  Hi Team, this is a vote to release Roller 5.1.1.  Binaries and source

are here:

https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.1/

This patch release fixes the following problems:

https://issues.apache.org/jira/browse/ROL-1387";>ROL-
1387
- In creating tag aggregate counts (for tag clouds, etc.), count tags
only
from published blog entries
https://issues.apache.org/jira/browse/ROL-1620";>ROL-
1620
- Plus signs in Category names result in 404s for Atom and RSS
feeds
https://issues.apache.org/jira/browse/ROL-2050?
focusedCommentId=14116588&page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel#comment-
14116588">ROL-2050
- Have Design Tab default to Templates page when custom themes are
being
used (speeds up template customization)
https://issues.apache.org/jira/browse/ROL-2051";>ROL-
2051
- Themes not falling back to standard templates when mobile ones
undefined
(affecting ability for Roller to be read from tablets and
smartphones.)
https://issues.apache.org/jira/browse/ROL-2052";>ROL-
2052
- Custom stylesheets not being updated correctly when user switches
between
shared and custom themes.
https://issues.apache.org/jira/browse/ROL-2054";>ROL-
2054
- Newly saved categories not appearing on blog
https://issues.apache.org/jira/browse/ROL-2055";>ROL-
2055
- Comment search should be case-insensitive

For ROL-2051, I confirmed with my blog that all themes that ship with
Roller are working on smart phones, I tested using Google Chrome's
developer tools and my own smartphone.  However, my particular
non-packaged
theme (Rolling from Roller extras) is working on

Re: [VOTE RESUMED] Re: [VOTE] Release Roller 5.1.1

[Glen Mazza]

I'll look into those issues for the current trunk but, absent any 
negative votes for the next three hours, will go ahead and release 
Roller 5.1.1, probably on Thursday.


Thanks,
Glen

On 09/29/2014 04:14 PM, Dave wrote:

I was able to download the release files, validate the signatures and run
the tests successfully. I did notice that there is a script "copy.sh" in
the root directory of the source release, that may have been committed
accidentally. Also, the "mvn jetty:run" command did start Roller properly
as it once did. I don't think either of those things should hold back the
release.

- Dave


On Fri, Sep 26, 2014 at 6:04 PM, Glen Mazza  wrote:


OK, team, I'm happy to report that ROL-2051 has been fixed also for custom
themes, so we're good to go to vote again.  The link below to the
distributions are the same, except they now have RC2 in them.

To test the blogs with mobile/tablet devices, try your own smartphone or
hit F12 from Google Chrome.  Some sample blogs using RC2:

http://web-gmazza.rhcloud.com/blog/
http://web-gmazza.rhcloud.com/frontpage/
http://web-gmazza.rhcloud.com/fauxcoly/
http://web-gmazza.rhcloud.com/testdual/
http://web-gmazza.rhcloud.com/gaurav/
http://web-gmazza.rhcloud.com/basic/

Here's my +1.  Vote will be held through the end of Monday Eastern USA
time.

Regards,
Glen


On 09/26/2014 09:12 AM, Glen Mazza wrote:


Hi team, I think I've figured out the problem in ROL-2051, if the theme
is custom it will still have problems rendering on smart phones, shared
themes work fine now but custom still needs fixing. So I'll have to -1
this, fix the problem and get an RC2 out.   :(

Please be careful/conservative with any commits you make in the interim
as they will end up going into the upcoming Roller 5.1.1.

Glen

On 09/26/2014 09:04 AM, Glen Mazza wrote:


Hi Team, this is a vote to release Roller 5.1.1.  Binaries and source
are here:

https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.1/

This patch release fixes the following problems:

https://issues.apache.org/jira/browse/ROL-1387";>ROL-1387
- In creating tag aggregate counts (for tag clouds, etc.), count tags only
from published blog entries
https://issues.apache.org/jira/browse/ROL-1620";>ROL-1620
- Plus signs in Category names result in 404s for Atom and RSS feeds
https://issues.apache.org/jira/browse/ROL-2050?
focusedCommentId=14116588&page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel#comment-14116588">ROL-2050
- Have Design Tab default to Templates page when custom themes are being
used (speeds up template customization)
https://issues.apache.org/jira/browse/ROL-2051";>ROL-2051
- Themes not falling back to standard templates when mobile ones undefined
(affecting ability for Roller to be read from tablets and smartphones.)
https://issues.apache.org/jira/browse/ROL-2052";>ROL-2052
- Custom stylesheets not being updated correctly when user switches between
shared and custom themes.
https://issues.apache.org/jira/browse/ROL-2054";>ROL-2054
- Newly saved categories not appearing on blog
https://issues.apache.org/jira/browse/ROL-2055";>ROL-2055
- Comment search should be case-insensitive

For ROL-2051, I confirmed with my blog that all themes that ship with
Roller are working on smart phones, I tested using Google Chrome's
developer tools and my own smartphone.  However, my particular non-packaged
theme (Rolling from Roller extras) is working only off-and-on.  It may be
related to the theme's CSS rules, I haven't investigated.  What we have is
at least a radical improvement though over 5.1.0 when *none* of the themes
(except the dual theme, basic-mobile) were working on non-standard displays.

Dave, as mentioned in the preceding email, don't forget to update
rollerweblogger with "alter table weblog add defaultplugins varchar(255);"
to get you up to the official 5.1.0 database, 5.1.1 will not work without
that addition.

For the few upgrading from Roller 5.1.0 to 5.1.1, Roller is coded to ask
if you want to update your database tables, still hit "yes", it won't make
any changes because there are none coded, it will just upgrade your Roller
db version in the roller_properties table to "511".

Note I just copied over the documentation from the 5.1.0 to 5.1.1, as
it's undergone no changes.

Here's my +1.  Vote will be held for 72 hours.

Regards,
Glen

[VOTE RESUMED] Re: [VOTE] Release Roller 5.1.1

[Glen Mazza]

OK, team, I'm happy to report that ROL-2051 has been fixed also for 
custom themes, so we're good to go to vote again.  The link below to the 
distributions are the same, except they now have RC2 in them.


To test the blogs with mobile/tablet devices, try your own smartphone or 
hit F12 from Google Chrome.  Some sample blogs using RC2:


http://web-gmazza.rhcloud.com/blog/
http://web-gmazza.rhcloud.com/frontpage/
http://web-gmazza.rhcloud.com/fauxcoly/
http://web-gmazza.rhcloud.com/testdual/
http://web-gmazza.rhcloud.com/gaurav/
http://web-gmazza.rhcloud.com/basic/

Here's my +1.  Vote will be held through the end of Monday Eastern USA time.

Regards,
Glen

On 09/26/2014 09:12 AM, Glen Mazza wrote:
Hi team, I think I've figured out the problem in ROL-2051, if the 
theme is custom it will still have problems rendering on smart phones, 
shared themes work fine now but custom still needs fixing. So I'll 
have to -1 this, fix the problem and get an RC2 out.   :(


Please be careful/conservative with any commits you make in the 
interim as they will end up going into the upcoming Roller 5.1.1.


Glen

On 09/26/2014 09:04 AM, Glen Mazza wrote:
Hi Team, this is a vote to release Roller 5.1.1.  Binaries and source 
are here:


https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.1/

This patch release fixes the following problems:

href="https://issues.apache.org/jira/browse/ROL-1387";>ROL-1387 - 
In creating tag aggregate counts (for tag clouds, etc.), count tags 
only from published blog entries
href="https://issues.apache.org/jira/browse/ROL-1620";>ROL-1620 - 
Plus signs in Category names result in 404s for Atom and RSS feeds
href="https://issues.apache.org/jira/browse/ROL-2050?focusedCommentId=14116588&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14116588";>ROL-2050 
- Have Design Tab default to Templates page when custom themes are 
being used (speeds up template customization)
href="https://issues.apache.org/jira/browse/ROL-2051";>ROL-2051 - 
Themes not falling back to standard templates when mobile ones 
undefined (affecting ability for Roller to be read from tablets and 
smartphones.)
href="https://issues.apache.org/jira/browse/ROL-2052";>ROL-2052 - 
Custom stylesheets not being updated correctly when user switches 
between shared and custom themes.
href="https://issues.apache.org/jira/browse/ROL-2054";>ROL-2054 - 
Newly saved categories not appearing on blog
href="https://issues.apache.org/jira/browse/ROL-2055";>ROL-2055 - 
Comment search should be case-insensitive


For ROL-2051, I confirmed with my blog that all themes that ship with 
Roller are working on smart phones, I tested using Google Chrome's 
developer tools and my own smartphone.  However, my particular 
non-packaged theme (Rolling from Roller extras) is working only 
off-and-on.  It may be related to the theme's CSS rules, I haven't 
investigated.  What we have is at least a radical improvement though 
over 5.1.0 when *none* of the themes (except the dual theme, 
basic-mobile) were working on non-standard displays.


Dave, as mentioned in the preceding email, don't forget to update 
rollerweblogger with "alter table weblog add defaultplugins 
varchar(255);" to get you up to the official 5.1.0 database, 5.1.1 
will not work without that addition.


For the few upgrading from Roller 5.1.0 to 5.1.1, Roller is coded to 
ask if you want to update your database tables, still hit "yes", it 
won't make any changes because there are none coded, it will just 
upgrade your Roller db version in the roller_properties table to "511".


Note I just copied over the documentation from the 5.1.0 to 5.1.1, as 
it's undergone no changes.


Here's my +1.  Vote will be held for 72 hours.

Regards,
Glen

[FAILED...] Re: [VOTE] Release Roller 5.1.1

[Glen Mazza]

Hi team, I think I've figured out the problem in ROL-2051, if the theme 
is custom it will still have problems rendering on smart phones, shared 
themes work fine now but custom still needs fixing. So I'll have to -1 
this, fix the problem and get an RC2 out.   :(


Please be careful/conservative with any commits you make in the interim 
as they will end up going into the upcoming Roller 5.1.1.


Glen

On 09/26/2014 09:04 AM, Glen Mazza wrote:
Hi Team, this is a vote to release Roller 5.1.1.  Binaries and source 
are here:


https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.1/

This patch release fixes the following problems:

href="https://issues.apache.org/jira/browse/ROL-1387";>ROL-1387 - 
In creating tag aggregate counts (for tag clouds, etc.), count tags 
only from published blog entries
href="https://issues.apache.org/jira/browse/ROL-1620";>ROL-1620 - 
Plus signs in Category names result in 404s for Atom and RSS feeds
href="https://issues.apache.org/jira/browse/ROL-2050?focusedCommentId=14116588&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14116588";>ROL-2050 
- Have Design Tab default to Templates page when custom themes are 
being used (speeds up template customization)
href="https://issues.apache.org/jira/browse/ROL-2051";>ROL-2051 - 
Themes not falling back to standard templates when mobile ones 
undefined (affecting ability for Roller to be read from tablets and 
smartphones.)
href="https://issues.apache.org/jira/browse/ROL-2052";>ROL-2052 - 
Custom stylesheets not being updated correctly when user switches 
between shared and custom themes.
href="https://issues.apache.org/jira/browse/ROL-2054";>ROL-2054 - 
Newly saved categories not appearing on blog
href="https://issues.apache.org/jira/browse/ROL-2055";>ROL-2055 - 
Comment search should be case-insensitive


For ROL-2051, I confirmed with my blog that all themes that ship with 
Roller are working on smart phones, I tested using Google Chrome's 
developer tools and my own smartphone.  However, my particular 
non-packaged theme (Rolling from Roller extras) is working only 
off-and-on.  It may be related to the theme's CSS rules, I haven't 
investigated.  What we have is at least a radical improvement though 
over 5.1.0 when *none* of the themes (except the dual theme, 
basic-mobile) were working on non-standard displays.


Dave, as mentioned in the preceding email, don't forget to update 
rollerweblogger with "alter table weblog add defaultplugins 
varchar(255);" to get you up to the official 5.1.0 database, 5.1.1 
will not work without that addition.


For the few upgrading from Roller 5.1.0 to 5.1.1, Roller is coded to 
ask if you want to update your database tables, still hit "yes", it 
won't make any changes because there are none coded, it will just 
upgrade your Roller db version in the roller_properties table to "511".


Note I just copied over the documentation from the 5.1.0 to 5.1.1, as 
it's undergone no changes.


Here's my +1.  Vote will be held for 72 hours.

Regards,
Glen

[VOTE] Release Roller 5.1.1

[Glen Mazza]

Hi Team, this is a vote to release Roller 5.1.1.  Binaries and source 
are here:


https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.1/

This patch release fixes the following problems:

href="https://issues.apache.org/jira/browse/ROL-1387";>ROL-1387 - In 
creating tag aggregate counts (for tag clouds, etc.), count tags only 
from published blog entries
href="https://issues.apache.org/jira/browse/ROL-1620";>ROL-1620 - 
Plus signs in Category names result in 404s for Atom and RSS feeds
href="https://issues.apache.org/jira/browse/ROL-2050?focusedCommentId=14116588&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14116588";>ROL-2050 
- Have Design Tab default to Templates page when custom themes are being 
used (speeds up template customization)
href="https://issues.apache.org/jira/browse/ROL-2051";>ROL-2051 - 
Themes not falling back to standard templates when mobile ones undefined 
(affecting ability for Roller to be read from tablets and smartphones.)
href="https://issues.apache.org/jira/browse/ROL-2052";>ROL-2052 - 
Custom stylesheets not being updated correctly when user switches 
between shared and custom themes.
href="https://issues.apache.org/jira/browse/ROL-2054";>ROL-2054 - 
Newly saved categories not appearing on blog
href="https://issues.apache.org/jira/browse/ROL-2055";>ROL-2055 - 
Comment search should be case-insensitive


For ROL-2051, I confirmed with my blog that all themes that ship with 
Roller are working on smart phones, I tested using Google Chrome's 
developer tools and my own smartphone.  However, my particular 
non-packaged theme (Rolling from Roller extras) is working only 
off-and-on.  It may be related to the theme's CSS rules, I haven't 
investigated.  What we have is at least a radical improvement though 
over 5.1.0 when *none* of the themes (except the dual theme, 
basic-mobile) were working on non-standard displays.


Dave, as mentioned in the preceding email, don't forget to update 
rollerweblogger with "alter table weblog add defaultplugins 
varchar(255);" to get you up to the official 5.1.0 database, 5.1.1 will 
not work without that addition.


For the few upgrading from Roller 5.1.0 to 5.1.1, Roller is coded to ask 
if you want to update your database tables, still hit "yes", it won't 
make any changes because there are none coded, it will just upgrade your 
Roller db version in the roller_properties table to "511".


Note I just copied over the documentation from the 5.1.0 to 5.1.1, as 
it's undergone no changes.


Here's my +1.  Vote will be held for 72 hours.

Regards,
Glen

resuming... Re: build stalled...

[Glen Mazza]

Continuing testing, incidentally, Dave you'll need to make this change 
to your blog's database when upgrading to 5.1.1 as it was a last-second 
addition prior to releasing the official 5.1.0 (you're on the snapshot 
just before 5.1.0):


alter table weblog add defaultplugins varchar(255);

(This may be the problem I had with my OpenShift blog, still checking...)

Glen

On 09/25/2014 06:28 PM, Glen Mazza wrote:
I built Roller 5.1.1 with JDK 8, with the pom's compiler plugin 
configured to build with 1.7.  The build works fine on both JDK 7 and 
JDK 8, both Tomcat 7 and Tomcat 8 for me *locally* but for some reason 
it's not working when I try to host it on my OpenShift blog (which 
uses JDK 7 and Tomcat 7).  One difference might be that the OpenShift 
already has a 5.1.0 database on it, while the others start 5.1.1 with 
an empty DB.


5.1.1, when placed on a 5.1.0 instance, asks users if they want to 
upgrade database tables.  No tables are upgraded though (as expected 
as there is none to upgrade) but failures subsequently occur when 
trying to read the blog pages.  URL's that would show a blog page like 
https://web-gmazza.rhcloud.com/blog continually return 404s. However, 
links such as https://web-gmazza.rhcloud.com/roller-ui/login.rol that 
don't go to a blog page seem to work OK, but the subsequent page after 
a successful log in fails.  When I revert back to 5.1.0, everything's 
OK again.


I'm going to try a local install of 5.1.0, then try to upgrade to 
5.1.1, if that works I'll post the builds for others to evaluate. If 
that fails even locally, more work is needed...  :/


Glen

build stalled...

[Glen Mazza]

I built Roller 5.1.1 with JDK 8, with the pom's compiler plugin 
configured to build with 1.7.  The build works fine on both JDK 7 and 
JDK 8, both Tomcat 7 and Tomcat 8 for me *locally* but for some reason 
it's not working when I try to host it on my OpenShift blog (which uses 
JDK 7 and Tomcat 7).  One difference might be that the OpenShift already 
has a 5.1.0 database on it, while the others start 5.1.1 with an empty DB.


5.1.1, when placed on a 5.1.0 instance, asks users if they want to 
upgrade database tables.  No tables are upgraded though (as expected as 
there is none to upgrade) but failures subsequently occur when trying to 
read the blog pages.  URL's that would show a blog page like 
https://web-gmazza.rhcloud.com/blog continually return 404s. However, 
links such as https://web-gmazza.rhcloud.com/roller-ui/login.rol that 
don't go to a blog page seem to work OK, but the subsequent page after a 
successful log in fails.  When I revert back to 5.1.0, everything's OK 
again.


I'm going to try a local install of 5.1.0, then try to upgrade to 5.1.1, 
if that works I'll post the builds for others to evaluate. If that fails 
even locally, more work is needed...  :/


Glen

Re: Release Roller 5.1.1?

[Glen Mazza]

let
INFO  2014-09-25 13:04:28,253 WeblogPageCache: - {id=cache.weblogpage, 
enabled=true, timeout=3600, size=400}
INFO  2014-09-25 13:04:28,254 CacheManager: - Cache Manager Initialized.
INFO  2014-09-25 13:04:28,255 CacheManager: - Cache Factory = 
org.apache.roller.weblogger.util.cache.ExpiringLRUCacheFactoryImpl
INFO  2014-09-25 13:04:28,256 SiteWideCache: - {id=cache.sitewide, 
enabled=true, timeout=1800, size=50}
INFO  2014-09-25 13:04:28,256 PageServlet:init - Referrer spam check enabled = 
false
INFO  2014-09-25 13:04:28,257 FeedServlet:init - Initializing FeedServlet
INFO  2014-09-25 13:04:28,257 WeblogFeedCache: - {id=cache.weblogfeed, 
enabled=true, timeout=3600, size=200}
INFO  2014-09-25 13:04:28,257 ResourceServlet:init - Initializing 
ResourceServlet
INFO  2014-09-25 13:04:28,258 SearchServlet:init - Initializing SearchServlet
INFO  2014-09-25 13:04:28,258 MediaResourceServlet:init - Initializing 
ResourceServlet
INFO  2014-09-25 13:04:28,258 CommentServlet:init - Initializing CommentServlet
INFO  2014-09-25 13:04:28,264 CommentValidationManager: - Configured 
CommentValidator: Blacklist Comment Validator / 
org.apache.roller.weblogger.ui.rendering.plugins.comments.BlacklistCommentValidator
INFO  2014-09-25 13:04:28,265 CommentValidationManager: - Configured 
CommentValidator: Excess Links Comment Validator / 
org.apache.roller.weblogger.ui.rendering.plugins.comments.ExcessLinksCommentValidator
INFO  2014-09-25 13:04:28,265 CommentValidationManager: - Configured 
CommentValidator: Excess Size Comment Validator / 
org.apache.roller.weblogger.ui.rendering.plugins.comments.ExcessSizeCommentValidator
INFO  2014-09-25 13:04:28,265 CommentValidationManager: - Configured 3 
CommentValidators
INFO  2014-09-25 13:04:28,265 CommentServlet:init - Comment Throttling DISABLED
INFO  2014-09-25 13:04:28,266 CommentValidationManager: - Configured 
CommentValidator: Blacklist Comment Validator / 
org.apache.roller.weblogger.ui.rendering.plugins.comments.BlacklistCommentValidator
INFO  2014-09-25 13:04:28,266 CommentValidationManager: - Configured 
CommentValidator: Excess Links Comment Validator / 
org.apache.roller.weblogger.ui.rendering.plugins.comments.ExcessLinksCommentValidator
INFO  2014-09-25 13:04:28,266 CommentValidationManager: - Configured 
CommentValidator: Excess Size Comment Validator / 
org.apache.roller.weblogger.ui.rendering.plugins.comments.ExcessSizeCommentValidator
INFO  2014-09-25 13:04:28,266 CommentValidationManager: - Configured 3 
CommentValidators
INFO  2014-09-25 13:04:28,267 RSDServlet:init - Initializing RSDServlet
INFO  2014-09-25 13:04:28,267 PlanetFeedServlet:init - Initializing 
PlanetRssServlet
INFO  2014-09-25 13:04:28,267 PlanetCache: - Planet cache = 
{id=cache.planet, enabled=true, timeout=1800, size=10}
INFO  2014-09-25 13:04:28,268 PreviewResourceServlet:init - Initializing 
PreviewResourceServlet
INFO  2014-09-25 13:04:28,268 PreviewThemeImageServlet:init - Initializing 
PreviewThemeImageServlet
INFO  2014-09-25 13:04:28,268 PreviewServlet:init - Initializing PreviewServlet
INFO  2014-09-25 13:04:46,444 SaltCache: - {id=cache.salt, enabled=true, 
timeout=3600, size=5000}
WARN  2014-09-25 13:04:46,477 ThemeManagerImpl:getTheme - Unable to lookup 
theme darklight
ERROR 2014-09-25 13:04:46,477 PageServlet:doGet - Error getting default page 
for weblog = rd
java.lang.NullPointerException
at 
org.apache.roller.weblogger.ui.rendering.servlets.PageServlet.doGet(PageServlet.java:331)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)

On Sep 24, 2014, at 11:31 AM, Glen Mazza  wrote:


Your steps here seem prone to error:

1. Copy JARs (from WEB-INF/lib) to existing install (to upgrade
   dependencies)
2. Delete any lower-versioned JARS from WEB-INF/lib directory
3. Copy JSPs (from WEB-INF/jsps) to existing install

I would think you should just swap out the old WAR and put in the new one.  The 
libs between Roller 5.0.x and 5.1 are radically different.

For the log4j location issue, adding the log4j.appender.roller.File property to 
your roller-custom.properties file should take care of that.

Glen


On 09/24/2014 12:55 PM, Matt Raible wrote:

I'm fine with it. I tried upgrading my blog to 5.1 yesterday using the
steps I wrote down back in April.
http://raibledesigns.com/rd/entry/this_site_now_powered_by

The good news is it seems the database upgrade worked. After figuring out
that there's a whole slew of new stuff in WEB-INF/classes, I landed at the
following error:

SEVERE: Exception starting filter CompressionFilter
java.lang.ClassNotFoundException:
org.apache.roller.weblogger.ui.core.filters.CompressionFilter
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceMan

Code freeze...

[Glen Mazza]

Hi team, please avoid making commits right now.  I'm going to do a RC 
for 5.1.1 now.


Glen

Re: programming 101 question

[Glen Mazza]

I'll use JDK 7...

On 09/24/2014 01:11 PM, Glen Mazza wrote:
I recently added JDK 8.0 to my machine, so I have both JDK 7 and JDK 
8.  When creating a Roller build, does it matter which JDK I build it 
with?  I guess since 7 is the lowest version we support, to use that 
or it really doesn't matter?


Thanks,
Glen

Re: Release Roller 5.1.1?

[Glen Mazza]

Your steps here seem prone to error:

1. Copy JARs (from WEB-INF/lib) to existing install (to upgrade
   dependencies)
2. Delete any lower-versioned JARS from WEB-INF/lib directory
3. Copy JSPs (from WEB-INF/jsps) to existing install

I would think you should just swap out the old WAR and put in the new 
one.  The libs between Roller 5.0.x and 5.1 are radically different.


For the log4j location issue, adding the log4j.appender.roller.File 
property to your roller-custom.properties file should take care of that.


Glen


On 09/24/2014 12:55 PM, Matt Raible wrote:

I'm fine with it. I tried upgrading my blog to 5.1 yesterday using the
steps I wrote down back in April.
http://raibledesigns.com/rd/entry/this_site_now_powered_by

The good news is it seems the database upgrade worked. After figuring out
that there's a whole slew of new stuff in WEB-INF/classes, I landed at the
following error:

SEVERE: Exception starting filter CompressionFilter
java.lang.ClassNotFoundException:
org.apache.roller.weblogger.ui.core.filters.CompressionFilter
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:530)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:512)

I was using this for Gzip compression. Is it still available? If not, I can
use wro4j.

 
 CompressionFilter

org.apache.roller.weblogger.ui.core.filters.CompressionFilter
 

Next, I received the following error:

java.io.FileNotFoundException:
/work/underthehood/apache-tomcat-7.0.50/logs/roller.log (No such file or
directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.(FileOutputStream.java:221)
at java.io.FileOutputStream.(FileOutputStream.java:142)
at org.apache.log4j.FileAppender.setFile(FileAppender.java:294)

Where do I change the path for log4j?

Everything seems to startup OK, but when I go to localhost:8080, I get a
page not found. Any ideas?

Thanks,

Matt

On Mon, Sep 22, 2014 at 8:01 PM, Glen Mazza  wrote:


Hi Team, I want to start a build soon for Roller 5.1.1.  It will take care
of the following problems:


https://issues.apache.org/jira/browse/ROL-2050?
focusedCommentId=14116588&page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel#comment-14116588">ROL-2050
- Have Design Tab default to Templates page when custom themes are being
used (speeds up template customization)
https://issues.apache.org/jira/browse/ROL-2051";>ROL-2051
- Themes not falling back to standard templates when mobile ones undefined
(affecting ability for Roller to be read from tablets and smartphones.)
https://issues.apache.org/jira/browse/ROL-2052";>ROL-2052
- Custom stylesheets not being updated correctly when user switches between
shared and custom themes.
https://issues.apache.org/jira/browse/ROL-2054";>ROL-2054
- Newly saved categories not appearing on blog
https://issues.apache.org/jira/browse/ROL-1620";>ROL-1620
- Plus signs in Category names result in 404s for Atom and RSS feeds
https://issues.apache.org/jira/browse/ROL-1387";>ROL-1387
- In creating tag aggregate counts (for tag clouds, etc.), count tags only
from published blog entries


Any objections or last-minute additions people want to put in?

Thanks,
Glen

programming 101 question

[Glen Mazza]

I recently added JDK 8.0 to my machine, so I have both JDK 7 and JDK 8.  
When creating a Roller build, does it matter which JDK I build it with?  
I guess since 7 is the lowest version we support, to use that or it 
really doesn't matter?


Thanks,
Glen

Release Roller 5.1.1?

[Glen Mazza]

Hi Team, I want to start a build soon for Roller 5.1.1.  It will take 
care of the following problems:



href="https://issues.apache.org/jira/browse/ROL-2050?focusedCommentId=14116588&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14116588";>ROL-2050 
- Have Design Tab default to Templates page when custom themes are being 
used (speeds up template customization)
href="https://issues.apache.org/jira/browse/ROL-2051";>ROL-2051 - 
Themes not falling back to standard templates when mobile ones undefined 
(affecting ability for Roller to be read from tablets and smartphones.)
href="https://issues.apache.org/jira/browse/ROL-2052";>ROL-2052 - 
Custom stylesheets not being updated correctly when user switches 
between shared and custom themes.
href="https://issues.apache.org/jira/browse/ROL-2054";>ROL-2054 - 
Newly saved categories not appearing on blog
href="https://issues.apache.org/jira/browse/ROL-1620";>ROL-1620 - 
Plus signs in Category names result in 404s for Atom and RSS feeds
href="https://issues.apache.org/jira/browse/ROL-1387";>ROL-1387 - In 
creating tag aggregate counts (for tag clouds, etc.), count tags only 
from published blog entries



Any objections or last-minute additions people want to put in?

Thanks,
Glen

Re: blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

If a cookie replacement option is too time-consuming or hacky to 
implement, perhaps it would be better for us not to make the perfect the 
enemy of the good, i.e., have Greg go ahead and update the device 
detection info even if we lose the cookie stuff.  Perhaps 90% of all 
blogs are going to be just single (responsive) rendition anyway, cookies 
would benefit only that subset of the 10% where mobile is not the best 
template for a tablet.


I'd like to get 5.1.1 out relatively soon, as Roller's 5.1.0's inability 
to work with tablets and smartphones OOTB is very harmful for its 
adoption.  Although I've already patched that problem by having mobile 
requests go to standard if mobile not provided, additionally getting the 
device detection list updated to Spring Mobile's latest and greatest as 
part of this release would be very good for Roller and helpful for 
integrators.  Greg at his leisure can later do the SaltCache stuff after 
5.1.1 if he wishes.


Some other ideas we could consider instead of SaltCache-based solutions 
(of which I don't really understand but am not too concerned about it), 
most probably post 5.1.1:


1.) Add a new type to RenditionType, TABLET, allowing the blogger to 
configure whatever he or she thinks is best for tablets in his 
theme.xml, still defaulting back to MOBILE, and from there, STANDARD, if 
a tablet rendition isn't provided.  Possibly also, create a top-level 
tabletDefault property in the theme.xml (or configured in user settings 
at the weblog level, so it will work with custom themes also), with 
accepted values of STANDARD or MOBILE, in which the blog writer 
specifies which rendition he wants used if the device is detected to be 
a tablet and he or she doesn't wish to manually configure tablet renditions.


2.) Twitter does not provide a standard/mobile button but just separate 
URLs for the user to choose from: m.twitter.com and www.twitter.com. 
What we could do is provide the user an ability to create a second 
(mobile) handle when creating the blog that will use the mobile 
renditions defined for that theme, if any.  That way the blog reader can 
choose whichever theme desired by his choice of URL.


Cheers,
Glen

On 09/07/2014 02:29 AM, Greg Huber wrote:

ok, will look into a more reliable method of remembering the device type,
the request attribute is not good.  Possibly use something like the
SaltCache to store the value via the ip address eg 127.0.0.1 == standard.
Kind of how spring does it.

Cheers Greg.


On 5 September 2014 14:29, Dave  wrote:


On Fri, Sep 5, 2014 at 3:18 AM, Greg Huber  wrote:


Ok, will look into the integration / documentation.

Can we drop the cookie switching?  Although nice to have, switch manually
from standard to mobile is too troublesome to get working reliably, and

it

was not easy to adopt the spring logic to control this (I may have

another

look at the spring code to see if it is possible, think it uses too much

of

spring, annotation stuff, from what I remember).  Its better to use an
agent switcher for development/viewing.

Cheers Greg

That's a *very* nice to have feature. I hate it when I'm stuck in a limited
"mobile" version of a website when my tablet's screen is more than enough
for the regular version of the site.

- Dave

Re: blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

But please, update the license headers in the interim on those files you 
added...   ;-)


Glen

On 09/07/2014 05:29 AM, Greg Huber wrote:

ok, will look into a more reliable method of remembering the device type,
the request attribute is not good.  Possibly use something like the
SaltCache to store the value via the ip address eg 127.0.0.1 == standard.
Kind of how spring does it.

Cheers Greg.


On 5 September 2014 14:29, Dave  wrote:


On Fri, Sep 5, 2014 at 3:18 AM, Greg Huber  wrote:


Ok, will look into the integration / documentation.

Can we drop the cookie switching?  Although nice to have, switch manually
from standard to mobile is too troublesome to get working reliably, and

it

was not easy to adopt the spring logic to control this (I may have

another

look at the spring code to see if it is possible, think it uses too much

of

spring, annotation stuff, from what I remember).  Its better to use an
agent switcher for development/viewing.

Cheers Greg



That's a *very* nice to have feature. I hate it when I'm stuck in a limited
"mobile" version of a website when my tablet's screen is more than enough
for the regular version of the site.






- Dave

Re: blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

If you're asking to remove the functionality that powers the "switch to 
mobile" and "switch to standard" buttons on the basic and mobile parts 
of the basic-mobile theme, I would say they aren't vital, if you 
wouldn't mind pulling out the buttons in the basic-mobile theme if they 
become unusable as a result.


Google Chrome offers a developer tools view where people can view and 
test the mobile theme from the laptop browser, so people can get to the 
mobile theme that way.


Glen

On 09/05/2014 03:18 AM, Greg Huber wrote:

Ok, will look into the integration / documentation.

Can we drop the cookie switching?  Although nice to have, switch manually
from standard to mobile is too troublesome to get working reliably, and it
was not easy to adopt the spring logic to control this (I may have another
look at the spring code to see if it is possible, think it uses too much of
spring, annotation stuff, from what I remember).  Its better to use an
agent switcher for development/viewing.

Cheers Greg


On 4 September 2014 09:56, Glen Mazza  wrote:


OK, please make the license changes needed as mentioned in the other email
though.  If your change is such that a tablet gets treated as a mobile,
then we're fine, as Roller won't blow up OOTB if it evaluates a device to
be a tablet.

Afterwards, if you wish to expand StylesheetEdit and TemplateEdit, as well
as the parser for theme.xml to support tablets separately, that's your
choice--I don't have that itch to scratch myself though as it seems a bit
overkill right now.

Thanks for this change -- as you note, it's easy for us to update and
gives us the opportunity to support tablets separately in the future should
we go that route.

Glen

On 09/04/2014 02:24 AM, Greg Huber wrote:


We will need to check with the original committer where the code came
from.  I could not find anything similar so rather than not be "supported"
I switched locally to a spring based solution.  It also is far superior
code than was previously supplied.

The tablet renders currently as a mobile, which we can change if needed to
render normal.

Cheers Greg


On 3 September 2014 14:41, Glen Mazza  wrote:

  I'm not comfortable with this change at the present, I think it is too

soon for us to move to three device support (now including tablets) and
not
a good allocation of resources, at a time that multiple device checking
is
nicely going out the window due to responsive themes and usage of media
queries.   What we presently have, i.e., check for "Mobile" in the UA
string, then check a device listing, and then fallback to standard theme
if
mobile unavailable will work for the vast majority of blogs today.  And
such simplicity saves us time, allowing us to add more important features
that grab more bloggers than we'd lose by not separately supporting
tablets. Three-device support is going to require code changes throughout
the system to support, it's not just bringing in these few classes.

I was hoping we could just update our list of devices we presently have
and just go with that--update one file alone.  (Where did that original
source come from?)  There are many sources for this information, even
JQuery will probably work because it's MIT-licensed.  Let's consider
whether we need three-device support later, once we get user demand for
it
(and your solution looks fine for it), but I'd rather we not be
maintaining
something that our present user base isn't asking for.

Glen

On 09/03/2014 03:14 AM, Greg Huber wrote:

  Checking the spring-mobile license it uses

http://www.apache.org/licenses/LICENSE-2.0.

So it looks ok to use, I will add a version which uses
DeviceResolverRequestFilter and LiteDeviceResolver to determine the
browser
type (also its easily maintained by spring! ;) ) and which we can easily
switch to.

I have added the code Committed revision 1622172.  If it is OK I will
update roller accordingly.

Cheers Greg



On 2 September 2014 10:57, Glen Mazza  wrote:

   No, we still support multiple renditions (i.e., basic-mobile) to be


defined if that's what the blogger wants, for single-rendition the
blogger
can use either a responsive theme or even a non-responsive one (my
smartphone just shrinks the image if it's non responsive, I can enlarge
it
and view chunks of the blog page.)

The older code, if there was just the standard rendition defined, would
make a copy of it and make the copy the mobile rendition, requiring the
theme user to have to maintain two sets of templates even if they were
desired to stay identical (e.g., a responsive theme).  When I took that
out
-- no copies unless two renditions are defined in the theme.xml -- I
apparently didn't get the code right for the standard theme to be the
default one.  I'll get it fixed.

As for the "browser user agent", I'm not sure if that "deviceType"
parameter is someth

remove usercookie table?

[Glen Mazza]

Hi Team, we have a table called "usercookie" in our data model, but a 
search of the Roller source code is showing that we're not using it 
anywhere.  Any objections if I get rid of it?


Thanks,
Glen

Re: blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

OK, please make the license changes needed as mentioned in the other 
email though.  If your change is such that a tablet gets treated as a 
mobile, then we're fine, as Roller won't blow up OOTB if it evaluates a 
device to be a tablet.


Afterwards, if you wish to expand StylesheetEdit and TemplateEdit, as 
well as the parser for theme.xml to support tablets separately, that's 
your choice--I don't have that itch to scratch myself though as it seems 
a bit overkill right now.


Thanks for this change -- as you note, it's easy for us to update and 
gives us the opportunity to support tablets separately in the future 
should we go that route.


Glen

On 09/04/2014 02:24 AM, Greg Huber wrote:

We will need to check with the original committer where the code came
from.  I could not find anything similar so rather than not be "supported"
I switched locally to a spring based solution.  It also is far superior
code than was previously supplied.

The tablet renders currently as a mobile, which we can change if needed to
render normal.

Cheers Greg


On 3 September 2014 14:41, Glen Mazza  wrote:


I'm not comfortable with this change at the present, I think it is too
soon for us to move to three device support (now including tablets) and not
a good allocation of resources, at a time that multiple device checking is
nicely going out the window due to responsive themes and usage of media
queries.   What we presently have, i.e., check for "Mobile" in the UA
string, then check a device listing, and then fallback to standard theme if
mobile unavailable will work for the vast majority of blogs today.  And
such simplicity saves us time, allowing us to add more important features
that grab more bloggers than we'd lose by not separately supporting
tablets. Three-device support is going to require code changes throughout
the system to support, it's not just bringing in these few classes.

I was hoping we could just update our list of devices we presently have
and just go with that--update one file alone.  (Where did that original
source come from?)  There are many sources for this information, even
JQuery will probably work because it's MIT-licensed.  Let's consider
whether we need three-device support later, once we get user demand for it
(and your solution looks fine for it), but I'd rather we not be maintaining
something that our present user base isn't asking for.

Glen

On 09/03/2014 03:14 AM, Greg Huber wrote:


Checking the spring-mobile license it uses
http://www.apache.org/licenses/LICENSE-2.0.

So it looks ok to use, I will add a version which uses
DeviceResolverRequestFilter and LiteDeviceResolver to determine the
browser
type (also its easily maintained by spring! ;) ) and which we can easily
switch to.

I have added the code Committed revision 1622172.  If it is OK I will
update roller accordingly.

Cheers Greg



On 2 September 2014 10:57, Glen Mazza  wrote:

  No, we still support multiple renditions (i.e., basic-mobile) to be

defined if that's what the blogger wants, for single-rendition the
blogger
can use either a responsive theme or even a non-responsive one (my
smartphone just shrinks the image if it's non responsive, I can enlarge
it
and view chunks of the blog page.)

The older code, if there was just the standard rendition defined, would
make a copy of it and make the copy the mobile rendition, requiring the
theme user to have to maintain two sets of templates even if they were
desired to stay identical (e.g., a responsive theme).  When I took that
out
-- no copies unless two renditions are defined in the theme.xml -- I
apparently didn't get the code right for the standard theme to be the
default one.  I'll get it fixed.

As for the "browser user agent", I'm not sure if that "deviceType"
parameter is something that a Roller page creates once in a browser or
something all browsers supply regardless of the website that they are on,
Googling isn't bringing up much on that parameter so I'm assuming the
former.  I'm pretty much new to this particular topic.

Glen

On 09/02/2014 02:45 AM, Greg Huber wrote:

  If there is no "mobile" on the theme.xml for the theme it used to show

the
default, so maybe something has changed.

The browser user agent is used to determine if its a mobile device.
What
I
do is to use the jquery mobile logic i.e. LiteDeviceResolver, I can
update
roller but am not sure on the licensing etc on copying jquery code.  As
you
mentioned previously the preferred method now would be to use a
responsive
design, rather than a separate theme, so this is kind of parked?

Cheers Greg


On 2 September 2014 01:49, Glen Mazza  wrote:

   Hi Team, I noticed today with Roller 5.1 the blogs are not rendering
on


smartphones (at least mine, I have a Windows 8 smartphone that uses IE
as
its browser) except for the combo basic-mobile theme, the only one

Re: svn commit: r1622172 - in /roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering: filters/ util/mobile/

[Glen Mazza]

Hi Greg, have to veto this change.  You have to do 4(b) and 4(d) of here 
to bring the code in: http://www.apache.org/licenses/LICENSE-2.0


4(b) just below the license header add something like "Code from Spring 
Mobile modified by use in Apache Roller"  This also helps Roller coders 
so we know where the code came from, where we need to research for more 
info, etc., that it is not our own.


4(d) add this blurb to our NOTICE file: 
https://github.com/spring-projects/spring-mobile/blob/master/NOTICE. 
Also, add the version.txt to the NOTICE file (it needs to be updated 
when we update the NOTICE file anyway) so we don't need version.txt anymore.


Regards,
Glen


On 09/03/2014 03:13 AM, ghu...@apache.org wrote:

Author: ghuber
Date: Wed Sep  3 07:13:17 2014
New Revision: 1622172

URL:http://svn.apache.org/r1622172
Log:
Alternate device type resolution for mobile themes

Added:
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/filters/DeviceResolverRequestFilter.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/Device.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/DeviceResolver.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/DeviceType.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/DeviceUtils.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/LiteDevice.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/LiteDeviceResolver.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/MobileDeviceRepository.java
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/util/mobile/version.txt

Added: 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/filters/DeviceResolverRequestFilter.java
URL:http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/filters/DeviceResolverRequestFilter.java?rev=1622172&view=auto
==
--- 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/filters/DeviceResolverRequestFilter.java
 (added)
+++ 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/filters/DeviceResolverRequestFilter.java
 Wed Sep  3 07:13:17 2014
@@ -0,0 +1,83 @@
+/*
+ * Copyright 2010-2014 the original author or authors.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.roller.weblogger.ui.rendering.filters;
+
+import java.io.IOException;
+
+import javax.servlet.Filter;
+import javax.servlet.FilterChain;
+import javax.servlet.ServletException;
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpServletResponse;
+
+import org.apache.roller.weblogger.ui.rendering.util.mobile.Device;
+import org.apache.roller.weblogger.ui.rendering.util.mobile.DeviceResolver;
+import org.apache.roller.weblogger.ui.rendering.util.mobile.DeviceUtils;
+import org.apache.roller.weblogger.ui.rendering.util.mobile.LiteDeviceResolver;
+import org.springframework.web.filter.OncePerRequestFilter;
+
+/**
+ * A Servlet 2.3 Filter that resolves the Device that originated the web
+ * request. The resolved Device is exported as a request attribute under the
+ * well-known name of {@link DeviceUtils#CURRENT_DEVICE_ATTRIBUTE}. Request
+ * handlers such as @Controllers and views may then access the currentDevice to
+ * vary their control and rendering logic, respectively.
+ *
+ *  
+ * DeviceResolverRequestFilter
+ * org.apache
+ * .roller.weblogger.ui.rendering.filters.DeviceResolverRequestFilter
+ *  
+ *
+ *  
+ * DeviceResolverRequestFilter
+ * /* REQUEST
+ * 
+ *
+ * @author Roy Clarkson
+ */
+public class DeviceResolverRequestFilter extends OncePerRequestFilter {
+
+private final DeviceResolver deviceResolver;
+
+/**
+ * Create a device resolving {@link Filter} that defaults to a
+ * {@link LiteDeviceResolver} implementation.
+ */
+public DeviceResolverRequestFilter() {
+this(new LiteDeviceResolver());
+}
+
+/**
+ * Create a device resolving {@link Filter}.
+ *
+ * @param deviceResolver
+ *the device

Re: blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

I'm not comfortable with this change at the present, I think it is too 
soon for us to move to three device support (now including tablets) and 
not a good allocation of resources, at a time that multiple device 
checking is nicely going out the window due to responsive themes and 
usage of media queries.   What we presently have, i.e., check for 
"Mobile" in the UA string, then check a device listing, and then 
fallback to standard theme if mobile unavailable will work for the vast 
majority of blogs today.  And such simplicity saves us time, allowing us 
to add more important features that grab more bloggers than we'd lose by 
not separately supporting tablets. Three-device support is going to 
require code changes throughout the system to support, it's not just 
bringing in these few classes.


I was hoping we could just update our list of devices we presently have 
and just go with that--update one file alone.  (Where did that original 
source come from?)  There are many sources for this information, even 
JQuery will probably work because it's MIT-licensed.  Let's consider 
whether we need three-device support later, once we get user demand for 
it (and your solution looks fine for it), but I'd rather we not be 
maintaining something that our present user base isn't asking for.


Glen

On 09/03/2014 03:14 AM, Greg Huber wrote:

Checking the spring-mobile license it uses
http://www.apache.org/licenses/LICENSE-2.0.

So it looks ok to use, I will add a version which uses
DeviceResolverRequestFilter and LiteDeviceResolver to determine the browser
type (also its easily maintained by spring! ;) ) and which we can easily
switch to.

I have added the code Committed revision 1622172.  If it is OK I will
update roller accordingly.

Cheers Greg



On 2 September 2014 10:57, Glen Mazza  wrote:


No, we still support multiple renditions (i.e., basic-mobile) to be
defined if that's what the blogger wants, for single-rendition the blogger
can use either a responsive theme or even a non-responsive one (my
smartphone just shrinks the image if it's non responsive, I can enlarge it
and view chunks of the blog page.)

The older code, if there was just the standard rendition defined, would
make a copy of it and make the copy the mobile rendition, requiring the
theme user to have to maintain two sets of templates even if they were
desired to stay identical (e.g., a responsive theme).  When I took that out
-- no copies unless two renditions are defined in the theme.xml -- I
apparently didn't get the code right for the standard theme to be the
default one.  I'll get it fixed.

As for the "browser user agent", I'm not sure if that "deviceType"
parameter is something that a Roller page creates once in a browser or
something all browsers supply regardless of the website that they are on,
Googling isn't bringing up much on that parameter so I'm assuming the
former.  I'm pretty much new to this particular topic.

Glen

On 09/02/2014 02:45 AM, Greg Huber wrote:


If there is no "mobile" on the theme.xml for the theme it used to show the
default, so maybe something has changed.

The browser user agent is used to determine if its a mobile device.  What
I
do is to use the jquery mobile logic i.e. LiteDeviceResolver, I can update
roller but am not sure on the licensing etc on copying jquery code.  As
you
mentioned previously the preferred method now would be to use a responsive
design, rather than a separate theme, so this is kind of parked?

Cheers Greg


On 2 September 2014 01:49, Glen Mazza  wrote:

  Hi Team, I noticed today with Roller 5.1 the blogs are not rendering on

smartphones (at least mine, I have a Windows 8 smartphone that uses IE as
its browser) except for the combo basic-mobile theme, the only one that
provides explicit "mobile" rendition types.  For the others, Roller just
returns a blank screen or a 404 or similar error page.  To test, for my
website I created 5 empty blogs, one for each theme we offer:

https://web-gmazza.rhcloud.com/frontpage/
https://web-gmazza.rhcloud.com/gaurav/
https://web-gmazza.rhcloud.com/testdual/(basic-mobile).
https://web-gmazza.rhcloud.com/frontpage/
https://web-gmazza.rhcloud.com/fauxcoly/

What I would like to have Roller do -- and I had incorrectly assumed was
already being done -- was for Roller to fall back to the "standard"
rendition type when the "mobile" rendition was not available, correct
anyway if you're using a responsive theme. Searching through the code I
think the only change I need to do is in class RollerVelocity[1], for
those
getTemplate() methods that take a deviceType parameter, to attempt to get
the standard rendition type as a fallback if the mobile deviceType was
requested and is not available.  I'll test it.  Until a Roller 5.1.1 is
out, users should be able to duplicate renditions in their theme.xml,

Re: blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

No, we still support multiple renditions (i.e., basic-mobile) to be 
defined if that's what the blogger wants, for single-rendition the 
blogger can use either a responsive theme or even a non-responsive one 
(my smartphone just shrinks the image if it's non responsive, I can 
enlarge it and view chunks of the blog page.)


The older code, if there was just the standard rendition defined, would 
make a copy of it and make the copy the mobile rendition, requiring the 
theme user to have to maintain two sets of templates even if they were 
desired to stay identical (e.g., a responsive theme).  When I took that 
out -- no copies unless two renditions are defined in the theme.xml -- I 
apparently didn't get the code right for the standard theme to be the 
default one.  I'll get it fixed.


As for the "browser user agent", I'm not sure if that "deviceType" 
parameter is something that a Roller page creates once in a browser or 
something all browsers supply regardless of the website that they are 
on, Googling isn't bringing up much on that parameter so I'm assuming 
the former.  I'm pretty much new to this particular topic.


Glen

On 09/02/2014 02:45 AM, Greg Huber wrote:

If there is no "mobile" on the theme.xml for the theme it used to show the
default, so maybe something has changed.

The browser user agent is used to determine if its a mobile device.  What I
do is to use the jquery mobile logic i.e. LiteDeviceResolver, I can update
roller but am not sure on the licensing etc on copying jquery code.  As you
mentioned previously the preferred method now would be to use a responsive
design, rather than a separate theme, so this is kind of parked?

Cheers Greg


On 2 September 2014 01:49, Glen Mazza  wrote:


Hi Team, I noticed today with Roller 5.1 the blogs are not rendering on
smartphones (at least mine, I have a Windows 8 smartphone that uses IE as
its browser) except for the combo basic-mobile theme, the only one that
provides explicit "mobile" rendition types.  For the others, Roller just
returns a blank screen or a 404 or similar error page.  To test, for my
website I created 5 empty blogs, one for each theme we offer:

https://web-gmazza.rhcloud.com/frontpage/
https://web-gmazza.rhcloud.com/gaurav/
https://web-gmazza.rhcloud.com/testdual/   (basic-mobile).
https://web-gmazza.rhcloud.com/frontpage/
https://web-gmazza.rhcloud.com/fauxcoly/

What I would like to have Roller do -- and I had incorrectly assumed was
already being done -- was for Roller to fall back to the "standard"
rendition type when the "mobile" rendition was not available, correct
anyway if you're using a responsive theme. Searching through the code I
think the only change I need to do is in class RollerVelocity[1], for those
getTemplate() methods that take a deviceType parameter, to attempt to get
the standard rendition type as a fallback if the mobile deviceType was
requested and is not available.  I'll test it.  Until a Roller 5.1.1 is
out, users should be able to duplicate renditions in their theme.xml,
defining the standard one as also the mobile one.

Couple of other concerns, in our MobileDeviceRepository class, our device
listing[2] used as a backup to determine if mobile is necessary may be
out-of-date, I think I can Google something more recent.  Also, just to
confirm, line #88 of that same file, checks the user agent "deviceType"
parameter for "standard" or "mobile" to determine the type, but that
parameter is not normally sent by a browser, correct?

Regards,
Glen

[1] http://svn.apache.org/viewvc/roller/trunk/app/src/main/
java/org/apache/roller/weblogger/ui/rendering/
velocity/RollerVelocity.java?revision=1583506&view=markup#l96
[2] http://svn.apache.org/viewvc/roller/trunk/app/src/main/
java/org/apache/roller/weblogger/ui/rendering/mobile/
MobileDeviceRepository.java?revision=1611764&view=markup#l34

blogs using single-rendition themes not showing on smartphones

[Glen Mazza]

Hi Team, I noticed today with Roller 5.1 the blogs are not rendering on 
smartphones (at least mine, I have a Windows 8 smartphone that uses IE 
as its browser) except for the combo basic-mobile theme, the only one 
that provides explicit "mobile" rendition types.  For the others, Roller 
just returns a blank screen or a 404 or similar error page.  To test, 
for my website I created 5 empty blogs, one for each theme we offer:


https://web-gmazza.rhcloud.com/frontpage/
https://web-gmazza.rhcloud.com/gaurav/
https://web-gmazza.rhcloud.com/testdual/   (basic-mobile).
https://web-gmazza.rhcloud.com/frontpage/
https://web-gmazza.rhcloud.com/fauxcoly/

What I would like to have Roller do -- and I had incorrectly assumed was 
already being done -- was for Roller to fall back to the "standard" 
rendition type when the "mobile" rendition was not available, correct 
anyway if you're using a responsive theme. Searching through the code I 
think the only change I need to do is in class RollerVelocity[1], for 
those getTemplate() methods that take a deviceType parameter, to attempt 
to get the standard rendition type as a fallback if the mobile 
deviceType was requested and is not available.  I'll test it.  Until a 
Roller 5.1.1 is out, users should be able to duplicate renditions in 
their theme.xml, defining the standard one as also the mobile one.


Couple of other concerns, in our MobileDeviceRepository class, our 
device listing[2] used as a backup to determine if mobile is necessary 
may be out-of-date, I think I can Google something more recent.  Also, 
just to confirm, line #88 of that same file, checks the user agent 
"deviceType" parameter for "standard" or "mobile" to determine the type, 
but that parameter is not normally sent by a browser, correct?


Regards,
Glen

[1] 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/velocity/RollerVelocity.java?revision=1583506&view=markup#l96
[2] 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/rendering/mobile/MobileDeviceRepository.java?revision=1611764&view=markup#l34

[ANNOUNCE] Apache Roller 5.1 Released

[Glen Mazza]

Hi all, Apache Roller 5.1 is now available.  Our JIRA lists 113 closed 
issues with this release 
(https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310906&version=12317621), 
perhaps about as many others were also fixed without a JIRA report to them.


It is primarily an internal architecture update, with seldom-used or 
obsolete functionality and code pulled out of Roller to make the 
application more streamlined and maintainable.  We also upgraded 
virtually all of Roller's dependencies, either removing them or updating 
them to the latest available.  We also upgraded and simplified the Maven 
build process.  While providing the same basic functionality, Roller 5.1 
is a considerably leaner application that builds in roughly a quarter of 
the time than the 5.0.x series.


The themes in Roller-extras 
(https://code.google.com/a/apache-extras.org/p/roller-extras/wiki/Themes) that 
you can add to your Roller installation have also been updated to Roller 
5.1 compatibility.


The downloads are available here: 
http://roller.apache.org/downloads/downloads.html, and instructions on 
upgrading from earlier versions of Roller to the latest are in the 
Roller Install Guide.  IMPORTANT: For those upgrading their Roller 
instances, be sure to back up your current Roller database prior to 
doing the upgrade in case you need to roll back to your original version 
of Roller, as the Roller 5.1 upgrade process makes irreversible database 
modifications as part of updating the database to the Roller 5.1 data model.


The Roller User's list remains available for any upgrade questions.

Regards,

Apache Roller Team

[VOTE][PASSED] Release Apache Roller 5.1

[Glen Mazza]

OK, Apache Roller 5.1 is a reality, with binding +1 votes from Greg, 
Dave, Craig and myself and no other votes.


I'll promote Roller 5.1 today, upping the next version to 5.1.1-SNAPSHOT.

Cheers,
Glen


On 08/24/2014 11:08 PM, Craig L Russell wrote:

Thanks for stepping up, Glen.

+1

Craig

On Aug 20, 2014, at 4:05 PM, Glen Mazza wrote:


Hi Team,

Here's a happy email I've been looking forward to send, a vote to release 
Roller 5.1.  The release notes below detail much of what was changed from 
Roller 5.0.x.

Binaries for release candidate #2 are here: 
https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.0/. (RC #1 didn't 
last very long.)

I'll be holding the voting through the end of Sunday to give people the full 
weekend to test if they wish, however, if you're aware of problems that 
shouldn't be postponed to a future 5.1.1 please report back as soon as you're 
aware of them.

Please be careful with commits to trunk until the vote is closed and the 
artifacts are released; whatever you commit becomes part of 5.1.

The user community is also encouraged to test this release candidate and let us 
know of problems that they find, but make sure to do a backup first of your 
Roller database if you wish to test against a current blog as Roller 5.1 makes 
significant nonreversable database modifications as part of the upgrade.  
Alternatively, and more safely, RC #2 can be tested with a new database and a 
test blog.

To start the voting, here is my +1.

Regards,
Glen



Release Notes - Apache Roller - Version 5.1

** Bug
* [ROL-1118] - Problems submitting Swedish characters over the xmlrpc 
interface
* [ROL-1241] - some items in ApplicationResources.properties Duplicated
* [ROL-1273] - resource item error
* [ROL-1346] - Weblog Calendar incorrectly assuming Sunday is first day of 
week for every locale.
* [ROL-1414] - Email scrambler not detecting hyphens in email addresses
* [ROL-1421] - Minor typos in ApplicationResources.properties
* [ROL-1479] - Create Weblog screen only allows 30 chars in description
* [ROL-1571] - missing graphic alt text
* [ROL-1592] - Limited blogger is still able to post a group weblog
* [ROL-1596] - Frontpage  theme lose record!
* [ROL-1597] - Comment email notification to a user who has previously left 
a comment on the same blog (and checked the box) is not functioning
* [ROL-1615] - textual errors on ApplicationResources.properties
* [ROL-1616] - Input fields not emptied after creating a new user
* [ROL-1638] - Problem with themes on case sensitive file systems
* [ROL-1715] - SiteModel's getWeblogsByLetterPager not documented correctly
* [ROL-1716] - a bug found when call getPopularTags with the limit=-1 (v4 
m1)
* [ROL-1737] - The settings tab in roller does not show the email comments 
option as shown in the install document
* [ROL-1738] - Charset of E-Mail Subject Needs to be configurable
* [ROL-1739] - Missing constraint on weblogentrytagagg table
* [ROL-1746] - Uploaded file names are lower-cased with AtomPub.
* [ROL-1778] - Blog entry preview before first publish not working with 
Derby database
* [ROL-1792] - Hit count increments with 
* [ROL-1794] - file uploads with spaces in their names are 404ing 
(incorrect URL escaping?)
* [ROL-1795] - Posting comments with SchemeEnforcementFilter in operation.
* [ROL-1817] - login.jsp remember me check box
* [ROL-1870] - Duplicate bookmarks not showing
* [ROL-1925] - Patch for the bug of OpenID only authentication
* [ROL-1927] - Roller 5 MSSQL Issues/Fixes
* [ROL-1928] - Missing 500-to-510-migration.vm file in Roller Mobile branch
* [ROL-1929] - reindexing fails if one of authors is disabled
* [ROL-1930] - Saving Template causes Null Pointer Exception
* [ROL-1936] - Special characters are converted to ?? when editing comments
* [ROL-1952] - Roller 5.0.1 does not work with PostgreSQL 9.1
* [ROL-1953] - mysql roller_permission insert statements not defined 
correctly in 400-to-500-migration.vm and 400-to-500-migration.sql file
* [ROL-1954] - user weblogs cannot be managed when admin logs in and select 
any user via Server Aministration and clicks on eit
* [ROL-1956] - ValidateSaltFilter not working on file upload
* [ROL-1957] - Unable to find RSD template
* [ROL-1966] - Search highlight problem
* [ROL-1969] - PostgreSQL migration scripts need fixing
* [ROL-1985] - it-selenium tests not working
* [ROL-1988] - Category search not working if space exists in category
* [ROL-1992] - Blogroll OPML import page raising 500 Security Error
* [ROL-2002] - https:// URLs not being processed correctly in the comment 
URL field
* [ROL-2003] - Comments management field "select all/none" options not 
working.
* [ROL-2006] - "Sort By" dro

Re: svn commit: r1619327 - in /roller/trunk/app/src/main: java/org/apache/roller/weblogger/ui/struts2/editor/ resources/ webapp/WEB-INF/jsps/editor/ webapp/roller-ui/styles/

[Glen Mazza]

Yes, now I see it on the pre-clearfix version (both chrome and ff); yes 
it's ugly.


Thanks,
Glen


On 08/23/2014 03:28 AM, Greg Huber wrote:

It does not render correctly when there are no left hand buttons,  ie the
folder is empty.  The right div is floated so it is no longer in the "box"
anymore, so the div collapses not showing the background.

firefox esr 24.7.0.


On 22 August 2014 12:07, Glen Mazza  wrote:


On 08/22/2014 04:44 AM, Greg Huber wrote:


##

Floating divs arbitrarily can cause errors (see "has layout" csmess), the
right float causes the div background colour not to show on ff.  Why I
removed the float previously to avoid the clearfix clug.


Have you tested that recently to confirm this is still an issue in 2014?
Like I said, testing my current blog (which was uploaded before you put in
the clearfix fix) on Windows (IE, FF, and Chrome) and Ubuntu (FF and
Chrome), I simpIy can't see the issue, the right-side buttons render all
fine, as they also do after your clearfix fix.  I couldn't understand from
your JSP comment why you removed the float last time as I can't reproduce
the problem (I'm relatively new to CSS and also didn't understand the
"clearfix" thing), but even if clearfix were an issue today, it's more
important to do that hack that you put in (thanks) as IMO it makes sense
and looks nicer for certain, more destructive buttons like delete to be on
the right side.  This is not a functionality issue (where we may need to
make adjustments for older browsers to get them to work) but an UI design
one, meaning we can put more weight on having Roller look sharp on modern
browsers than to have it look suboptimal on the current ones in order to
improve appearance on older ones.

Glen

Re: svn commit: r1619327 - in /roller/trunk/app/src/main: java/org/apache/roller/weblogger/ui/struts2/editor/ resources/ webapp/WEB-INF/jsps/editor/ webapp/roller-ui/styles/

[Glen Mazza]

OK, don't forget we still need your vote...

Glen

On 08/23/2014 03:28 AM, Greg Huber wrote:

It does not render correctly when there are no left hand buttons,  ie the
folder is empty.  The right div is floated so it is no longer in the "box"
anymore, so the div collapses not showing the background.

firefox esr 24.7.0.


On 22 August 2014 12:07, Glen Mazza  wrote:


On 08/22/2014 04:44 AM, Greg Huber wrote:


##

Floating divs arbitrarily can cause errors (see "has layout" csmess), the
right float causes the div background colour not to show on ff.  Why I
removed the float previously to avoid the clearfix clug.


Have you tested that recently to confirm this is still an issue in 2014?
Like I said, testing my current blog (which was uploaded before you put in
the clearfix fix) on Windows (IE, FF, and Chrome) and Ubuntu (FF and
Chrome), I simpIy can't see the issue, the right-side buttons render all
fine, as they also do after your clearfix fix.  I couldn't understand from
your JSP comment why you removed the float last time as I can't reproduce
the problem (I'm relatively new to CSS and also didn't understand the
"clearfix" thing), but even if clearfix were an issue today, it's more
important to do that hack that you put in (thanks) as IMO it makes sense
and looks nicer for certain, more destructive buttons like delete to be on
the right side.  This is not a functionality issue (where we may need to
make adjustments for older browsers to get them to work) but an UI design
one, meaning we can put more weight on having Roller look sharp on modern
browsers than to have it look suboptimal on the current ones in order to
improve appearance on older ones.

Glen

Re: svn commit: r1619327 - in /roller/trunk/app/src/main: java/org/apache/roller/weblogger/ui/struts2/editor/ resources/ webapp/WEB-INF/jsps/editor/ webapp/roller-ui/styles/

[Glen Mazza]

On 08/22/2014 04:44 AM, Greg Huber wrote:

##

Floating divs arbitrarily can cause errors (see "has layout" csmess), the
right float causes the div background colour not to show on ff.  Why I
removed the float previously to avoid the clearfix clug.


Have you tested that recently to confirm this is still an issue in 
2014?  Like I said, testing my current blog (which was uploaded before 
you put in the clearfix fix) on Windows (IE, FF, and Chrome) and Ubuntu 
(FF and Chrome), I simpIy can't see the issue, the right-side buttons 
render all fine, as they also do after your clearfix fix.  I couldn't 
understand from your JSP comment why you removed the float last time as 
I can't reproduce the problem (I'm relatively new to CSS and also didn't 
understand the "clearfix" thing), but even if clearfix were an issue 
today, it's more important to do that hack that you put in (thanks) as 
IMO it makes sense and looks nicer for certain, more destructive buttons 
like delete to be on the right side.  This is not a functionality issue 
(where we may need to make adjustments for older browsers to get them to 
work) but an UI design one, meaning we can put more weight on having 
Roller look sharp on modern browsers than to have it look suboptimal on 
the current ones in order to improve appearance on older ones.


Glen

[VOTE RESTARTED - RC3] Release Apache Roller 5.1

[Glen Mazza]

OK team, vote has restarted, the binaries at the link below now have 
RC#3 in them.


Code freeze has been lifted but please be very conservative about what 
you put in (ideally fixes only).


Changes made: the default plugins option for each weblog has been 
restored (users on the settings page can designate which of the 
pre-installed plugins they want activated by default.), install guide 
updated in section 10.2 to add caution on running the migration script 
manually, also some GUI changes done by Greg to handle the clearfix 
issue (http://stackoverflow.com/questions/8554043/what-is-clearfix).


Here's my +1.  Voting will end at the end of Sunday Eastern US time.

Regards,
Glen


On 08/20/2014 07:05 PM, Glen Mazza wrote:

Hi Team,

Here's a happy email I've been looking forward to send, a vote to 
release Roller 5.1.  The release notes below detail much of what was 
changed from Roller 5.0.x.


Binaries for release candidate #2 are here: 
https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.0/. (RC 
#1 didn't last very long.)


I'll be holding the voting through the end of Sunday to give people 
the full weekend to test if they wish, however, if you're aware of 
problems that shouldn't be postponed to a future 5.1.1 please report 
back as soon as you're aware of them.


Please be careful with commits to trunk until the vote is closed and 
the artifacts are released; whatever you commit becomes part of 5.1.


The user community is also encouraged to test this release candidate 
and let us know of problems that they find, but make sure to do a 
backup first of your Roller database if you wish to test against a 
current blog as Roller 5.1 makes significant nonreversable database 
modifications as part of the upgrade. Alternatively, and more safely, 
RC #2 can be tested with a new database and a test blog.


To start the voting, here is my +1.

Regards,
Glen



Release Notes - Apache Roller - Version 5.1

** Bug
* [ROL-1118] - Problems submitting Swedish characters over the 
xmlrpc interface
* [ROL-1241] - some items in ApplicationResources.properties 
Duplicated

* [ROL-1273] - resource item error
* [ROL-1346] - Weblog Calendar incorrectly assuming Sunday is 
first day of week for every locale.
* [ROL-1414] - Email scrambler not detecting hyphens in email 
addresses

* [ROL-1421] - Minor typos in ApplicationResources.properties
* [ROL-1479] - Create Weblog screen only allows 30 chars in 
description

* [ROL-1571] - missing graphic alt text
* [ROL-1592] - Limited blogger is still able to post a group weblog
* [ROL-1596] - Frontpage  theme lose record!
* [ROL-1597] - Comment email notification to a user who has 
previously left a comment on the same blog (and checked the box) is 
not functioning

* [ROL-1615] - textual errors on ApplicationResources.properties
* [ROL-1616] - Input fields not emptied after creating a new user
* [ROL-1638] - Problem with themes on case sensitive file systems
* [ROL-1715] - SiteModel's getWeblogsByLetterPager not documented 
correctly
* [ROL-1716] - a bug found when call getPopularTags with the 
limit=-1 (v4 m1)
* [ROL-1737] - The settings tab in roller does not show the email 
comments option as shown in the install document

* [ROL-1738] - Charset of E-Mail Subject Needs to be configurable
* [ROL-1739] - Missing constraint on weblogentrytagagg table
* [ROL-1746] - Uploaded file names are lower-cased with AtomPub.
* [ROL-1778] - Blog entry preview before first publish not working 
with Derby database
* [ROL-1792] - Hit count increments with type="text/css" media="all" href="$model.weblog.stylesheet">
* [ROL-1794] - file uploads with spaces in their names are 404ing 
(incorrect URL escaping?)
* [ROL-1795] - Posting comments with SchemeEnforcementFilter in 
operation.

* [ROL-1817] - login.jsp remember me check box
* [ROL-1870] - Duplicate bookmarks not showing
* [ROL-1925] - Patch for the bug of OpenID only authentication
* [ROL-1927] - Roller 5 MSSQL Issues/Fixes
* [ROL-1928] - Missing 500-to-510-migration.vm file in Roller 
Mobile branch

* [ROL-1929] - reindexing fails if one of authors is disabled
* [ROL-1930] - Saving Template causes Null Pointer Exception
* [ROL-1936] - Special characters are converted to ?? when editing 
comments

* [ROL-1952] - Roller 5.0.1 does not work with PostgreSQL 9.1
* [ROL-1953] - mysql roller_permission insert statements not 
defined correctly in 400-to-500-migration.vm and 
400-to-500-migration.sql file
* [ROL-1954] - user weblogs cannot be managed when admin logs in 
and select any user via Server Aministration and clicks on eit

* [ROL-1956] - ValidateSaltFilter not working on file upload
* [ROL-1957] - Unable to find RSD template
* [ROL-1966] -

Re: [VOTE] Release Apache Roller 5.1

[Glen Mazza]

I like 5.1.  It's nice and modest.  But please hold off on testing until 
I have RC3 out later on today...


Glen

On 08/21/2014 03:43 PM, Matt Raible wrote:

This seems like a pretty big release. Maybe we should up the version so it's 
5.5 or 6.0?

On Aug 20, 2014, at 5:05 PM, Glen Mazza  wrote:


Hi Team,

Here's a happy email I've been looking forward to send, a vote to release 
Roller 5.1.  The release notes below detail much of what was changed from 
Roller 5.0.x.

Binaries for release candidate #2 are here: 
https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.0/. (RC #1 didn't 
last very long.)

I'll be holding the voting through the end of Sunday to give people the full 
weekend to test if they wish, however, if you're aware of problems that 
shouldn't be postponed to a future 5.1.1 please report back as soon as you're 
aware of them.

Please be careful with commits to trunk until the vote is closed and the 
artifacts are released; whatever you commit becomes part of 5.1.

The user community is also encouraged to test this release candidate and let us 
know of problems that they find, but make sure to do a backup first of your 
Roller database if you wish to test against a current blog as Roller 5.1 makes 
significant nonreversable database modifications as part of the upgrade.  
Alternatively, and more safely, RC #2 can be tested with a new database and a 
test blog.

To start the voting, here is my +1.

Regards,
Glen



Release Notes - Apache Roller - Version 5.1

** Bug
* [ROL-1118] - Problems submitting Swedish characters over the xmlrpc 
interface
* [ROL-1241] - some items in ApplicationResources.properties Duplicated
* [ROL-1273] - resource item error
* [ROL-1346] - Weblog Calendar incorrectly assuming Sunday is first day of 
week for every locale.
* [ROL-1414] - Email scrambler not detecting hyphens in email addresses
* [ROL-1421] - Minor typos in ApplicationResources.properties
* [ROL-1479] - Create Weblog screen only allows 30 chars in description
* [ROL-1571] - missing graphic alt text
* [ROL-1592] - Limited blogger is still able to post a group weblog
* [ROL-1596] - Frontpage  theme lose record!
* [ROL-1597] - Comment email notification to a user who has previously left 
a comment on the same blog (and checked the box) is not functioning
* [ROL-1615] - textual errors on ApplicationResources.properties
* [ROL-1616] - Input fields not emptied after creating a new user
* [ROL-1638] - Problem with themes on case sensitive file systems
* [ROL-1715] - SiteModel's getWeblogsByLetterPager not documented correctly
* [ROL-1716] - a bug found when call getPopularTags with the limit=-1 (v4 
m1)
* [ROL-1737] - The settings tab in roller does not show the email comments 
option as shown in the install document
* [ROL-1738] - Charset of E-Mail Subject Needs to be configurable
* [ROL-1739] - Missing constraint on weblogentrytagagg table
* [ROL-1746] - Uploaded file names are lower-cased with AtomPub.
* [ROL-1778] - Blog entry preview before first publish not working with 
Derby database
* [ROL-1792] - Hit count increments with 
* [ROL-1794] - file uploads with spaces in their names are 404ing 
(incorrect URL escaping?)
* [ROL-1795] - Posting comments with SchemeEnforcementFilter in operation.
* [ROL-1817] - login.jsp remember me check box
* [ROL-1870] - Duplicate bookmarks not showing
* [ROL-1925] - Patch for the bug of OpenID only authentication
* [ROL-1927] - Roller 5 MSSQL Issues/Fixes
* [ROL-1928] - Missing 500-to-510-migration.vm file in Roller Mobile branch
* [ROL-1929] - reindexing fails if one of authors is disabled
* [ROL-1930] - Saving Template causes Null Pointer Exception
* [ROL-1936] - Special characters are converted to ?? when editing comments
* [ROL-1952] - Roller 5.0.1 does not work with PostgreSQL 9.1
* [ROL-1953] - mysql roller_permission insert statements not defined 
correctly in 400-to-500-migration.vm and 400-to-500-migration.sql file
* [ROL-1954] - user weblogs cannot be managed when admin logs in and select 
any user via Server Aministration and clicks on eit
* [ROL-1956] - ValidateSaltFilter not working on file upload
* [ROL-1957] - Unable to find RSD template
* [ROL-1966] - Search highlight problem
* [ROL-1969] - PostgreSQL migration scripts need fixing
* [ROL-1985] - it-selenium tests not working
* [ROL-1988] - Category search not working if space exists in category
* [ROL-1992] - Blogroll OPML import page raising 500 Security Error
* [ROL-2002] - https:// URLs not being processed correctly in the comment 
URL field
* [ROL-2003] - Comments management field "select all/none" options not 
working.
* [ROL-2006] - "Sort By" dropdown not working in media file vi

Re: [FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1

[Glen Mazza]

On 08/21/2014 02:08 PM, Dave wrote:

On Thu, Aug 21, 2014 at 12:42 PM, Glen Mazza  wrote:


On 08/21/2014 05:39 AM, Greg Huber wrote:


Glen,

On upgrading/testing.

##

One of my databases failed on this statement on the upgrade. The index did
not exist.

ALTER TABLE bookmark_folder DROP INDEX folder_namefolderid_uq;

Its does mention it may not exist.



Hi Greg, yes, I put a change in the code for dropping of nonexistent
indexes to be a non-fatal upgrade error, seeing that we don't need to fail
if we're trying to delete something that already doesn't exist.  Some
roller installs have indexes that others don't, and I just want the upgrade
to proceed in those cases, rather than leave people with a half-completed
database.

http://svn.apache.org/viewvc/roller/trunk/app/src/main/
java/org/apache/roller/weblogger/business/startup/SQLScriptRunner.java?r1=
1580425&r2=1613234&diff_format=h


The problem with that fix is that many sys admins prefer (that was my first
inclination and Greg's too) to run the database script "manually" instead
of letting Roller run the script. When you run the script manually, that
error causes the script to fail.



OK, I just saw the relevant section in our Install Guide (Section 10.2), 
to me manual process meant the DBA ran the statements one-by-one before 
going on to the next, not that they would run a single SQL script 
without looking at or modifying its contents, as the latter process 
wouldn't give them much advantage over the automated process.  We've 
already commented in the migration script that this index may not exist 
and hence manual upgraders may not wish to run the statement:


-- If you run this script manually (i.e. you are doing 
installation.type=manual)
-- them you may need to comment out this next statement, this index does 
not

-- exist in all Roller systems:
alter table bookmark_folder drop index folder_namefolderid_uq;


Possible solutions:
* In the upgrade docs, tell people not to run the script manually


That's too strong.  I just need to update the section saying that the 
migration script may not be runnable as a whole as some databases throw 
an error when one attempts to delete an index or foreign key that does 
not already exist, something that the automated process takes care of 
automatically.  Therefore, manual upgraders may need to run the upgrade 
statements one-by-one rather than the script as a whole, or comment out 
drop index or foreign key statements that they already know don't exist.


I'll get that done.


* In the upgrade docs, tell people that want to run manually they should
use a "continue on error" appropriate for their database (on MySQL this is
the --force option)


Possible, but continue on error is too dangerous because you need to 
know what the error is.  Dropping something that doesn't already exist 
is normally survivable, but other types of errors you do want the 
database script to halt on.  Manual updaters, i.e., those leery of 
relying on our automated process, would probably also be equally leery 
of "continue on error".


Glen

Re: svn commit: r1619327 - in /roller/trunk/app/src/main: java/org/apache/roller/weblogger/ui/struts2/editor/ resources/ webapp/WEB-INF/jsps/editor/ webapp/roller-ui/styles/

[Glen Mazza]

On 08/21/2014 05:39 AM, ghu...@apache.org wrote:

Modified: 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/struts2/editor/MediaFileAdd.java
URL:http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/struts2/editor/MediaFileAdd.java?rev=1619327&r1=1619326&r2=1619327&view=diff
==
--- 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/struts2/editor/MediaFileAdd.java
 (original)
+++ 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/ui/struts2/editor/MediaFileAdd.java
 Thu Aug 21 09:39:05 2014
@@ -19,11 +19,11 @@ package org.apache.roller.weblogger.ui.s
  
  import java.io.File;

  import java.io.FileInputStream;
-
  import java.util.ArrayList;
  import java.util.Arrays;
  import java.util.Iterator;
  import java.util.List;
+
  import org.apache.commons.lang3.StringUtils;
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogFactory;
@@ -248,6 +248,15 @@ public class MediaFileAdd extends MediaF
  addError("error.upload.disabled");
  }
  }
+
+/**
+ * Cancel.
+ *
+ * @return the string
+ */
+public String cancel() {
+return CANCEL;
+}
  


Just FYI, not necessary, as cancel() is defined as above in UIAction, 
for any action needing it.





Modified: roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/Bookmarks.jsp
URL:http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/Bookmarks.jsp?rev=1619327&r1=1619326&r2=1619327&view=diff
==
--- roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/Bookmarks.jsp 
(original)
+++ roller/trunk/app/src/main/webapp/WEB-INF/jsps/editor/Bookmarks.jsp Thu Aug 
21 09:39:05 2014
@@ -153,7 +153,7 @@ function onMove()
  
  
  
-

+
  
  <%-- Delete-selected button --%>
  " 
onclick="onDelete();return false;" />
@@ -168,6 +168,7 @@ function onMove()
  
  
  

+
  
  
  


Boo Hiss. "group" is way too generic a name for a class, call it 
"clearfix" or something.  I'll fix it...


I never heard of the clearfix problem until googling it this morning, 
the latest Firefox and Chrome browsers have no problem with it.  Which 
browsers are you using that require the clearfix hack?


Cheers,
Glen

[FAILED][CODE FREEZE: On]Re: [VOTE] Release Apache Roller 5.1

[Glen Mazza]

On 08/21/2014 05:39 AM, Greg Huber wrote:

Glen,

On upgrading/testing.

##

One of my databases failed on this statement on the upgrade. The index did
not exist.

ALTER TABLE bookmark_folder DROP INDEX folder_namefolderid_uq;

Its does mention it may not exist.



Hi Greg, yes, I put a change in the code for dropping of nonexistent 
indexes to be a non-fatal upgrade error, seeing that we don't need to 
fail if we're trying to delete something that already doesn't exist.  
Some roller installs have indexes that others don't, and I just want the 
upgrade to proceed in those cases, rather than leave people with a 
half-completed database.


http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/business/startup/SQLScriptRunner.java?r1=1580425&r2=1613234&diff_format=h


##

Formatting section on preference | settings

Not sure on this now, maybe needs to be removed from WeblogConfig.jsp as
bean.defaultPluginsArray has been removed.


 
  
 
 

 
 <%--  --%>
 
 
 
 
 



My error, I should not have removed defaultPlugins from the Weblog 
class, in my email of July 23rd I recommended its removal without 
realizing it was indeed configurable at the blog level:


8.) defaultplugins: Always null, no place to configure at the 
blog-level, as with #2 above, perhaps best to let the blog admin 
configure this for all bloggers in the roller-custom.properties file.


I'll put this back in and come up with another RC3 today.

Regards,
Glen

Re: code freeze...

[Glen Mazza]

Commits are OK, per my [VOTE] email, as I'm not making another RC just 
yet.  Just be very cautious/conservative in commits as they go into 5.1, 
major stuff can wait until after we release.


I'll be freezing again soon for RC3.

Thanks,
Glen


On 08/21/2014 05:40 AM, Greg Huber wrote:

oops sorry, made a commit.


On 20 August 2014 17:42, Glen Mazza  wrote:


If people could refrain from svn commits today, I'm making the 1st rc
right now.

Thanks,
Glen

[VOTE] Release Apache Roller 5.1

[Glen Mazza]

Hi Team,

Here's a happy email I've been looking forward to send, a vote to 
release Roller 5.1.  The release notes below detail much of what was 
changed from Roller 5.0.x.


Binaries for release candidate #2 are here: 
https://dist.apache.org/repos/dist/dev/roller/roller-5.1/v5.1.0/. (RC #1 
didn't last very long.)


I'll be holding the voting through the end of Sunday to give people the 
full weekend to test if they wish, however, if you're aware of problems 
that shouldn't be postponed to a future 5.1.1 please report back as soon 
as you're aware of them.


Please be careful with commits to trunk until the vote is closed and the 
artifacts are released; whatever you commit becomes part of 5.1.


The user community is also encouraged to test this release candidate and 
let us know of problems that they find, but make sure to do a backup 
first of your Roller database if you wish to test against a current blog 
as Roller 5.1 makes significant nonreversable database modifications as 
part of the upgrade.  Alternatively, and more safely, RC #2 can be 
tested with a new database and a test blog.


To start the voting, here is my +1.

Regards,
Glen



Release Notes - Apache Roller - Version 5.1

** Bug
* [ROL-1118] - Problems submitting Swedish characters over the 
xmlrpc interface

* [ROL-1241] - some items in ApplicationResources.properties Duplicated
* [ROL-1273] - resource item error
* [ROL-1346] - Weblog Calendar incorrectly assuming Sunday is first 
day of week for every locale.

* [ROL-1414] - Email scrambler not detecting hyphens in email addresses
* [ROL-1421] - Minor typos in ApplicationResources.properties
* [ROL-1479] - Create Weblog screen only allows 30 chars in description
* [ROL-1571] - missing graphic alt text
* [ROL-1592] - Limited blogger is still able to post a group weblog
* [ROL-1596] - Frontpage  theme lose record!
* [ROL-1597] - Comment email notification to a user who has 
previously left a comment on the same blog (and checked the box) is not 
functioning

* [ROL-1615] - textual errors on ApplicationResources.properties
* [ROL-1616] - Input fields not emptied after creating a new user
* [ROL-1638] - Problem with themes on case sensitive file systems
* [ROL-1715] - SiteModel's getWeblogsByLetterPager not documented 
correctly
* [ROL-1716] - a bug found when call getPopularTags with the 
limit=-1 (v4 m1)
* [ROL-1737] - The settings tab in roller does not show the email 
comments option as shown in the install document

* [ROL-1738] - Charset of E-Mail Subject Needs to be configurable
* [ROL-1739] - Missing constraint on weblogentrytagagg table
* [ROL-1746] - Uploaded file names are lower-cased with AtomPub.
* [ROL-1778] - Blog entry preview before first publish not working 
with Derby database
* [ROL-1792] - Hit count increments with type="text/css" media="all" href="$model.weblog.stylesheet">
* [ROL-1794] - file uploads with spaces in their names are 404ing 
(incorrect URL escaping?)
* [ROL-1795] - Posting comments with SchemeEnforcementFilter in 
operation.

* [ROL-1817] - login.jsp remember me check box
* [ROL-1870] - Duplicate bookmarks not showing
* [ROL-1925] - Patch for the bug of OpenID only authentication
* [ROL-1927] - Roller 5 MSSQL Issues/Fixes
* [ROL-1928] - Missing 500-to-510-migration.vm file in Roller 
Mobile branch

* [ROL-1929] - reindexing fails if one of authors is disabled
* [ROL-1930] - Saving Template causes Null Pointer Exception
* [ROL-1936] - Special characters are converted to ?? when editing 
comments

* [ROL-1952] - Roller 5.0.1 does not work with PostgreSQL 9.1
* [ROL-1953] - mysql roller_permission insert statements not 
defined correctly in 400-to-500-migration.vm and 
400-to-500-migration.sql file
* [ROL-1954] - user weblogs cannot be managed when admin logs in 
and select any user via Server Aministration and clicks on eit

* [ROL-1956] - ValidateSaltFilter not working on file upload
* [ROL-1957] - Unable to find RSD template
* [ROL-1966] - Search highlight problem
* [ROL-1969] - PostgreSQL migration scripts need fixing
* [ROL-1985] - it-selenium tests not working
* [ROL-1988] - Category search not working if space exists in category
* [ROL-1992] - Blogroll OPML import page raising 500 Security Error
* [ROL-2002] - https:// URLs not being processed correctly in the 
comment URL field
* [ROL-2003] - Comments management field "select all/none" options 
not working.

* [ROL-2006] - "Sort By" dropdown not working in media file view.
* [ROL-2007] - Changing values in Media File Editor frequently 
results in permissions error.

* [ROL-2009] - Custom template theme folder creation isn't working
* [ROL-2011] - Media File Chooser on Blog Edit screen is empty.
* [ROL-2016] - roller-startup.log not created on 

rc1 failed...

[Glen Mazza]

Testing RC#1 I found two errors that needed to get fixed, I'm fixing now 
and will release RC #2 and hold the vote for that shortly...

code freeze...

[Glen Mazza]

If people could refrain from svn commits today, I'm making the 1st rc 
right now.


Thanks,
Glen

Re: ampersand on search text

[Glen Mazza]

OK, I changed the code to:

public String getTerm() {
String query = searchRequest.getQuery();
return (query == null)
? "" : StringEscapeUtils.escapeXml10(query);
}

in SearchResultsModel, the double-escaping problem has gone away. The 
"escapeXML" method is deprecated, so I replaced it with escapeXML10, 
apparently still the dominant XML to use.


Regards,
Glen


On 08/20/2014 09:48 AM, Glen Mazza wrote:
Oops, I note the code is escapeXML(escapeHTML), not 
escapeHTML(escapeHTML).  Still checking...


Glen


On 08/19/2014 09:52 PM, Glen Mazza wrote:
Hi Dave, do you know why 
"StringEscapeUtils.escapeXml(Utilities.escapeHTML(query)); " is not 
just coded as "Utilities.escapeHTML(query); " ?


On the basic theme search, if I do a search on "home run" (with 
quotes), the search field gets repopulated as "home run" , 
if I search again, another pair of "s get added in, etc.


I can test and remove that in a heartbeat, but I'm not sure if the 
double escapeHTML was meant to guard against XSS attacks. Might that 
have been the case?  If so, maybe we can postpone a full solution to 
past 5.1.


(Incidentally, I just updated my own blog to the latest 5.1, and 
found a couple of minor nitpicks, unneeded files, etc. that I've 
since fixed in the code.  I'm trying to keep changes minimal this 
week, unless a known error.)


Thanks,
Glen


On 08/14/2014 07:19 AM, Glen Mazza wrote:
Hi Greg, that was done by Dave as part of this commit last August 
13th: http://svn.apache.org/viewvc?view=revision&revision=151, 
which *may* have been part of the XSS security release Dave did the 
following November: 
http://rollerweblogger.org/project/entry/apache_roller_5_0_2.


It may have been a copy and paste error, checking in feeds.vm in the 
above commit he does a escapeHTML(removeHTML) but in the other an 
escapeHTML(escapeHTML).  One of the three files, 
SearchResultsModel() had no real changes, just the formatting was 
rearranged.


I would say we don't need to allow searching on punctuation 
characters (does Google even?) but if Dave doesn't respond and 
removing one of the escapeHTML calls fixes things without breaking 
more important stuff, perhaps good to go ahead with the change. 
Certainly, if it needs to be reapplied, next time we can put in a 
comment saying why the consecutive escapeHTML() calls are necessary.


Regards,
Glen

On 08/14/2014 04:03 AM, Greg Huber wrote:

Glen,

When I do a search containing and ampersand, roller does not show 
correctly

the returned text.

eg

b&z

actually returns :b&z

which renders  as b&z

It should return b&z with no second ampersand for it to render
correctly.

Checking the method getTerm() it does a double escape, where the
StringEscapeUtils.escapeXml(..) adds the extra  amp; causing it not 
to show

correctly :

SearchResultsModel():

public String getTerm() {
 String query = searchRequest.getQuery();
 return (query == null)
 ? "" : 
StringEscapeUtils.escapeXml(Utilities.escapeHTML(query));

 }

Do we need the double escape? For XSS? 
StringEscapeUtils.escapeXml() or

how do we make it render correctly?


Cheers Greg.

Re: ampersand on search text

[Glen Mazza]

Oops, I note the code is escapeXML(escapeHTML), not 
escapeHTML(escapeHTML).  Still checking...


Glen


On 08/19/2014 09:52 PM, Glen Mazza wrote:
Hi Dave, do you know why 
"StringEscapeUtils.escapeXml(Utilities.escapeHTML(query)); " is not 
just coded as "Utilities.escapeHTML(query); " ?


On the basic theme search, if I do a search on "home run" (with 
quotes), the search field gets repopulated as "home run" , 
if I search again, another pair of "s get added in, etc.


I can test and remove that in a heartbeat, but I'm not sure if the 
double escapeHTML was meant to guard against XSS attacks.  Might that 
have been the case?  If so, maybe we can postpone a full solution to 
past 5.1.


(Incidentally, I just updated my own blog to the latest 5.1, and found 
a couple of minor nitpicks, unneeded files, etc. that I've since fixed 
in the code.  I'm trying to keep changes minimal this week, unless a 
known error.)


Thanks,
Glen


On 08/14/2014 07:19 AM, Glen Mazza wrote:
Hi Greg, that was done by Dave as part of this commit last August 
13th: http://svn.apache.org/viewvc?view=revision&revision=151, 
which *may* have been part of the XSS security release Dave did the 
following November: 
http://rollerweblogger.org/project/entry/apache_roller_5_0_2.


It may have been a copy and paste error, checking in feeds.vm in the 
above commit he does a escapeHTML(removeHTML) but in the other an 
escapeHTML(escapeHTML).  One of the three files, SearchResultsModel() 
had no real changes, just the formatting was rearranged.


I would say we don't need to allow searching on punctuation 
characters (does Google even?) but if Dave doesn't respond and 
removing one of the escapeHTML calls fixes things without breaking 
more important stuff, perhaps good to go ahead with the change. 
Certainly, if it needs to be reapplied, next time we can put in a 
comment saying why the consecutive escapeHTML() calls are necessary.


Regards,
Glen

On 08/14/2014 04:03 AM, Greg Huber wrote:

Glen,

When I do a search containing and ampersand, roller does not show 
correctly

the returned text.

eg

b&z

actually returns :b&z

which renders  as b&z

It should return b&z with no second ampersand for it to render
correctly.

Checking the method getTerm() it does a double escape, where the
StringEscapeUtils.escapeXml(..) adds the extra  amp; causing it not 
to show

correctly :

SearchResultsModel():

public String getTerm() {
 String query = searchRequest.getQuery();
 return (query == null)
 ? "" : 
StringEscapeUtils.escapeXml(Utilities.escapeHTML(query));

 }

Do we need the double escape? For XSS? StringEscapeUtils.escapeXml() or
how do we make it render correctly?


Cheers Greg.

Re: 5.1 status

[Glen Mazza]

If you'd like a break this weekend, I can probably take care of the 
first RC over the next couple of days.  Just let me know.


Regards,
Glen


On 08/17/2014 04:30 PM, Dave wrote:

I've upgraded my site to "Apache Roller Weblogger Version 5.1.0-SNAPSHOT
(r1618351)" and the blogs hosted on my Roller instance look pretty good:

http://rollerweblogger.org/roller/
http://rollerweblogger.org
http://photophys.com

I ran into a bunch of problems with my themes, but I believe all problems
were due to my schema, which had a bunch of pre-5.1 dev stuff present.  I
should have time to roll a first release candidate next weekend.

- Dave



On Sat, Aug 16, 2014 at 2:34 PM, Dave  wrote:


I had some success testing 500-to-510 upgrade script against
rollerweblogger.org and blogs.apache.org.

With rollerweblgger.org, I had to use a custom version of the script
because the schema there is a mix of 5.0 and 5.1 stuff. Everything went
fine and blogging features seem to be working.

With blogs.apache.org, I did the database upgrade manually, as I expect
the Infrastructure will do and the migration script hit an error and exited
with it hit that drop-index call for "folder_namefolderid_uq." I was able
to omit that statement and get the rest of the upgrade to run successfully.
  I added a comment to the upgrade script template to note that the drop may
fail, just so folks know it might be a problem -- it won't bea problem for
people who choose the automatic install, which is what we encourage in the
install guide.

I had to do some work to upgrade the two ASF themes used on
blogs.apache.org, but after that, things looked good and I think we'll be
ready when the blogs.apache.org chooses to upgrade.

I'll upgrade rollerweblogger.org to 5.1 tomorrow and report back later.

- Dave




On Sat, Aug 16, 2014 at 10:09 AM, Glen Mazza  wrote:


OK, now I'm done with the docs too, so done with everything.  If others
on the team can start testing Roller trunk that would be good.

Dave, once the testing is all fine on your side, would you mind making
the release artifacts for 5.1 to hold the vote?  The process has changed as
we're now on svnpubsub for builds, I've updated the guide here:
https://cwiki.apache.org/confluence/display/ROLLER/Release+Process, it
would be good for you to go through it once.  If we have to make a 2nd,
3rd, etc., set of artifacts until the vote passes (most likely due to
coding errors I put in), I will take care of it from there.

Regards,
Glen



On 08/16/2014 09:37 AM, Glen Mazza wrote:


Trackbacks are working fine, so I'm done now, coding-wise.  Just
checking the install guide right now...

Glen


On 08/16/2014 08:56 AM, Dave wrote:


Great! I will test against my site and the blogs.apache.org database
today
and hope to update rollerweblogger.org to be running 5.1 sometime
tomorrow.

- Dave



On Fri, Aug 15, 2014 at 10:39 PM, Glen Mazza 
wrote:

  OK, I'm happy to report the first two items are done, also, Dual

DB/Open
ID security seems to run pretty well so we'll have 4 auth options
(everything except CMA) available.  I just want to sanity check
trackbacks
tomorrow and then I'll be finished on my side for 5.1.

Glen


On 08/13/2014 09:28 PM, Glen Mazza wrote:

  Hi team, things I see left for 5.1 (at least on my side):

-- Creating a blog post from the MediaFileFromEdit view is inoperative
perhaps as a result of recent changes I made, I need to revisit it.

-- Need to make sure the User Admin and Edit Profile are showing the
correct fields depending on the security implementation (LDAP,
OpenID, or
regular Database)--some have password fields, some don't etc.  (We
may not
have Dual DB/Open ID ready for 5.1, I don't want to hold off a
release for
that though.)  This is about halfway done.

-- Check that trackbacks work.  I've never used them before and would
like to make sure they basically work.

There are many other tasks that can be done, but those can wait for
5.1.1
and onward.  So long as 5.1 is more solid than 5.0.4, we should be OK
for a
release.

Regards,
Glen

Re: ampersand on search text

[Glen Mazza]

Hi Dave, do you know why 
"StringEscapeUtils.escapeXml(Utilities.escapeHTML(query)); " is not just 
coded as "Utilities.escapeHTML(query); " ?


On the basic theme search, if I do a search on "home run" (with quotes), 
the search field gets repopulated as "home run" , if I search 
again, another pair of "s get added in, etc.


I can test and remove that in a heartbeat, but I'm not sure if the 
double escapeHTML was meant to guard against XSS attacks.  Might that 
have been the case?  If so, maybe we can postpone a full solution to 
past 5.1.


(Incidentally, I just updated my own blog to the latest 5.1, and found a 
couple of minor nitpicks, unneeded files, etc. that I've since fixed in 
the code.  I'm trying to keep changes minimal this week, unless a known 
error.)


Thanks,
Glen


On 08/14/2014 07:19 AM, Glen Mazza wrote:
Hi Greg, that was done by Dave as part of this commit last August 
13th: http://svn.apache.org/viewvc?view=revision&revision=151, 
which *may* have been part of the XSS security release Dave did the 
following November: 
http://rollerweblogger.org/project/entry/apache_roller_5_0_2.


It may have been a copy and paste error, checking in feeds.vm in the 
above commit he does a escapeHTML(removeHTML) but in the other an 
escapeHTML(escapeHTML).  One of the three files, SearchResultsModel() 
had no real changes, just the formatting was rearranged.


I would say we don't need to allow searching on punctuation characters 
(does Google even?) but if Dave doesn't respond and removing one of 
the escapeHTML calls fixes things without breaking more important 
stuff, perhaps good to go ahead with the change. Certainly, if it 
needs to be reapplied, next time we can put in a comment saying why 
the consecutive escapeHTML() calls are necessary.


Regards,
Glen

On 08/14/2014 04:03 AM, Greg Huber wrote:

Glen,

When I do a search containing and ampersand, roller does not show 
correctly

the returned text.

eg

b&z

actually returns :b&z

which renders  as b&z

It should return b&z with no second ampersand for it to render
correctly.

Checking the method getTerm() it does a double escape, where the
StringEscapeUtils.escapeXml(..) adds the extra  amp; causing it not 
to show

correctly :

SearchResultsModel():

public String getTerm() {
 String query = searchRequest.getQuery();
 return (query == null)
 ? "" : 
StringEscapeUtils.escapeXml(Utilities.escapeHTML(query));

 }

Do we need the double escape? For XSS? StringEscapeUtils.escapeXml() or
how do we make it render correctly?


Cheers Greg.

Re: 5.1 status

[Glen Mazza]

Just FYI, I fixed the blogroll list on the Roller blog, I just needed to 
rename the blogroll folder in the vm template from "/Documentation" to 
"Documentation", as we now use names instead of paths for bookmark folders.


Glen

On 08/17/2014 04:30 PM, Dave wrote:

I've upgraded my site to "Apache Roller Weblogger Version 5.1.0-SNAPSHOT
(r1618351)" and the blogs hosted on my Roller instance look pretty good:

http://rollerweblogger.org/roller/
http://rollerweblogger.org
http://photophys.com

I ran into a bunch of problems with my themes, but I believe all problems
were due to my schema, which had a bunch of pre-5.1 dev stuff present.  I
should have time to roll a first release candidate next weekend.

- Dave



On Sat, Aug 16, 2014 at 2:34 PM, Dave  wrote:


I had some success testing 500-to-510 upgrade script against
rollerweblogger.org and blogs.apache.org.

With rollerweblgger.org, I had to use a custom version of the script
because the schema there is a mix of 5.0 and 5.1 stuff. Everything went
fine and blogging features seem to be working.

With blogs.apache.org, I did the database upgrade manually, as I expect
the Infrastructure will do and the migration script hit an error and exited
with it hit that drop-index call for "folder_namefolderid_uq." I was able
to omit that statement and get the rest of the upgrade to run successfully.
  I added a comment to the upgrade script template to note that the drop may
fail, just so folks know it might be a problem -- it won't bea problem for
people who choose the automatic install, which is what we encourage in the
install guide.

I had to do some work to upgrade the two ASF themes used on
blogs.apache.org, but after that, things looked good and I think we'll be
ready when the blogs.apache.org chooses to upgrade.

I'll upgrade rollerweblogger.org to 5.1 tomorrow and report back later.

- Dave




On Sat, Aug 16, 2014 at 10:09 AM, Glen Mazza  wrote:


OK, now I'm done with the docs too, so done with everything.  If others
on the team can start testing Roller trunk that would be good.

Dave, once the testing is all fine on your side, would you mind making
the release artifacts for 5.1 to hold the vote?  The process has changed as
we're now on svnpubsub for builds, I've updated the guide here:
https://cwiki.apache.org/confluence/display/ROLLER/Release+Process, it
would be good for you to go through it once.  If we have to make a 2nd,
3rd, etc., set of artifacts until the vote passes (most likely due to
coding errors I put in), I will take care of it from there.

Regards,
Glen



On 08/16/2014 09:37 AM, Glen Mazza wrote:


Trackbacks are working fine, so I'm done now, coding-wise.  Just
checking the install guide right now...

Glen


On 08/16/2014 08:56 AM, Dave wrote:


Great! I will test against my site and the blogs.apache.org database
today
and hope to update rollerweblogger.org to be running 5.1 sometime
tomorrow.

- Dave



On Fri, Aug 15, 2014 at 10:39 PM, Glen Mazza 
wrote:

  OK, I'm happy to report the first two items are done, also, Dual

DB/Open
ID security seems to run pretty well so we'll have 4 auth options
(everything except CMA) available.  I just want to sanity check
trackbacks
tomorrow and then I'll be finished on my side for 5.1.

Glen


On 08/13/2014 09:28 PM, Glen Mazza wrote:

  Hi team, things I see left for 5.1 (at least on my side):

-- Creating a blog post from the MediaFileFromEdit view is inoperative
perhaps as a result of recent changes I made, I need to revisit it.

-- Need to make sure the User Admin and Edit Profile are showing the
correct fields depending on the security implementation (LDAP,
OpenID, or
regular Database)--some have password fields, some don't etc.  (We
may not
have Dual DB/Open ID ready for 5.1, I don't want to hold off a
release for
that though.)  This is about halfway done.

-- Check that trackbacks work.  I've never used them before and would
like to make sure they basically work.

There are many other tasks that can be done, but those can wait for
5.1.1
and onward.  So long as 5.1 is more solid than 5.0.4, we should be OK
for a
release.

Regards,
Glen

Re: svn commit: r1618424 - in /roller/trunk: app/src/main/java/org/apache/roller/weblogger/pojos/wrapper/ app/src/main/webapp/WEB-INF/jsps/core/ app/src/main/webapp/WEB-INF/velocity/ app/src/main/weba

[Glen Mazza]

Sorry, I found a had-to-fix bug as I was moving the Brushed Metal theme 
from 5.0.x to Roller-extras.  This should not affect Dave's theme tests 
with blogs.apache.org as AFAICT they don't use blog taglines in their 
theme.  I'm finished (again) with any coding changes.


Glen

On 08/16/2014 06:45 PM, gma...@apache.org wrote:

Author: gmazza
Date: Sat Aug 16 22:45:32 2014
New Revision: 1618424

URL: http://svn.apache.org/r1618424
Log:
Fixed bugs (sorry) -- (1)  was putting blog tagline into meta description field 
for blog homepages instead of the blog about text; (2) permalink pages of 
themes were missing the (Google) analytics tracking keys, (3) removed 
model.weblog.description calls in the themes and replaced with 
model.weblog.about or model.weblog.tagline depending on which was actually 
needed.

Modified:
 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/pojos/wrapper/WeblogWrapper.java
 roller/trunk/app/src/main/webapp/WEB-INF/jsps/core/MainMenu.jsp
 
roller/trunk/app/src/main/webapp/WEB-INF/velocity/templates/feeds/weblog-comments-rss.vm
 
roller/trunk/app/src/main/webapp/WEB-INF/velocity/templates/feeds/weblog-entries-atom.vm
 
roller/trunk/app/src/main/webapp/WEB-INF/velocity/templates/feeds/weblog-entries-rss.vm
 
roller/trunk/app/src/main/webapp/WEB-INF/velocity/templates/feeds/weblog-files-atom.vm
 roller/trunk/app/src/main/webapp/WEB-INF/velocity/weblog.vm
 roller/trunk/app/src/main/webapp/themes/basic/permalink.vm
 roller/trunk/app/src/main/webapp/themes/basic/weblog.vm
 roller/trunk/app/src/main/webapp/themes/basicmobile/permalink-mobile.vm
 roller/trunk/app/src/main/webapp/themes/basicmobile/permalink.vm
 roller/trunk/app/src/main/webapp/themes/basicmobile/weblog-mobile.vm
 roller/trunk/app/src/main/webapp/themes/fauxcoly/entry.vm
 roller/trunk/app/src/main/webapp/themes/fauxcoly/std_header.vm
 roller/trunk/app/src/main/webapp/themes/fauxcoly/weblog.vm
 roller/trunk/app/src/main/webapp/themes/frontpage/_blogprofile.vm
 roller/trunk/app/src/main/webapp/themes/gaurav/entry.vm
 roller/trunk/app/src/main/webapp/themes/gaurav/search.vm
 roller/trunk/app/src/main/webapp/themes/gaurav/std_head.vm
 roller/trunk/app/src/main/webapp/themes/gaurav/tags_index.vm
 roller/trunk/app/src/main/webapp/themes/gaurav/weblog.vm
 roller/trunk/docs/roller-template-guide.odt

Modified: 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/pojos/wrapper/WeblogWrapper.java
URL: 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/pojos/wrapper/WeblogWrapper.java?rev=1618424&r1=1618423&r2=1618424&view=diff
==
--- 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/pojos/wrapper/WeblogWrapper.java
 (original)
+++ 
roller/trunk/app/src/main/java/org/apache/roller/weblogger/pojos/wrapper/WeblogWrapper.java
 Sat Aug 16 22:45:32 2014
@@ -108,16 +108,10 @@ public final class WeblogWrapper {
  return StringEscapeUtils.escapeHtml4(this.pojo.getName());
  }
  
-/* Deprecated in Roller 5.1 */

-public String getDescription() {
-return getTagline();
-}
-
  public String getTagline() {
  return HTMLSanitizer.conditionallySanitize(this.pojo.getTagline());
  }
  
-

  public UserWrapper getCreator() {
  return UserWrapper.wrap(this.pojo.getCreator());
  }
@@ -125,8 +119,7 @@ public final class WeblogWrapper {
  public Boolean getEnableBloggerApi() {
  return this.pojo.getEnableBloggerApi();
  }
-
-
+
  public WeblogCategoryWrapper getBloggerCategory() {
  return WeblogCategoryWrapper.wrap(this.pojo.getBloggerCategory(), 
urlStrategy);
  }
@@ -376,7 +369,7 @@ public final class WeblogWrapper {
   * this is a special method to access the original pojo
   * we don't really want to do this, but it's necessary
   * because some parts of the rendering process still need the
- * orginal pojo object
+ * original pojo object
   */
  public Weblog getPojo() {
  return this.pojo;

Modified: roller/trunk/app/src/main/webapp/WEB-INF/jsps/core/MainMenu.jsp
URL: 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/WEB-INF/jsps/core/MainMenu.jsp?rev=1618424&r1=1618423&r2=1618424&view=diff
==
--- roller/trunk/app/src/main/webapp/WEB-INF/jsps/core/MainMenu.jsp (original)
+++ roller/trunk/app/src/main/webapp/WEB-INF/jsps/core/MainMenu.jsp Sat Aug 16 
22:45:32 2014
@@ -85,7 +85,7 @@
 
 

 
-   
+   
 
  
 


Modified: 
roller/trunk/app/src/main/webapp/WEB-INF/velocity/templates/feeds/weblog-comments-rss.vm
URL: 
http://svn.apache.org/viewvc

Re: 5.1 status

[Glen Mazza]

OK, now I'm done with the docs too, so done with everything.  If others 
on the team can start testing Roller trunk that would be good.


Dave, once the testing is all fine on your side, would you mind making 
the release artifacts for 5.1 to hold the vote?  The process has changed 
as we're now on svnpubsub for builds, I've updated the guide here: 
https://cwiki.apache.org/confluence/display/ROLLER/Release+Process, it 
would be good for you to go through it once.  If we have to make a 2nd, 
3rd, etc., set of artifacts until the vote passes (most likely due to 
coding errors I put in), I will take care of it from there.


Regards,
Glen


On 08/16/2014 09:37 AM, Glen Mazza wrote:
Trackbacks are working fine, so I'm done now, coding-wise.  Just 
checking the install guide right now...


Glen


On 08/16/2014 08:56 AM, Dave wrote:
Great! I will test against my site and the blogs.apache.org database 
today
and hope to update rollerweblogger.org to be running 5.1 sometime 
tomorrow.


- Dave



On Fri, Aug 15, 2014 at 10:39 PM, Glen Mazza  
wrote:


OK, I'm happy to report the first two items are done, also, Dual 
DB/Open

ID security seems to run pretty well so we'll have 4 auth options
(everything except CMA) available.  I just want to sanity check 
trackbacks

tomorrow and then I'll be finished on my side for 5.1.

Glen


On 08/13/2014 09:28 PM, Glen Mazza wrote:


Hi team, things I see left for 5.1 (at least on my side):

-- Creating a blog post from the MediaFileFromEdit view is inoperative
perhaps as a result of recent changes I made, I need to revisit it.

-- Need to make sure the User Admin and Edit Profile are showing the
correct fields depending on the security implementation (LDAP, 
OpenID, or
regular Database)--some have password fields, some don't etc.  (We 
may not
have Dual DB/Open ID ready for 5.1, I don't want to hold off a 
release for

that though.)  This is about halfway done.

-- Check that trackbacks work.  I've never used them before and would
like to make sure they basically work.

There are many other tasks that can be done, but those can wait for 
5.1.1
and onward.  So long as 5.1 is more solid than 5.0.4, we should be 
OK for a

release.

Regards,
Glen

Re: 5.1 status

[Glen Mazza]

Trackbacks are working fine, so I'm done now, coding-wise.  Just 
checking the install guide right now...


Glen


On 08/16/2014 08:56 AM, Dave wrote:

Great! I will test against my site and the blogs.apache.org database today
and hope to update rollerweblogger.org to be running 5.1 sometime tomorrow.

- Dave



On Fri, Aug 15, 2014 at 10:39 PM, Glen Mazza  wrote:


OK, I'm happy to report the first two items are done, also, Dual DB/Open
ID security seems to run pretty well so we'll have 4 auth options
(everything except CMA) available.  I just want to sanity check trackbacks
tomorrow and then I'll be finished on my side for 5.1.

Glen


On 08/13/2014 09:28 PM, Glen Mazza wrote:


Hi team, things I see left for 5.1 (at least on my side):

-- Creating a blog post from the MediaFileFromEdit view is inoperative
perhaps as a result of recent changes I made, I need to revisit it.

-- Need to make sure the User Admin and Edit Profile are showing the
correct fields depending on the security implementation (LDAP, OpenID, or
regular Database)--some have password fields, some don't etc.  (We may not
have Dual DB/Open ID ready for 5.1, I don't want to hold off a release for
that though.)  This is about halfway done.

-- Check that trackbacks work.  I've never used them before and would
like to make sure they basically work.

There are many other tasks that can be done, but those can wait for 5.1.1
and onward.  So long as 5.1 is more solid than 5.0.4, we should be OK for a
release.

Regards,
Glen

Re: 5.1 status

[Glen Mazza]

OK, I'm happy to report the first two items are done, also, Dual DB/Open 
ID security seems to run pretty well so we'll have 4 auth options 
(everything except CMA) available.  I just want to sanity check 
trackbacks tomorrow and then I'll be finished on my side for 5.1.


Glen

On 08/13/2014 09:28 PM, Glen Mazza wrote:

Hi team, things I see left for 5.1 (at least on my side):

-- Creating a blog post from the MediaFileFromEdit view is inoperative 
perhaps as a result of recent changes I made, I need to revisit it.


-- Need to make sure the User Admin and Edit Profile are showing the 
correct fields depending on the security implementation (LDAP, OpenID, 
or regular Database)--some have password fields, some don't etc.  (We 
may not have Dual DB/Open ID ready for 5.1, I don't want to hold off a 
release for that though.)  This is about halfway done.


-- Check that trackbacks work.  I've never used them before and would 
like to make sure they basically work.


There are many other tasks that can be done, but those can wait for 
5.1.1 and onward.  So long as 5.1 is more solid than 5.0.4, we should 
be OK for a release.


Regards,
Glen

Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?

[Glen Mazza]

I'm still not persuaded on the wisdom of retaining the userrole database 
table (#2 below), even if we skip the other proposals. However, as the 
team hasn't shown much enthusiasm in making changes to our permissions 
subsystem I'll let the matter drop, we'll keep Roller's security 
subsystem unchanged.


As I see it, the userrole table buys us the ability to assign multiple 
roles to the same user, a need that internally Roller has never had, as 
we just have two roles: editor and admin, and assigning a user the 
latter gives them the former's permissions.  So the only OOTB Roller 
need is to add a ROLE column to the roller_user table and it's all set, 
95%+ users are unaffected and have one fewer DB table in their model.


As we have so few permissions, basically just two coded: weblog and 
admin (even though we list four--including login and comment) there's 
not much need to assign multiple roles to a user, as one could just 
create a new role with the desired total permissions and give the user 
that role:


i.e., from:
role.names=editor,admin
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin

to:
role.names=editor,admin,aaa <-- new role "aaa"
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin
role.action.aaa=login,comment,weblog,bbb   <-- new role with new 
permission "bbb"


Even assuming we would want to give multiple roles to the same user, the 
same syntactic sugar can be had by allowing roles to be assigned to 
another role, allowing a user to still just have one role:


role.names=editor,admin,aaa
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin
role.action.aaa=editor, bbb (= login,comment,weblog,bbb)

Now if Roller were to be incorporated into a larger CMS solution with 
dozens of roles and hundreds of permissions (something where having 
multiple roles per user might be indicated), they are in all likelihood 
not going to be using our own simple userrole table but their own table 
anyway.


Whenever you add additional functionality that has to be maintained, 
other areas of the code begin to suffer (opportunity costs), so you have 
to make sure there's enough demand for the additional functionality, and 
that you gain more users than you lose due to other, more important 
areas getting less attention.  Also, people are naturally attracted to 
simple, easy-to-understand applications that take care of their needs 
with a minimum of bloat.  When we remove code and database tables that 
98% of users don't need, we gain more users just by having a leaner app 
than we lose.  And as for the 2% inconvenienced by having Roller 
slightly harder to hack for their unique needs, they would probably be 
more than compensated anyway due to the additional bells and whistles 
added to Roller that come naturally from having a larger user community.


Regards,
Glen


On 08/15/2014 11:27 AM, Glen Mazza wrote:
Thanks for the clarification, Anil, I didn't realize the difference 
between roles and permissions.


Glen

On 08/15/2014 10:34 AM, Anil Gangolli wrote:


I agree.  I think we should leave as is.

There may be confusion about the model in place:
*  specific permissions are checked on actions
*  roles are defined as sets of permissions
*  users are assigned roles
I think this is pretty conventional, and I think there's value in 
keeping with that.


--a.

On 8/14/14 11:40 PM, Greg Huber wrote:

Personally I would leave as is.  Having multiple roles/authorities per
action, is kind of useful if you want to extend roller.  The 
overhead is

also minimal compared with what struts does internally.


On 14 August 2014 23:35, Glen Mazza  wrote:

Does anyone else on the team have a view?  #5 below I'm no longer 
sure on

so I'm withdrawing that proposal but feedback on #1-#4 below is most
welcome.

Glen

On 08/13/2014 04:27 PM, Dave wrote:

I don't see the need for this change and I would leave those 
permissions

in
place. They existed to support and may still be used to support 
real uses
cases like private blogging, where only registered users can see 
blogs and

only those with special permissions can comment.

Even if they do not work fully now, they give people a way to hook 
their
own rules into their own custom versions of Roller, perhaps by 
adding new
code, ServletFilters, etc.  And they are a starting point for 
people who

want private blogging to be fully supported in Roller.

- Dave




On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza  
wrote:


  OK, checking Global Permission, we have these three levels:

  /** Allowed to login and edit profile */
  public static final String LOGIN  = "login";

  /** Allowed to login and do weblogging */
  public static final String WEBLOG = "weblog";

  /** Allowed to login and do everything, including site-wide 
admin */

 

Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?

[Glen Mazza]

Thanks for the clarification, Anil, I didn't realize the difference 
between roles and permissions.


Glen

On 08/15/2014 10:34 AM, Anil Gangolli wrote:


I agree.  I think we should leave as is.

There may be confusion about the model in place:
*  specific permissions are checked on actions
*  roles are defined as sets of permissions
*  users are assigned roles
I think this is pretty conventional, and I think there's value in 
keeping with that.


--a.

On 8/14/14 11:40 PM, Greg Huber wrote:

Personally I would leave as is.  Having multiple roles/authorities per
action, is kind of useful if you want to extend roller.  The overhead is
also minimal compared with what struts does internally.


On 14 August 2014 23:35, Glen Mazza  wrote:

Does anyone else on the team have a view?  #5 below I'm no longer 
sure on

so I'm withdrawing that proposal but feedback on #1-#4 below is most
welcome.

Glen

On 08/13/2014 04:27 PM, Dave wrote:

I don't see the need for this change and I would leave those 
permissions

in
place. They existed to support and may still be used to support 
real uses
cases like private blogging, where only registered users can see 
blogs and

only those with special permissions can comment.

Even if they do not work fully now, they give people a way to hook 
their
own rules into their own custom versions of Roller, perhaps by 
adding new
code, ServletFilters, etc.  And they are a starting point for 
people who

want private blogging to be fully supported in Roller.

- Dave




On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza  
wrote:


  OK, checking Global Permission, we have these three levels:

  /** Allowed to login and edit profile */
  public static final String LOGIN  = "login";

  /** Allowed to login and do weblogging */
  public static final String WEBLOG = "weblog";

  /** Allowed to login and do everything, including site-wide 
admin */

  public static final String ADMIN  = "admin";

We don't use "weblog" though, we save it as "editor" in the userrole
table.  We also don't use "login" for anything other than to make 
it the
minimum required setting on pages that don't require an ADMIN 
setting.

All
newly registered users are given "editor" as a minimum, meaning we 
could
raise minimum from "login" to "editor" and do away with the login 
role

without any difference in application behavior.

On top of this, we allow the roles additional subroles per the
roller.properties file:

# Role name to global permission action mappings
role.names=editor,admin
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin

"comment" is also never used in the application, further, in the 
above
list we're inconsistently assigning admin to admin but weblog to 
editor.

   Since the permissions are all Russian doll (login < comment <
weblog/editor < admin), it's sufficient to just store the highest 
role,

as
the lower ones are all implied, i.e., we don't need these properties.

My proposal is to:

1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
enumeration, EDITOR and ADMIN.  Later, if we have user demand for 
LOGIN

and
COMMENT, and somebody actually coding in logic that uses those 
values, we
can easily add in the enumerations for them.  (I don't like LOGIN 
much,

however, if we don't trust them not to blog they shouldn't be lurking
around the UI.)

2.) The "userrole" database table will be dropped, replaced with a 
new
varchar column ROLE in the Roller_User table.  I'll update the 
migration

script to copy the user's highest role into that column.

3.) The three properties "role.name, role.action.editor, and
role.action.admin" will be removed.

4.) List requiredGlobalPermissionActions() will return a 
single

enumeration constant instead (EDITOR or ADMIN), stating the minimum
accepted value.

5.) WeblogPermissions looks fine, except I'll just switch the string
array
of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same
values
and have requiredWeblogPermissionActions() return an enumeration
constant
instead.

How does this sound?  I have other things to work on so I'll wait 72
hours
before proceeding to give time for others to evaluate this change.

Regards,
Glen



On 08/13/2014 08:33 AM, Glen Mazza wrote:

  If the methods return just a single permission instead of a 
collection

of
permissions, at least for GlobalPermissionActions, that means we can
move
to "Russian doll" type role levels, where each permission level 
includes
all the permission levels below it (de facto the way Roller runs 
now).

If
we can officially be on that, that means we can toss out the 
userrole

table
and just place a single column "rolename" (indicating the highest 
role a

person has) in the roller_u

Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?

[Glen Mazza]

Does anyone else on the team have a view?  #5 below I'm no longer sure 
on so I'm withdrawing that proposal but feedback on #1-#4 below is most 
welcome.


Glen

On 08/13/2014 04:27 PM, Dave wrote:

I don't see the need for this change and I would leave those permissions in
place. They existed to support and may still be used to support real uses
cases like private blogging, where only registered users can see blogs and
only those with special permissions can comment.

Even if they do not work fully now, they give people a way to hook their
own rules into their own custom versions of Roller, perhaps by adding new
code, ServletFilters, etc.  And they are a starting point for people who
want private blogging to be fully supported in Roller.

- Dave




On Wed, Aug 13, 2014 at 3:51 PM, Glen Mazza  wrote:


OK, checking Global Permission, we have these three levels:

 /** Allowed to login and edit profile */
 public static final String LOGIN  = "login";

 /** Allowed to login and do weblogging */
 public static final String WEBLOG = "weblog";

 /** Allowed to login and do everything, including site-wide admin */
 public static final String ADMIN  = "admin";

We don't use "weblog" though, we save it as "editor" in the userrole
table.  We also don't use "login" for anything other than to make it the
minimum required setting on pages that don't require an ADMIN setting.  All
newly registered users are given "editor" as a minimum, meaning we could
raise minimum from "login" to "editor" and do away with the login role
without any difference in application behavior.

On top of this, we allow the roles additional subroles per the
roller.properties file:

# Role name to global permission action mappings
role.names=editor,admin
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin

"comment" is also never used in the application, further, in the above
list we're inconsistently assigning admin to admin but weblog to editor.
  Since the permissions are all Russian doll (login < comment <
weblog/editor < admin), it's sufficient to just store the highest role, as
the lower ones are all implied, i.e., we don't need these properties.

My proposal is to:

1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value
enumeration, EDITOR and ADMIN.  Later, if we have user demand for LOGIN and
COMMENT, and somebody actually coding in logic that uses those values, we
can easily add in the enumerations for them.  (I don't like LOGIN much,
however, if we don't trust them not to blog they shouldn't be lurking
around the UI.)

2.) The "userrole" database table will be dropped, replaced with a new
varchar column ROLE in the Roller_User table.  I'll update the migration
script to copy the user's highest role into that column.

3.) The three properties "role.name, role.action.editor, and
role.action.admin" will be removed.

4.) List requiredGlobalPermissionActions() will return a single
enumeration constant instead (EDITOR or ADMIN), stating the minimum
accepted value.

5.) WeblogPermissions looks fine, except I'll just switch the string array
of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the same values
and have requiredWeblogPermissionActions() return an enumeration constant
instead.

How does this sound?  I have other things to work on so I'll wait 72 hours
before proceeding to give time for others to evaluate this change.

Regards,
Glen



On 08/13/2014 08:33 AM, Glen Mazza wrote:


If the methods return just a single permission instead of a collection of
permissions, at least for GlobalPermissionActions, that means we can move
to "Russian doll" type role levels, where each permission level includes
all the permission levels below it (de facto the way Roller runs now).  If
we can officially be on that, that means we can toss out the userrole table
and just place a single column "rolename" (indicating the highest role a
person has) in the roller_user table, a very sleek change.  (I'm not
talking about Roller_Permission, i.e., permissions a user has on each blog
-- that table is still needed, but the userrole table indicating whether
one's a global admin or not.)

Glen

On 08/13/2014 07:54 AM, Dave wrote:


I don't have a strong opinion, but this seems like change just for the
sake
of change. I doubt that impacts performance in any significant way,
especially when compared to all the database calls that are made during
JSP
or page template processing.

- Dave


On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza 
wrote:

  Hi team, one or both of these methods are heavily called within the

application, indeed for almost every action run:

  public List requiredWeblogPermissionActions() {
  return Collections.singleto

Re: ampersand on search text

[Glen Mazza]

Hi Greg, that was done by Dave as part of this commit last August 13th: 
http://svn.apache.org/viewvc?view=revision&revision=151, which *may* 
have been part of the XSS security release Dave did the following 
November: http://rollerweblogger.org/project/entry/apache_roller_5_0_2.


It may have been a copy and paste error, checking in feeds.vm in the 
above commit he does a escapeHTML(removeHTML) but in the other an 
escapeHTML(escapeHTML).  One of the three files, SearchResultsModel() 
had no real changes, just the formatting was rearranged.


I would say we don't need to allow searching on punctuation characters 
(does Google even?) but if Dave doesn't respond and removing one of the 
escapeHTML calls fixes things without breaking more important stuff, 
perhaps good to go ahead with the change. Certainly, if it needs to be 
reapplied, next time we can put in a comment saying why the consecutive 
escapeHTML() calls are necessary.


Regards,
Glen

On 08/14/2014 04:03 AM, Greg Huber wrote:

Glen,

When I do a search containing and ampersand, roller does not show correctly
the returned text.

eg

b&z

actually returns :b&z

which renders  as b&z

It should return b&z with no second ampersand for it to render
correctly.

Checking the method getTerm() it does a double escape, where the
StringEscapeUtils.escapeXml(..) adds the extra  amp; causing it not to show
correctly :

SearchResultsModel():

public String getTerm() {
 String query = searchRequest.getQuery();
 return (query == null)
 ? "" : StringEscapeUtils.escapeXml(Utilities.escapeHTML(query));
 }

Do we need the double escape? For XSS?  StringEscapeUtils.escapeXml() or
how do we make it render correctly?


Cheers Greg.

5.1 status

[Glen Mazza]

Hi team, things I see left for 5.1 (at least on my side):

-- Creating a blog post from the MediaFileFromEdit view is inoperative 
perhaps as a result of recent changes I made, I need to revisit it.


-- Need to make sure the User Admin and Edit Profile are showing the 
correct fields depending on the security implementation (LDAP, OpenID, 
or regular Database)--some have password fields, some don't etc.  (We 
may not have Dual DB/Open ID ready for 5.1, I don't want to hold off a 
release for that though.)  This is about halfway done.


-- Check that trackbacks work.  I've never used them before and would 
like to make sure they basically work.


There are many other tasks that can be done, but those can wait for 
5.1.1 and onward.  So long as 5.1 is more solid than 5.0.4, we should be 
OK for a release.


Regards,
Glen

Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?

[Glen Mazza]

OK, checking Global Permission, we have these three levels:

/** Allowed to login and edit profile */
public static final String LOGIN  = "login";

/** Allowed to login and do weblogging */
public static final String WEBLOG = "weblog";

/** Allowed to login and do everything, including site-wide admin */
public static final String ADMIN  = "admin";

We don't use "weblog" though, we save it as "editor" in the userrole 
table.  We also don't use "login" for anything other than to make it the 
minimum required setting on pages that don't require an ADMIN setting.  
All newly registered users are given "editor" as a minimum, meaning we 
could raise minimum from "login" to "editor" and do away with the login 
role without any difference in application behavior.


On top of this, we allow the roles additional subroles per the 
roller.properties file:


# Role name to global permission action mappings
role.names=editor,admin
role.action.editor=login,comment,weblog
role.action.admin=login,comment,weblog,admin

"comment" is also never used in the application, further, in the above 
list we're inconsistently assigning admin to admin but weblog to 
editor.  Since the permissions are all Russian doll (login < comment < 
weblog/editor < admin), it's sufficient to just store the highest role, 
as the lower ones are all implied, i.e., we don't need these properties.


My proposal is to:

1.) Replace the above LOGIN/WEBLOG/ADMIN strings with a two-value 
enumeration, EDITOR and ADMIN.  Later, if we have user demand for LOGIN 
and COMMENT, and somebody actually coding in logic that uses those 
values, we can easily add in the enumerations for them.  (I don't like 
LOGIN much, however, if we don't trust them not to blog they shouldn't 
be lurking around the UI.)


2.) The "userrole" database table will be dropped, replaced with a new 
varchar column ROLE in the Roller_User table.  I'll update the migration 
script to copy the user's highest role into that column.


3.) The three properties "role.name, role.action.editor, and 
role.action.admin" will be removed.


4.) List requiredGlobalPermissionActions() will return a single 
enumeration constant instead (EDITOR or ADMIN), stating the minimum 
accepted value.


5.) WeblogPermissions looks fine, except I'll just switch the string 
array of EDIT_DRAFT, ADMIN, POST, to an enumeration constant with the 
same values and have requiredWeblogPermissionActions() return an 
enumeration constant instead.


How does this sound?  I have other things to work on so I'll wait 72 
hours before proceeding to give time for others to evaluate this change.


Regards,
Glen


On 08/13/2014 08:33 AM, Glen Mazza wrote:
If the methods return just a single permission instead of a collection 
of permissions, at least for GlobalPermissionActions, that means we 
can move to "Russian doll" type role levels, where each permission 
level includes all the permission levels below it (de facto the way 
Roller runs now).  If we can officially be on that, that means we can 
toss out the userrole table and just place a single column "rolename" 
(indicating the highest role a person has) in the roller_user table, a 
very sleek change.  (I'm not talking about Roller_Permission, i.e., 
permissions a user has on each blog -- that table is still needed, but 
the userrole table indicating whether one's a global admin or not.)


Glen

On 08/13/2014 07:54 AM, Dave wrote:
I don't have a strong opinion, but this seems like change just for 
the sake

of change. I doubt that impacts performance in any significant way,
especially when compared to all the database calls that are made 
during JSP

or page template processing.

- Dave


On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza  
wrote:



Hi team, one or both of these methods are heavily called within the
application, indeed for almost every action run:

 public List requiredWeblogPermissionActions() {
 return Collections.singletonList(WeblogPermission.x);
 }

 public List requiredGlobalPermissionActions() {
 return Collections.singletonList(GlobalPermission.xx);
 }

I've checked every implementation of both methods within the 
application

-- about 20-25 in all -- every one returns just a single permission
requirement, not a list of items.

I think it would be good to optimize these methods by having them 
return

just a string or a fast and lightweight enumeration constant. The only
thing lost I can see would be the ability to require multiple 
permissions,
but again within the app today and through 12-14 years of Roller it 
just

hasn't been needed.  WDYT?

Regards,
Glen

Re: simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?

[Glen Mazza]

If the methods return just a single permission instead of a collection 
of permissions, at least for GlobalPermissionActions, that means we can 
move to "Russian doll" type role levels, where each permission level 
includes all the permission levels below it (de facto the way Roller 
runs now).  If we can officially be on that, that means we can toss out 
the userrole table and just place a single column "rolename" (indicating 
the highest role a person has) in the roller_user table, a very sleek 
change.  (I'm not talking about Roller_Permission, i.e., permissions a 
user has on each blog -- that table is still needed, but the userrole 
table indicating whether one's a global admin or not.)


Glen

On 08/13/2014 07:54 AM, Dave wrote:

I don't have a strong opinion, but this seems like change just for the sake
of change. I doubt that impacts performance in any significant way,
especially when compared to all the database calls that are made during JSP
or page template processing.

- Dave


On Tue, Aug 12, 2014 at 9:15 PM, Glen Mazza  wrote:


Hi team, one or both of these methods are heavily called within the
application, indeed for almost every action run:

 public List requiredWeblogPermissionActions() {
 return Collections.singletonList(WeblogPermission.x);
 }

 public List requiredGlobalPermissionActions() {
 return Collections.singletonList(GlobalPermission.xx);
 }

I've checked every implementation of both methods within the application
-- about 20-25 in all -- every one returns just a single permission
requirement, not a list of items.

I think it would be good to optimize these methods by having them return
just a string or a fast and lightweight enumeration constant.  The only
thing lost I can see would be the ability to require multiple permissions,
but again within the app today and through 12-14 years of Roller it just
hasn't been needed.  WDYT?

Regards,
Glen

simplify requiredWeblogPermissionActions() and requiredGlobalPermissionActions()?

[Glen Mazza]

Hi team, one or both of these methods are heavily called within the 
application, indeed for almost every action run:


public List requiredWeblogPermissionActions() {
return Collections.singletonList(WeblogPermission.x);
}

public List requiredGlobalPermissionActions() {
return Collections.singletonList(GlobalPermission.xx);
}

I've checked every implementation of both methods within the application 
-- about 20-25 in all -- every one returns just a single permission 
requirement, not a list of items.


I think it would be good to optimize these methods by having them return 
just a string or a fast and lightweight enumeration constant.  The only 
thing lost I can see would be the ability to require multiple 
permissions, but again within the app today and through 12-14 years of 
Roller it just hasn't been needed.  WDYT?


Regards,
Glen

Re: Switch templateCode element to rendition in our theme.xml's?

[Glen Mazza]

OK, we've gone from:

 
standard
velocity
Weblog.vm


to:


Weblog.vm
velocity


Type is now an attribute of rendition, like action is of template, with 
a default of "standard" so it needs to be provided only when having 
multiple renditions like the basic-mobile theme.


Glen

On 08/12/2014 07:45 AM, Dave wrote:

Sounds like a reasonable change.

- Dave



On Tue, Aug 12, 2014 at 7:41 AM, Glen Mazza  wrote:


Hi team, I noticed most all of our themes in roller-extras (
https://code.google.com/a/apache-extras.org/p/roller-extras/wiki/Themes)
have an incompatible themes.xml, Roller trunk can't load them in. They need
to be updated, for example, from the Roller 5.0 and earlier here:

 
 weblog
 weblog
 
 false
 true
 text/html
 velocity
 Weblog.vm
 

... to the 5.1-style:

 
 weblog
 weblog
 
 false
 true
 text/html

 standard
velocity
 Weblog.vm
 
 [
  mobile
  
 ]
 

As part of updating them, I'm thinking of renaming the 
element above to  as the table storing them has been renamed to
custom_template_rendition and "renditions" is how they are referred to
within Roller code.  I think rendition also does a better job of clarifying
that the renditions are independent of each other, whereas templateCodes
can be thought of as cumulative, somehow working together.  WDYT?

Regards,
Glen

Switch templateCode element to rendition in our theme.xml's?

[Glen Mazza]

Hi team, I noticed most all of our themes in roller-extras 
(https://code.google.com/a/apache-extras.org/p/roller-extras/wiki/Themes) have 
an incompatible themes.xml, Roller trunk can't load them in. They need 
to be updated, for example, from the Roller 5.0 and earlier here:



weblog
weblog

false
true
text/html
velocity
Weblog.vm


... to the 5.1-style:


weblog
weblog

false
true
text/html

standard
velocity
Weblog.vm

[
 mobile
 
]


As part of updating them, I'm thinking of renaming the  
element above to  as the table storing them has been renamed 
to custom_template_rendition and "renditions" is how they are referred 
to within Roller code.  I think rendition also does a better job of 
clarifying that the renditions are independent of each other, whereas 
templateCodes can be thought of as cumulative, somehow working 
together.  WDYT?


Regards,
Glen

Re: Pull out CMA authentication from 5.1?

[Glen Mazza]

OK, for future expansion I'll keep the class and the 
AuthenticationMethod.CMA setting for others' use, but I won't be 
implementing it within the JSPs (you can though), i.e., password fields 
that need to appear or disappear based on the usage of CMA, that will be 
a function of how the users plan to implement it, and they can leverage 
what we have for the other three auth methods to figure out what to do.


Glen

On 08/11/2014 09:37 AM, Dave wrote:

-1 I don't see the harm in leaving a partial implementation in place, it's
only one class and comments its presence might be the spark that causes
somebody to fix it it.

- Dave


On Mon, Aug 11, 2014 at 8:23 AM, Glen Mazza  wrote:


Hi Team, I'm presently going through the user profile/create user/modify
user JSPs to make sure they are working correctly (e.g., fields
hidden/shown) for our three working auth methods, DB, LDAP, and OpenID.

We also have a nonfunctioning CMA auth mechanism, it consists of one class
(RoleAssignmentFilter) and a three or four old references within the
application and no web.xml or other configuration necessary to get it to
work.  I'd like to pull out that option for 5.1, until we get some user
demand for it, including a patch implementing it.  Users have the 5.0.4
source code for ideas on how to implement CMA, at least on older Tomcats,
but they'll need to do some research on how to hook it up to their
particular servlet container.  WDYT?

Regards,
Glen

Pull out CMA authentication from 5.1?

[Glen Mazza]

Hi Team, I'm presently going through the user profile/create user/modify 
user JSPs to make sure they are working correctly (e.g., fields 
hidden/shown) for our three working auth methods, DB, LDAP, and OpenID.


We also have a nonfunctioning CMA auth mechanism, it consists of one 
class (RoleAssignmentFilter) and a three or four old references within 
the application and no web.xml or other configuration necessary to get 
it to work.  I'd like to pull out that option for 5.1, until we get some 
user demand for it, including a patch implementing it.  Users have the 
5.0.4 source code for ideas on how to implement CMA, at least on older 
Tomcats, but they'll need to do some research on how to hook it up to 
their particular servlet container.  WDYT?


Regards,
Glen

simplify number of options for comment period?

[Glen Mazza]

Hi team, on the blog entry edit page, I sense we offer more options in 
our "Allow Comments [for number of days]" dropdown than are necessary 
for most business cases. I'd like to make that dropdown shorter and more 
week- and month-centric.  Instead of these options:


1,2,3,4,5,7,10,20,30,60,90,unlimited

I'd like to switch to these:
3,7,14,30,60,90,unlimited

I.e., 3-day short comment period, 1 week, 2 weeks, 1 month, 2 months, 3 
months & unlimited.


WDYT?

Regards,
Glen

remove the roller_userattribute table?

[Glen Mazza]

Hi team, I know we're trying to get 5.1 out but I see a nice database 
and code simplification possibility.  The Roller team created the 
roller_userattribute table as part of the Roller 4.0 to 5.0 migration, 
but through the years we've never needed it for more than its original 
purpose of storing OpenID values, and since most aren't using OpenID, 
it's hardly ever used.


In createdb.vm, I'd like to add a nullable "openid" column in the 
roller_user table and just drop the roller_userattribute table, and 
recode the app to read that column.  In the 500to510 migration script, I 
will keep this table in case users are using it for something else, but 
copy the openid values, if any, into roller_user.  WDYT?


The latest blogging tools such as those that post to GitHub Pages as 
well as wiki products like JSPWiki don't even use databases, so I want 
to make sure we keep the signal-to-noise ratio of our database pretty high.


Regards,
Glen

remove Acronyms plugin?

[Glen Mazza]

Hi Team, with our recent upgrade to HTML 5, the AcronymsPlugin created 
by Jaap van der Molen in 2004 is obsolete, as acronym tags are not 
supported in HTML5 (http://www.w3schools.com/tags/tag_acronym.asp).  The 
HTML 5 equivalent,  is quite nice 
(http://camendesign.com/code/using-abbr), and it would be trivial to 
convert the AcronymsPlugin to it, but I'm not sure enough % of people 
would use this plugin to warrant maintaining it.  For people who care 
about adding abbr tags to their text, they are hard to automate because 
sometimes you want the abbreviation and sometimes you don't, the 
abbreviation value changes depending on context, etc., and this plugin 
does a one-size-fits-all.


From the blog article linked above, the purpose of the  tag is 
to provide alternative spoken text in cases where the written is 
different from how you would speak it.  Examples given:  i.e. --> in 
other words; vs. --> versus; CSS --> style sheet, != --> does not equal.


This is how an  tag looks:

|CSS

|

Which makes it of comparable complexity to an anchor tag:



Regards,
Glen

Remove users.sso.passwords.save?

[Glen Mazza]

Hi team, we have a "users.sso.passwords.save" parameter in our 
roller.properties defined as follows:


# If you don't want user credentials from LDAP to be stored in Roller
# (possibly in clear-text) leave this alone, otherwise set to true.
# i.e. you would like a backup auth mechanism in case LDAP is down.
users.sso.passwords.save=false

Our security.xml does not support a fallback mechanism to rollerdb if 
LDAP is down, I doubt anyone wants to code that, and I'd rather we not 
be duplicating LDAP passwords within the Roller database anyway.  It's a 
security issue to store passwords in multiple places, plus companies 
normally require LDAP passwords to be changed every couple of months or 
so, causing the LDAP passwords being stored in Roller to fall out of sync.


If a company's LDAP server is down they'll have bigger problems than 
their blog server, and if they want to use LDAP they should have a 
backup solution already in place in case their LDAP server goes down.  WDYT?


Regards,
Glen

Re: Unable to compile JSP for Securibench Version

[Glen Mazza]

None whatsoever personally, I don't care to look into stuff that old.

Glen

On 08/01/2014 11:33 AM, Marc-André Laverdière wrote:

Hello Glen,

I certainly want to put much more recent packages in a new version of
securibench, and that probably will include a recent version of roller.

That being said, I see no problem having a mix of old and new. I'm sure
that there are webapps out there that haven't been significantly updated
since 2005 and it would be nice if I could analyze them too.

In the meantime, any clue about this escapeText?

Marc-André Laverdière-Papineau
Doctorant - PhD Candidate

On 08/01/2014 11:16 AM, Glen Mazza wrote:

Hi Marc-Andre, as far as I can tell that SecuriBench site hasn't been
updated in almost nine years, nearly all of it is probably obsolete.
You should try to find something more recent to work with on the 'Net,
if you can't do better than something from 2005 that would tend to
indicate that your approach to reference baselining is no longer common
today, and that some other approach should be used.

Anyway, that class below does not exist in modern-day Roller.  Your fix
would be to pull out that ancient Roller version and rely on the
remaining non-Roller packages there, or replace it with modern Roller
that you can download from our website.

Glen


On 08/01/2014 10:45 AM, Marc-André Laverdière wrote:

Hello,

Securibench uses an outdated version of Roller and it looks like
Tomcat's JspC isn't able to compile it anymore.
http://suif.stanford.edu/~livshits/securibench/

This is the error that I'm getting:
An error occurred at line: 42 in the jsp file:
/weblog/spellcheck-entry.jsp
escapeText cannot be resolved to a variable
39:
40: 
41: 
42: <%= escapeText %>
43: 
44: 
45: 


I would appreciate your help for a quick fix. I understand that this is
very very old code, and that few people know about it - and thus not
really interesting to maintain... But it is important for us security
folks to have some kind of reference baseline for testing our tools.

Your help is greatly appreciated.

Regards,

Re: problem with gaurav theme?

[Glen Mazza]

Oh, my bad then.  Thanks.

Glen

On 08/01/2014 11:31 AM, Gaurav Saini wrote:

Hello Glen,

The theme is working fine. I have tested it.
The thing you mentioned is actually the name of template mentioned in 
the theme.xml. You can see in the below  its the  that 
I included in weblog.vm and the file name is different mentioned as 



   
standard_header
Displayed in header of each page

false
true
text/html

velocity
   std_header.vm
   standard
   



Thanks
Gaurav


On Thursday 31 July 2014 07:18 PM, Glen Mazza wrote:

Hi Gaurav, I noticed in the weblog.vm of the gaurav theme:


#includeTemplate($model.weblog "standard_head")
...




#includeTemplate($model.weblog "standard_header")



Yet, the names of the files are std_head.vm and std_header.vm. You 
may wish to retest that it works if the above #includeTemplates are 
updated with the actual template names.


Regards,
Glen

Re: Unable to compile JSP for Securibench Version

[Glen Mazza]

Hi Marc-Andre, as far as I can tell that SecuriBench site hasn't been 
updated in almost nine years, nearly all of it is probably obsolete.  
You should try to find something more recent to work with on the 'Net, 
if you can't do better than something from 2005 that would tend to 
indicate that your approach to reference baselining is no longer common 
today, and that some other approach should be used.


Anyway, that class below does not exist in modern-day Roller.  Your fix 
would be to pull out that ancient Roller version and rely on the 
remaining non-Roller packages there, or replace it with modern Roller 
that you can download from our website.


Glen


On 08/01/2014 10:45 AM, Marc-André Laverdière wrote:

Hello,

Securibench uses an outdated version of Roller and it looks like
Tomcat's JspC isn't able to compile it anymore.
http://suif.stanford.edu/~livshits/securibench/

This is the error that I'm getting:
An error occurred at line: 42 in the jsp file: /weblog/spellcheck-entry.jsp
escapeText cannot be resolved to a variable
39:
40: 
41: 
42: <%= escapeText %>
43: 
44: 
45: 


I would appreciate your help for a quick fix. I understand that this is
very very old code, and that few people know about it - and thus not
really interesting to maintain... But it is important for us security
folks to have some kind of reference baseline for testing our tools.

Your help is greatly appreciated.

Regards,

Re: Consolidate the security properties in roller.properties?

[Glen Mazza]

Team, if no objections, I'm going to go ahead tomorrow with the new 
"authentication.method" flag, replacing the three below.


Regards,
Glen

On 07/30/2014 01:38 PM, Glen Mazza wrote:
Actually, this could wait for a future patch release, 5.1.1 or 
whatever, if desired.  Requiring a major release whenever we need to 
have users make a minor change to their roller-custom.properties file 
as a part of a Roller upgrade, as I suggested below, is major overkill 
for a small project such as ours.


Glen

On 07/29/2014 04:35 PM, Glen Mazza wrote:
Hi Team, it may be a good time for us to consolidate our security 
settings in roller.properties from our current three properties to 
just one.  It would be best to get such a change into Roller 5.1 
because for backward compatibility reasons we're not going to be able 
to put it into a subsequent minor patch release.


Presently we have three different security flags:

authentication.cma.enabled  = true/false  (i.e., tomcat-users.xml file)
users.sso.enabled = true/false  (i.e., LDAP)
authentication.openid = disabled/hybrid/only  (Roller DB only, either 
Roller DB or OpenID, OpenID only)


The problem with coding three properties where one will do is that 
security holes start to develop as we code with just one or two of 
the properties where we actually need all three.  Also, users may 
inadvertently set unsupported combinations of the three and as a 
result not get the security they're expecting. Finally, it's not 
obvious as it could be from the above settings the type of security 
offered by each setting.


I propose we switch to one flag in 5.1 called "authentication.method" 
and it will have only one of five possible values:


db  (use roller database, this will be the default value defined in 
roller.properties)

ldap   (equivalent to old users.sso.enabled=true)
db-openid  ("hybrid" above, users can use DB or OpenID but not both)
openid ("only" above, openID alone supported)
cma (= authentication.cma.enabled=true).

If "db" seems too terse/vague, we can use "rollerdb" instead to 
clarify the DB it's using.  If we have additional auth methods in the 
future, we'll add other constants, using hyphens such as "db-openid" 
above instead of additional properties if we're allowing multiple 
auth methods simultaneously.  [Incidentally, I'm not sure if 
authentication.cma.enabled (i.e., tomcat-users.xml file) even works 
in Roller today--the web.xml probably won't support it--but we have 
some coding for it within the application.  We may wish to pull this 
option out.]


Another advantage of this switch is that by leaving the ambiguous 
"users.sso.enabled" ("sso" can mean multiple things--OpenID, LDAP, 
CMA) and replacing it with an explicit "ldap" flag, we can possibly 
start moving towards LDAP security without the users needing to 
modify their security.xml, they would just need to configure their 
roller-custom.properties instead.


WDYT?

Regards,
Glen

ROL-1739 add a DB constraint?

[Glen Mazza]

Hi Team, re: https://issues.apache.org/jira/browse/ROL-1739, in 2008 a 
user reported a data error in the weblog-entry-tag-aggregate table that 
probably would have been immediately caught if we had a DB constraint 
preventing it.  Namely, a unique key constraint on the weblog and the 
tag name.  Since the purpose of this constraint is primarily to trap and 
fix a potential error in Roller, I wouldn't mind adding it just to the 
createdb.vm script but *not* the 500-to-510 migration script.  This way 
anybody with an invalid tag table can still do the upgrade (upgrades are 
going to be complex enough without this extra curve ball), while we'll 
find out about the tag aggregate table error, if it still exists, from 
new Roller users.


Alternatively, we can also just omit adding this constraint and closing 
the matter as a won't fix (especially if we're reasonably confident the 
tag aggregate table error has been fixed since then.) What I wouldn't 
want to do is keep this issue open anymore -- one way or another, let's 
get this one closed.  WDYT?


Regards,
Glen

Re: Remove XHTML Friends Network from our HTML headers?

[Glen Mazza]

All XFN references removed yesterday.

Glen

On 07/31/2014 01:15 AM, Anil Gangolli wrote:


+1

On 7/30/14 4:47 PM, Dave wrote:

+1

If people want XFN they can easily add it via custom templates.

- Dave



On Wed, Jul 30, 2014 at 7:45 PM, Glen Mazza  
wrote:



Hi Team, I'm in the process of updating Roller's HTML headers to HTML5.
  We have a profile referring to the XHTML Friends Network (
http://en.wikipedia.org/wiki/XHTML_Friends_Network) on several of our
headers:




http://gmpg.org/xfn/11";>
 

XFN looks out-of-date (http://gmpg.org/xfn/and/), maybe supplanted by
other social media tools today.  Anyone know, is this an antiquated
reference I should pull out of our HTMLs or are people still using 
it today?


Thanks,
Glen

problem with gaurav theme?

[Glen Mazza]

Hi Gaurav, I noticed in the weblog.vm of the gaurav theme:


#includeTemplate($model.weblog "standard_head")
...




#includeTemplate($model.weblog "standard_header")



Yet, the names of the files are std_head.vm and std_header.vm.  You may 
wish to retest that it works if the above #includeTemplates are updated 
with the actual template names.


Regards,
Glen

Remove XHTML Friends Network from our HTML headers?

[Glen Mazza]

Hi Team, I'm in the process of updating Roller's HTML headers to HTML5.  
We have a profile referring to the XHTML Friends Network 
(http://en.wikipedia.org/wiki/XHTML_Friends_Network) on several of our 
headers:





http://gmpg.org/xfn/11";>


XFN looks out-of-date (http://gmpg.org/xfn/and/), maybe supplanted by 
other social media tools today.  Anyone know, is this an antiquated 
reference I should pull out of our HTMLs or are people still using it today?


Thanks,
Glen

Re: Consolidate the security properties in roller.properties?

[Glen Mazza]

Actually, this could wait for a future patch release, 5.1.1 or whatever, 
if desired.  Requiring a major release whenever we need to have users 
make a minor change to their roller-custom.properties file as a part of 
a Roller upgrade, as I suggested below, is major overkill for a small 
project such as ours.


Glen

On 07/29/2014 04:35 PM, Glen Mazza wrote:
Hi Team, it may be a good time for us to consolidate our security 
settings in roller.properties from our current three properties to 
just one.  It would be best to get such a change into Roller 5.1 
because for backward compatibility reasons we're not going to be able 
to put it into a subsequent minor patch release.


Presently we have three different security flags:

authentication.cma.enabled  = true/false  (i.e., tomcat-users.xml file)
users.sso.enabled = true/false  (i.e., LDAP)
authentication.openid = disabled/hybrid/only  (Roller DB only, either 
Roller DB or OpenID, OpenID only)


The problem with coding three properties where one will do is that 
security holes start to develop as we code with just one or two of the 
properties where we actually need all three.  Also, users may 
inadvertently set unsupported combinations of the three and as a 
result not get the security they're expecting.  Finally, it's not 
obvious as it could be from the above settings the type of security 
offered by each setting.


I propose we switch to one flag in 5.1 called "authentication.method" 
and it will have only one of five possible values:


db  (use roller database, this will be the default value defined in 
roller.properties)

ldap   (equivalent to old users.sso.enabled=true)
db-openid  ("hybrid" above, users can use DB or OpenID but not both)
openid ("only" above, openID alone supported)
cma (= authentication.cma.enabled=true).

If "db" seems too terse/vague, we can use "rollerdb" instead to 
clarify the DB it's using.  If we have additional auth methods in the 
future, we'll add other constants, using hyphens such as "db-openid" 
above instead of additional properties if we're allowing multiple auth 
methods simultaneously.  [Incidentally, I'm not sure if 
authentication.cma.enabled (i.e., tomcat-users.xml file) even works in 
Roller today--the web.xml probably won't support it--but we have some 
coding for it within the application.  We may wish to pull this option 
out.]


Another advantage of this switch is that by leaving the ambiguous 
"users.sso.enabled" ("sso" can mean multiple things--OpenID, LDAP, 
CMA) and replacing it with an explicit "ldap" flag, we can possibly 
start moving towards LDAP security without the users needing to modify 
their security.xml, they would just need to configure their 
roller-custom.properties instead.


WDYT?

Regards,
Glen

Re: Permissions inconsistencies for an author w.r.t. Bookmarks and Categories

[Glen Mazza]

Taken care of -- Categories are now fully in control by authors, 
Blogroll items are admin-only.


Glen

On 07/29/2014 07:57 AM, Glen Mazza wrote:
Hi Team, we're inconsistent right now in what we allow folks with 
"author" permission to do -- currently:


Categories -- menu item is *visible*
-- they can't add categories (throws a permission error)
-- they can edit (rename) them
-- they can delete them

Bookmarks -- menu item is *invisible*
-- they can still add bookmarks if they know the URL
-- they can't edit them
-- they can't delete them

I'd like to make these consistent for each group above -- allow all or 
disallow all.  For Bookmark, shut off the ability for them to add a 
bookmark, as I guess it was never intended for them to be able to, as 
they don't have a bookmark menu option anyway.


For categories?  Because the author is not allowed to alter other 
presentation matters such as the theme or (apparently) bookmarks, I'm 
leaning that the task of configuring categories should remain with the 
Admin, let the author suggest to the Admin the categories that the 
blog should have.  I.e., take out the Categories tab for authors as 
well as their ability to edit/rename them.  Or, are we going to allow 
authors to modify categories?  In this case I'll need to open up 
Category Add for them to make it consistent.


Regards,
Glen

Consolidate the security properties in roller.properties?

[Glen Mazza]

Hi Team, it may be a good time for us to consolidate our security 
settings in roller.properties from our current three properties to just 
one.  It would be best to get such a change into Roller 5.1 because for 
backward compatibility reasons we're not going to be able to put it into 
a subsequent minor patch release.


Presently we have three different security flags:

authentication.cma.enabled  = true/false  (i.e., tomcat-users.xml file)
users.sso.enabled = true/false  (i.e., LDAP)
authentication.openid = disabled/hybrid/only  (Roller DB only, either 
Roller DB or OpenID, OpenID only)


The problem with coding three properties where one will do is that 
security holes start to develop as we code with just one or two of the 
properties where we actually need all three.  Also, users may 
inadvertently set unsupported combinations of the three and as a result 
not get the security they're expecting.  Finally, it's not obvious as it 
could be from the above settings the type of security offered by each 
setting.


I propose we switch to one flag in 5.1 called "authentication.method" 
and it will have only one of five possible values:


db  (use roller database, this will be the default value defined in 
roller.properties)

ldap   (equivalent to old users.sso.enabled=true)
db-openid  ("hybrid" above, users can use DB or OpenID but not both)
openid ("only" above, openID alone supported)
cma (= authentication.cma.enabled=true).

If "db" seems too terse/vague, we can use "rollerdb" instead to clarify 
the DB it's using.  If we have additional auth methods in the future, 
we'll add other constants, using hyphens such as "db-openid" above 
instead of additional properties if we're allowing multiple auth methods 
simultaneously.  [Incidentally, I'm not sure if 
authentication.cma.enabled (i.e., tomcat-users.xml file) even works in 
Roller today--the web.xml probably won't support it--but we have some 
coding for it within the application.  We may wish to pull this option out.]


Another advantage of this switch is that by leaving the ambiguous 
"users.sso.enabled" ("sso" can mean multiple things--OpenID, LDAP, CMA) 
and replacing it with an explicit "ldap" flag, we can possibly start 
moving towards LDAP security without the users needing to modify their 
security.xml, they would just need to configure their 
roller-custom.properties instead.


WDYT?

Regards,
Glen

upgrading to HTML5...

[Glen Mazza]

We're fine to upgrade to HTML5 now, correct?  I checked 5 sites 
(Bootstrap, JQuery, Foundation, CNN & our JIRA) and they are all on that 
standard.  It appears just a header switch in our tiles-*.jsp is all 
that's needed, as the closing tag stuff that's used in XHTML is still 
supported although not encouraged.


Glen

Re: Upgrading fauxcoly theme to Foundation CSS

[Glen Mazza]

Yes, I did upgrade from YUI2 to YUI3, but found that YUI3 is just very 
inconvenient/clumsy to keep in a web application (one file per folder, 
70-80 files, 70-80 folders, no SSL CDN.)  Plus I need to learn JQuery...  :)


Glen

On 07/29/2014 01:23 PM, Gaurav Saini wrote:

Hello Glen,

Yes, I still remember that issue that is why I though of adding to 
this theme. Also, It good to add to velocity/weblog.vm so all themes 
can use it.


Thanks for appreciation :)
Ok. I will place the widgets to the right side and will see that in 
mobile it comes to the left. For now we can leave rate this template, 
I just places to occupy the space.


So, the YUI3 is gone. Isn't that we were thinking of upgrading from 
YUI2 to YUI3 or I missed out of some discussion ?

Yes, once theme is ready we can get rid of YUI3 folder definitely.

Regards,
Gaurav

On Monday 28 July 2014 08:29 PM, Glen Mazza wrote:
Hi Gaurav, can you see to it that the updated Fauxcoly theme does 
*not* use YUI3's CSS grids -- it's the only thing in Roller using it 
today and we can get rid of its folder 
http://svn.apache.org/viewvc/roller/trunk/app/src/main/webapp/roller-ui/yui3/ 
once it's gone from the theme.


Thanks,
Glen


On 07/28/2014 09:39 AM, Gaurav Saini wrote:

Hello Matt,

Yes, definately I will add some widgets to the right. For now I have 
just made it in html so some rough mockup.
There is a tree in the bottom (blog archive widget). I am planning 
to include that in the theme. What you think about it, wordpress and 
blogger already have this type of tree.


If you have some more ideas, Please let me know. I want to make it 
look great :)


Thanks
Gaurav

On Monday 28 July 2014 06:57 PM, Matt Raible wrote:
I think it looks OK, but maybe there should be something more under 
the

search on the right. Perhaps a tag cloud or most recent posts listing?


On Mon, Jul 28, 2014 at 7:23 AM, Gaurav Saini 


wrote:


Hello Team,

As discussed before, about upgrading the fauxoly theme to 
Foundation CSS
framwork. I have prepared initial rough mockup of the theme. I 
tried to
have it similar to old theme with a large background image on the 
top.


Please get in with some reviews about it. So, I can go forward 
with it.
(Its responsive in nature and adapts well on mobile and tablets 
also.)


http://awesomescreenshot.com/0ee37zej4b

Note: Original Foundation components (buttons, icons, and other css
components might look a bit different).

--
Regards,
Gaurav Saini
Developer and Internet Marketing

Permissions inconsistencies for an author w.r.t. Bookmarks and Categories

[Glen Mazza]

Hi Team, we're inconsistent right now in what we allow folks with 
"author" permission to do -- currently:


Categories -- menu item is *visible*
-- they can't add categories (throws a permission error)
-- they can edit (rename) them
-- they can delete them

Bookmarks -- menu item is *invisible*
-- they can still add bookmarks if they know the URL
-- they can't edit them
-- they can't delete them

I'd like to make these consistent for each group above -- allow all or 
disallow all.  For Bookmark, shut off the ability for them to add a 
bookmark, as I guess it was never intended for them to be able to, as 
they don't have a bookmark menu option anyway.


For categories?  Because the author is not allowed to alter other 
presentation matters such as the theme or (apparently) bookmarks, I'm 
leaning that the task of configuring categories should remain with the 
Admin, let the author suggest to the Admin the categories that the blog 
should have.  I.e., take out the Categories tab for authors as well as 
their ability to edit/rename them.  Or, are we going to allow authors to 
modify categories?  In this case I'll need to open up Category Add for 
them to make it consistent.


Regards,
Glen