Disadvantages of changing to php?

RapidWeaver Classic Stacks
1

I want to tailor information on my website based on type of device.
The Mobilize stack of stacks4stacks requires to change to php.
Is there any general disadvantage to change to php?

2

None whatsoever. Lots of stacks use PHP. And billions of webpages use PHP too - not forgetting that it is the default page format of publishing platforms like Wordpress.

All that the .php file extension does is tell the web server that there is PHP code in the page, that needs to be processed before the page is sent down to the web browser.

Contrary to what a couple of very misleading posts on this forum have suggested in the past, changing a file extension to .php has no impact on page loading speed, SEO, user privacy, accessibility or any other factors. It is perfectly safe to do.

Generally I would only recommend using a stack like Mobilize as a last option. If it’s possible to create a website that can be seen and used by all devices, then that’s a lot better for everyone.

Mobilize was formerly developed by Nimblehost and is now over a decade old. Nowadays most themes and stacks for RapidWeaver are mobile compatible. The only use I can think of for Mobilize would be if you had a really specialist plugin or script in a webpage that was impossible to get working on tablets and mobiles. I know I am probably killing myself some sales by saying this, but that is my totally honest opinion!

If you need to display specific banners for Android and iOS, then another option you have is the free AppBanner stack:

3 Likes
3

One thing I always do in my projects is set the default extension to always be PHP. This will help eliminate headaches when adding a stack that uses PHP and changes your page from HTML to PHP.

3 Likes
4

Thank you,

my problem is that I have want to have very compact websites with some videostacks +…
The idea was triggered by Agent stack of Mr. Workman, who outlined that in RW stacks
could be hide but still send to the device.

The proposal was to send only a smaller gallery, I am using pro gallery, to a mobile
then to a desktop, assuming that mobile have lower speed. However, I agree with you fully
to design one page with proper responsiveness setting is the most streamlined approach.

But my website addresses Pakistan where we partially have excellent but as well partially
very bad net. So my dream would be to send simpler versions of my page, with less effects,
in case of slow net. But as I could not fins any stack for this purpose I assume that there
is no solution.

Or what do you recommend?

| willwood Will Woodgate Addon Developer
November 16 |

  • | - |

sb-webadmin:

Is there any general disadvantage to change to php?

None whatsoever. Lots of stacks use PHP. And billions of webpages use PHP too - not forgetting that it is the default page format of publishing platforms like Wordpress.

All that the .php file extension does is tell the web server that there is PHP code in the page, that needs to be processed before the page is sent down to the web browser.

Contrary to what a couple of very misleading posts on this forum have suggested in the past, changing a file extension to .php has no impact on page loading speed, SEO, user privacy, accessibility or any other factors. It is perfectly safe to do.

Generally I would only recommend using a stack like Mobilize as a last option. If it’s possible to create a website that can be seen and used by all devices, then that’s a lot better for everyone.

Mobilize was formerly developed by Nimblehost and is now over a decade old. Nowadays most themes and stacks for RapidWeaver are mobile compatible. The only use I can think of for Mobilize would be if you had a really specialist plugin or script in a webpage that was impossible to get working on tablets and mobiles. I know I am probably killing myself some sales by saying this, but that is my totally honest opinion!

If you need to display specific banners for Android and iOS, then another option you have is the free AppBanner stack:

Stacks4Stacks

AppBanner

Displays customisable app store advertising banners for Android and iOS devices. For apps, podcasts, audio downloads and video streaming

5

I am now using the Agent Stack as it works perfectly (I used different solutions before) and I have all my sites running on PHP (or GSP/JSP), there’s no impact on SEO and so ever, just think of the billions of commercial sites and blogs using PHP (actually, it’s still the Apache HTTP server delivering the pages, PHP is just replacing the dynamic parts).

If you’re refering to “responsive sites”, I disagree here: it’s only easier for the developer, that’s all.

Desktop and Mobile have different approaches in usability, navigation and content. It’s a different way to consume the content. CTAs need different wording, Texts needs to be shorter, written in a different way, etc. Just placing some columns differently and moving the main navigation into a burger menu is not really a mobile solution. Images, Videos, Buttons also work differently on a mobile, it’s a whole different user experience.

If you try to archieve this by showing / hiding stacks, you send over two separate pages at the same time, that’s a challenge for mobile users with limited bandwidth (just take your mobile and access your pages from the sub or bus), limited data (sending 10mb of not used desktop data only to let the browser decide what to display…)

1 Like
6

Browser “sniffing” and redirecting different users to different webpages (based on their device) is no longer reliable and most web design agencies and companies have abandoned this method. The popularity of RWD (responsive web design) is indisputable, as the alternative.

Recently Apple has changed the user agents on their new iPads and iOS updates so that they identify themselves as ‘desktop’. So straight away, anybody arriving on a website using a newer iPad risks getting the desktop version of the website! And certain Android / Huawei branded devices are starting to go the same route too. Conditionally serving content or redirecting users based on their browser user agent is no longer something to rely upon.

Think also about website accessibility. This is a taboo topic that a lot of people don’t like to talk about and many RW built websites fail miserably at achieving. But work on the notion that if you have things in a website that only look or work better on particular devices, there is a danger you could be discriminating against people with disabilities too. And that is something you really want to avoid.

So I would tend to always go with the “simple is best” approach. Work on engineering a “one size fits all” solution that everybody benefits from. A single website anyone can access, regardless of browser, device, internet speed, disabilities and other factors.

With ProGallery, it is possible to build some fairly large galleries that can still be loaded over slower internet connections. You have the choice to provide small thumbnail images that load quicker. All versions of ProGallery support lazy-loading. And content types like iFrames and video are only loaded on demand, when the lightbox opens. If you want to email me a link to a page you have built with ProGallery, I can certainly give you some advice on ways you can make it available to all your website users.

2 Likes
7

That’s exactly what browser agents are created for. Due to the nature of RW (and Stacks) it might not look very common to the RW community, but I can’t remember a single project in my last 20 years of (e-commerce) web development, where browser agents (and accept headers) didn’t play a huge role.

This is a very welcomed decision in the developer community as (especially WITH responsive design) to exactly serve this purpose: delivering the right content to the right device.

You’re right, if a developer would only check the user agent.
But if you go this route (using some of the common libraries) other conditions are checked too, such as navigator.maxTouchPoints .

You’re simply advising to agree on the lowest common denominator.
So at the end, you’re limiting the desktop user excperience to sacrifice the mobile use case.
This is simply not practical.

So my advice is:

  • serve thougfully designed sites for the device class you are targeting (desktop / tablet / mobile phone)
  • within each device class, use responsive technologies to deliver the content the best way, e.g. different desktop sizes, tablet screen sizes and mobile phones (think of a iPhone 5 over a Samsung Galaxy Fold - okay, two extremes)
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.