Release Management Case Study - Formerly "Styling Fixes"

Thank you! This helps a lot. I'm not at my computer right now, but I can see how the changes are part of the style much better now.

 

heads up, I added a picture above, showing where the birthday field is stopped from being displayed.

 

It would be extremely unfair to you or anyone to have to find those changes without being provided details like those.There are too many different ways it could be done, having to distinguish my changes from those templates would have been a really horrible assignment.

 

i am sure you will not hate seeing this...

 

What do the asterisks mean?

 

Lots to do here.

I'll start by documenting my explorations of the changes to the log in page. I think I understand how that worked now.

Here are the changes to the register_form that you showed me:



Finally! I understand how that part works.



Therefore, if the path to dansSupplements is present in the PAGE_CONTAINER template, like so:



And, dansSupplements is where it belongs on my server in the dev directories:



This should work ...



This was not agony, because I'm beginning to understand how things fit together better now.
In fact, I'm going to have to explore PAGE_CONTAINER a bit more, because it might contain the solution to some of my other styling troubles.
But now, I'm going to check out the new arrangement, which eliminates the supplements and styles the login page within the .xml file.

(And I finally figured out how to use the find on page function in my browser. Doh! Searching templates is a snap now. )

 

The asterisks denote styles that are only available to admins. They should not be appearing to ordinary visitors.


We can set these up in the styles menu.



You can see what this looks like on the styles page. The styles with the strikethrough on the text are available only to admins (and will show the asterisk in the style menu.)

 

Nice! I reproduced removing the link to the external css supplement, and instead copied the supplement from my server and pasted it into the EXTRA.css template.



Here is the supplement file:


Here is the addition to the EXTRA.css template:



And, to be sure that my changes 'take', I need to remove the old way of doing this:



Success!!

This helps me a lot. I now understand why the styles weren't coming over to dev the way I expected, and I understand how to fix that. I'm going to download the present style we have now and start looking at some of the other problems we are having.
BTW, I am presently on Longview 1.3.1, and I noticed that we are back to Longview 1.3 as the default style? Is there a reason for that?

 

I agree with this recommendation. Other than getting this style into better shape, my other objective is to become more proficient with css as I work through this. Having you show me what you did, and then incorporating those changes into my updated version is a good way for me to do that. For that reason, redoing the changes is no big deal, and besides I may have my own ideas about how to improve the visibility of certain items into the style. For example, going through the changes in the log in page and removing the link to an external file today helped me understand a lot more about how the styles work.

The log in page though is one page that I think is critical to get right, and that is why I wanted to pay particular attention to it.

In the meantime, I'm hoping you can point me in the direction of making this change to my dev version:



Putting an inline style in place seems like a quicker way to get around all those classes I can't track down, at least in the short term. However, I'm puzzled about why I can't find it in the .xml. (I'm sure it will seem obvious once I see it in action, but that is just how things seem to go!)

 

Page container has a ton in it that is a fact.


THANK YOU!!!! That was stumping me totally.

I have been running 1.3, not 1.3.1.... I don't know if that is what I should do.

You could be Albert Einstein teamed with Charles Darwin in the CSS world, and you still would need changes by other programmers spelled out for, not because you could never get it to work, but changes must be documented for the release manager, which for this CSS is you. Believe me ,I always want to be the one that makes things work, but that is a bad attitude for what lies in front of us.

This post is continued here.

 

So, right now I have two changes that I noticed are not showing up in my dev version of the style.

The first is the terms of service page that I indicated above.
Mine looks like this:



And ours here looks pretty nice. (see above)

Then I noticed the Captcha box is the preferable "I'm not a robot" version here:



While my version still has the old 'try to read the random street sign' thing:

 

TERMS OF SERVICE.

I did something kind of different on that one. I think I can find it.

Oh yes! Now I remember. I did some googling and found out how to edit terms of service, and then put a style in there. Terms of service is phrase in xf.





For the captcha, you have to enter keys that are specific to domain where you are running. So you need from google, because it is there captha thing. The are free and easy to get. Google Recaptcha, what you want is to get recaptcha. There is a place where you enter your domain name and they give you the keys and you enter into place in xf where they ask them.












These are the keys now in 21C

 

That's cool! And really easy to do.
I bet I can fix a lot of things up around here that way. The only thing about it is that it isn't part of the style, so it doesn't come over to dev that way.



So, luckily I had figured out a way to fix it by changing the colors on the baseHtml class, which also fixes the other Help pages.





I'm thinking I should go with my fixes on the baseHtml class instead of your inline one, since the css fix is saved with the style template? I'll increase the font size on the final version.

But, your way is still a really handy way to get things looking good fast without spending a bunch of time digging through templates.

 

I hardly ever use inline styles for that reason. At the time, I didn't think of another way, because the terms of service do not have their own class or id. I could have added a class instead of the inline style and then put the css for the class into extra.css. I am going to do that now.

 

It worked

 

The reCaptcha was easy too. I pasted in the keys like you showed in the screenshots, and there it was.









I was wondering about Steps 1 and 2 after the Keys on the reCaptcha page, since I didn't see the codes for those in the page source. Are they integrated into XenForo? Is that why I could just enter the keys and there was my reCaptcha verification?

(And, oh look, now I'm the one writing posts but forgetting to post them! I wrote this up yesterday, and found in the draft mode today. )

 

I've been trying to fix that 'view recent posts' problem forever.
This fixed it:

• Adding the class:

​

• Specifying a new color in EXTRA.css:

​

• Checking my work:

​

CSS and I are buddies again.

 

And, because the css that changes the color for that new class is only in the Longview template, the default style is unaffected. (The inline styling affected all the styles including the Default style.)




Only one thing that is less cohesive about this is that class that I added for the phrase is not part of the style, and must be entered manually.

 

I made a copy of the Longview 1.3 style tonight, and loaded it onto my dev version so I can start making some changes to improve the usability and the look of it.
If you make any changes to the style here, I'd appreciate it if you let me know so I can incorporate them into this next version.

 

Longview 1.3.1 is ready for action!

​

Some features of my latest styling improvements:​

​

I still have work to do on this, but I wanted to put up an intermediate style in the meantime.

It should be okay to make it the default style, but I want to use it for a few days first to catch any errors before I do that.