I am having problems with the views_php module when viewing any views with a field for Global: PHP. I see one use of this field type is to display the dates in a particular way within the Events. For dates, wouldn't a user specified date format be more appropriate? You can add a new format here admin/config/regional/date-time/formats

Another use of this field type was for rewriting other fields. I would think the Global: Custom text field type could be used for this.

The only view that I am seeing that may not allow the removal is the latest blog view. It is using the Global: PHP field to add a link to the blog archives within the header of the view.

What do you think?

CommentFileSizeAuthor
#13 Remove-views-PHP-dependency.zip703.05 KBCode Monkey

Comments

drupalninja99’s picture

drupalninja99 commented

So far I see this in 5 places:

1. Events for rewriting dates, I agree with your assessment. I did this for expediency but I should go back and do it the right way.
2. Homepage rotator - yes I can convert this to global: custom text
3. Blog - I can just hardcode this as a normal link in html
4. Podcasts - this is the date reformatting issue
5. Gallery - this is the link thing again, I can change to a normal html link

OK this sounds pretty doable. I wish I had some help (*ahem*) but I think I can get this resolved.

Code Monkey’s picture

Code Monkey commented

What can I do to help?

drupalninja99’s picture

drupalninja99 commented

I need to look at this again bc I definitely need php sometimes in the header, but I should kill the fields that use it for date reformatting for sure or places where global: custom text would work.

Code Monkey’s picture

Code Monkey commented

You could use the text format of PHP Code within a Global: Text Area if you still need to have PHP within the view. Just a thought.

drupalninja99’s picture

drupalninja99 commented
Status: Active » Needs work

Adding to the roadmap bc this is an important 'maintenance' issue that needs to be cleaned up. I will replace all the views php fields with more appropriate fields.

drupalninja99’s picture

drupalninja99 commented
Priority: Normal » Major

Changing priority

Code Monkey’s picture

Code Monkey commented

How would you name the new date format? I would like to see if I can modify the views to get this fixed.

drupalninja99’s picture

drupalninja99 commented

Suggestions?

Code Monkey’s picture

Code Monkey commented

Machine name: openchurch_event_date
readable name: Openchurch Event Date
Format to match the current views_php format.

How does that sound?

drupalninja99’s picture

drupalninja99 commented

I think podcast has the same issue, so maybe just openchurch_short_date.

Code Monkey’s picture

Code Monkey commented

Will do. Do I just need to export the views for you? What would make this easiest for you?

drupalninja99’s picture

drupalninja99 commented

Ya re-export the whole feature, I can manually reconcile the view/.info file. the openchurch_short_date deal would probably be a strongarm variable inside of openchurch_defaults I am thinking.

Code Monkey’s picture

Code Monkey commented
Status: Needs work » Needs review
StatusFileSize
new Remove-views-PHP-dependency.zip703.05 KB

Here is a zip file containing the exported features.

You will want to check the default feature to make sure the superfish error is fixed. I manually modified the included strongarm file to fix the error.

drupalninja99’s picture

drupalninja99 commented

Excellent, ya I am going to go through these and merge changes

drupalninja99’s picture

drupalninja99 commented

Ya these look pretty good, I have the oc short date in my defaults info and strongarm but for some reason on my local tests it isn't initializing when I run the install. Troubleshooting for the moment.

drupalninja99’s picture

drupalninja99 commented

OK I got this working in head now.

Basically the strongarm stuff wasn't working for the date, there are additional pieces to it. So I opted to put that code in the openchurch_defaults.install file as opposed to trying strongarm.

I also added an _update_N() hook as I would like to have a consistent upgrade path so that people can upgrade cleanly from one version to the next.

I had to make a small fix to the podcasts view which had a couple small bugs in it but now that is looking correct. I haven't removed the views php module or anything, it has basically just been 'deprecated' since we are no longer using it.

drupalninja99’s picture

drupalninja99 commented
Status: Needs review » Fixed

This is fixed in alpha3

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.