Sorry this has taken a long while. It’s been a very busy week for me and Steve has had family staying of course.

OK – all four look good except for where you have asked a specific question. So…

sp_ProfileEditButton()
You are correct that the first filter does not adhere to the correct nomenclature. I have opened a ticket and committed a fix ready for 5.4.2. So please correct the codex page as well to include the missing ‘Edit’.

sp_RecentPostList()
Please remove the second filter form the codex page as this particular function does not and should not have one. it is an exception to the more general principle. The call to the data collection (spTopicList) has it’s own data filters and calls to templates (sp_load_template) should contain templates changes if required. Adding a filter would be hard to use and redundant. So – that is why ot is not there.

Thanks again Ken. Looking good. And after these changes ready to publish. And thanks for finding the odd anomaly…

Thanks for the review.  Before I publish sp_ProfileEditButton(), please answer the following question.  Should I publish the page as it has been updated or make the “Edit” change and then publish?  Please see below. 

sp_ProfileEditButton()
Point of Procedure item:  If the code currently published and available to the users of this codex does not have the “Edit” change in sp_ProfileEditButton(), would it be prudent to publish the codex page as it has been updated and to add the codex “Edit” change to the ticket for the code change?  The codex change would then be timed to the release of the new code with the ticket being closed when both changes are made.  Would it be better to open a separate ticket associated with the codex change?

sp_ColumnEnd() codex page has a similar update to be done after the next Build is published.  Steve has written a ticket to change the code by adding “_” to do_action(‘sph_ColumnEnd’.$columnName, $a) so it becomes  …ColumnEnd_’.$….  The updated codex page was published awhile back without the change included in it.

I am not sure if the ticket for the sp_ColumnEnd() code change also called out a codex change.  Maybe I am just supposed to remember to make the change when the Build is published. 

This does raise the configuration question regarding keeping the currently published code and the codex sync’d.  An additional point is how to inform the users working with older Simple:Press versions that the codex as updated no longer applies to their version. Let me know if these are too low on the priority list to worry about.

sp_QuickLinksForum()
Sorry, I didn’t mean to enter it twice in the list to review. Its 2nd entry was supposed to be sp_QuickLinksTopics(). I will put sp_QuickLinksTopics in a separate Topic for review in the near future.

On the points in your first post my own personal view is that you make the change now and publish in the knowledge that within a couple of weeks or so the new code will be released. But – that you mark the change in the changelog section against version 5.4.2.

Actually this also raises the question about the changelog section itself. As it says on the actual code, the mobileMenu argument was actually added in 5.2.0 and is not part if the original 5.0 code. I am not sure of this matters now but I think we should use that section ion the future.

I thought the repeat of spQuickLinksForum() was probably a simple typo!

Andy,

Did you look at sp_QuickLinksTopics() during your reviews and just not indicate it in your response?  If so, did you consider it ready to publish? 


To the group,
If this should be a separate topic, let me know and I will generate a new topic.

Please agree upon the desired configuration change standard for the codex pages as well as the overall change history concept.  Below are a few questions that may help the group decide what is desired.  I will begin incorporating the standard into future updates once it is decided upon.   
1. Shall the change information with Build number from the code headers as well as expected future changes with their anticipated Build number be added into the change area of the codex page? 
2. What is the standard header for the change area in the codex pages?  - "Change Log" or "Changelog" 
3. Will future header change information be written for direct/ near direct transfer into the codex change area?
4. Should an entry be made on the codex page indicating the Published Build version code used when the page was reviewed/updated?
5. Other considerations?

Just trying to "keep the customer(s) satisfied."

published sp_QuicklinkTopics…

couple comments shooting from the hip…

1 – not the build number, but the version number…

2 – I prefer changelog which seems to be ‘standard’ for code stuff (and supported by wikipedia http://en.wikipedia.org/wiki/Changelog)

3 – not sure I follow… are you asking if changes to code files will auto transfer to codex pages?  if so, no… would be nice, but would take some effort to add such automation…

4 – like this idea… but would think it would have to have a method for occurring (adding and removing) auto… seems like logistical nightmare to manage by human…  might be a wp plugin for this…

3 – Asking if the developers will write explanation of change in a manner that can be copied and pasted into the Changelog section.

4. See item 5 below for my attempt at a manual near-term solution.  Change it or delete it as appropriate. 

Based on inputs received, the below strawman changes were made.  Someone please approve or change it until it can be considered the new standard for the codex pages.

sp_ProfileEditButton()
1. Ready to publish after review if acceptable; otherwise please change.
2. apply_filters(‘sph_ProfileEditButton_args’, $a) replaced apply_filters(‘sph_ProfileButton_args’, $a) [planned for 5.4.2].
3. Changelog replaced Change Log.
4. Changelog updated with previous changes from function header in code and planned 5.4.2 change.
5. Changelog entry added to define when codex page was sync’d with code.

Thanks.  I look forward to finalizing this aspect of the codex.

looks fine to me!!  published…

Thanks.  More to come tomorrow.

oh joy 😉  will be waiting…