SEO Friendly URLs in Scipio ecommerce


#1

I noticed that the current version of scipio does not (seem) to have any SCO features, like “ecomseo”.

There seems to be SEO menu items under Catalog::Store::Websites:Website_id

https://ce.scipioerp.com/catalog/control/EditWebSite?webSiteId=ScipioWebStore

But after selecting “Generate Missing SEO URLs”, it doesn’t APPEAR to do anything. I even analyzed the database for changes.

Can this be clarified?


#2

The SEO-like URL handling and functions are in the process of being reviewed. That one is currently the stock behavior. It only creates new ALTERNATIVE_URL records for categories and products that don’t already have them. The demo data has these records for almost all products already so it may not do much for it. If you mean your own data, maybe something is missing…


#3

Doesn’t seem to work. The demo store has this:

select product_id,content_id,product_content_type_id from product_content where product_content_type_id=‘ALTERNATIVE_URL’;
product_id | content_id | product_content_type_id
-> -----------------±---------------------±------------------------

PH-1000 | PH-1000-ALT | ALTERNATIVE_URL
PH-1001 | PH-1001-ALT | ALTERNATIVE_URL
PH-1004 | PH-1004-ALT | ALTERNATIVE_URL
PH-1005 | PH-1005-ALT | ALTERNATIVE_URL
SW-1006 | SW-1006-ALT | ALTERNATIVE_URL
SW-1006-1 | SW-1006-1-ALT | ALTERNATIVE_URL
SW-1006-2 | SW-1006-2-ALT | ALTERNATIVE_URL

When I update SEO (products), it only creates two records (even though I have 800+)

10000-798936836182 | 10002 | ALTERNATIVE_URL
10000-798936823571 | 10003 | ALTERNATIVE_URL

The “1002” and “1003” are the category IDs. I would expect it to create content_id(s) similar to “10000-798936836182-ALT” which would be unique. BTW, I’d prefer the “-ALT” be configurable. If it were up to me, Id prefer “Aen”, to match the locale syntax normally used in electronic_text.

When I run a script that follows the content_id(s) in this order:

product_content:content_id->content:data_resource_id->data_resource:data_resource_id->electronic_text:text_data

I get this:

[demo]
ALT-SUCCESS id=[FA-001-30] Content_id=[FA-001-30-ALT] text_dara=[financial-account-activation-30] url=[financial-account-activation-30-FA-001-30-p]
ALT-SUCCESS id=[FA-001-50] Content_id=[FA-001-50-ALT] text_data=[financial-account-activation-50] url=[financial-account-activation-50-FA-001-50-p]
ALT-SUCCESS id=[FA-001-O] Content_id=[FA-001-O-ALT] text_data=[financial-account-activation-o] url=[financial-account-activation-o-FA-001-O-p]
[mine]
ALT-SUCCESS id=[10000-798936836182] Content_id=[10002] text_data=[10000-798936836182] url=[10000-798936836182-10000-798936836182-p]
ALT-SUCCESS id=[10000-798936823571] Content_id=[10003] text_data=[10000-798936823571] url=[10000-798936823571-10000-798936823571-p]

The “friendly URLs” generated are not friendly. I would hope that the text_data format would also be configurable. Right not it seems to put in the product_id. I’d prefer the short description, (depending on the locale) converted to lower case, with spaces to switched to “-” characters.


#4

Thanks, and I noted your preferences there. There’s a chance the whole function will be replaced or highly modified, but to be honest I cannot say for sure yet, though it just happened to be on our list to fully review very soon.


#5

I want to extend on what Pascal already said. Basically the ecomseo component is something we (ilscipio) contributed to the OFBiz community. It resulted out of our own work back in the day and Jinghai (who was a team member at that point), generalized the work a bit for the ofbiz community. Jacques then tried to replace the common store with it, but got blocked because… well, let’s just say some ofbiz members don’t like other companies contributions. So it got added alongside the outdated ecommerce component.

I am saying this now, to ensure you that SEO is something that is very dear to us and we invest into quite a bit.

Anyway, we heavily improved on that code for our own purposes and client installations since, so we are now reviewing those aspects again for the our store component. We must do this now anyway, as a new CMS component is in the works and thus there is a higher need for a better url structure. Other features, such as a sitemap generator is also desired; and you also have to sanitize the urls to take care of diacritics properly. So we plan on adding those, too…

So the short answer is: we will probably provide an update to all this very soon…


#6

Well, I managed to get the SEO friendly URLs working for the products and categories by changing the seed data to add the proper ALTERNATIVE_URL records, using the naming convention I wanted for content_id “xxxAen”. Urls like this work:

Friendly Product : https://example.com/mount_name/agreement-builder-10000-798936826053-p
Friendly Category: https://example.com/mount_name/kids-toddler-preschool-kinder-10035-c

However, the category listing generated on the left menu still shows normal ofbiz links when hovering over, and after clicking:

https://example.com/mount_name/products/10000/10010/10011

So it is not dynamically substituting the SEO category name. However, for the products, hovering over and clicking “detail” shows the friendly SEO for the products.

Is there a trick to make the left menu properly list the SEO category names?


#7

We’re working on replacement for the seo link building. What you see is because of multiple different url generation methods were originally used by ofbiz and were in ecommerce and shop for demo purposes first. you’d have to edit the templates but with the WIP stuff it will probably not be necessary.


#8

Here is another bug in the SEO code that creates the link to the product “detail” link. It appears that the building of the product detail does not take into account the locale. If I have a MULTIPLE alternate links defined for the same product in electronic_text, the detail link seems to pick up the first matching. Example:

https://example.com/mount/101キティペット-バーチャルペットゲーム-10000-798936838421-p
https://example.com/mount/101-kitty-pets-virtual-pet-game-10000-798936826053-p

Even though both of the same links point to the same product (and they each work), the one that shows up in the product detail is the first one returned from the database.

Here is the evidence from the postgresql logs:

SELECT PRODUCT_ID, CONTENT_ID, PRODUCT_CONTENT_TYPE_ID, FROM_DATE, THRU_DATE, PURCHASE_FROM_DATE, PURCHASE_THRU_DATE, USE_COUNT_LIMIT, USE_TIME, USE_TIME_UOM_ID, USE_ROLE_TYPE_ID, SEQUENCE_NUM, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP FROM public.PRODUCT_CONTENT WHERE ((PRODUCT_ID = ‘10000-798936838421’ AND PRODUCT_CONTENT_TYPE_ID = ‘ALTERNATIVE_URL’)) ORDER BY FROM_DATE DESC;


10000-798936838421|10000-798936838421Aja|ALTERNATIVE_URL|2017-11-04 12:43:58-07|||||||||2017-11-04 12:45:56.666-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:56.666-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Azh|ALTERNATIVE_URL|2017-11-04 12:43:58-07|||||||||2017-11-04 12:45:58.073-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:58.073-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Avi|ALTERNATIVE_URL|2017-11-04 12:43:58-07|||||||||2017-11-04 12:45:58.453-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:58.453-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Ako|ALTERNATIVE_URL|2017-11-04 12:43:58-07|||||||||2017-11-04 12:45:59.121-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:59.121-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Ait|ALTERNATIVE_URL|2017-11-04 12:43:57-07|||||||||2017-11-04 12:45:53.691-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:53.691-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Aen|ALTERNATIVE_URL|2017-11-04 12:43:57-07|||||||||2017-11-04 12:45:52.165-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:52.165-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Aru|ALTERNATIVE_URL|2017-11-04 12:43:57-07|||||||||2017-11-04 12:45:54.164-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:54.164-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Aes|ALTERNATIVE_URL|2017-11-04 12:43:57-07|||||||||2017-11-04 12:45:52.719-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:52.719-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Ade|ALTERNATIVE_URL|2017-11-04 12:43:57-07|||||||||2017-11-04 12:45:52.893-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:52.893-07|2017-11-04 12:45:24.469-07
10000-798936838421|10000-798936838421Afr|ALTERNATIVE_URL|2017-11-04 12:43:57-07|||||||||2017-11-04 12:45:53.273-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:53.273-07|2017-11-04 12:45:24.469-07


NOTE: Does not distinguish or look for locale, so it takes the first found, which is “10000-798936838421Aja”

Then it moves on with this false data:

SELECT CONTENT_ID, CONTENT_TYPE_ID, OWNER_CONTENT_ID, DECORATOR_CONTENT_ID, INSTANCE_OF_CONTENT_ID, DATA_RESOURCE_ID, TEMPLATE_DATA_RESOURCE_ID, DATA_SOURCE_ID, STATUS_ID, PRIVILEGE_ENUM_ID, SERVICE_NAME, CUSTOM_METHOD_ID, CONTENT_NAME, DESCRIPTION, LOCALE_STRING, MIME_TYPE_ID, CHARACTER_SET_ID, CHILD_LEAF_COUNT, CHILD_BRANCH_COUNT, CREATED_DATE, CREATED_BY_USER_LOGIN, LAST_MODIFIED_DATE, LAST_MODIFIED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP FROM public.CONTENT WHERE ((CONTENT_ID = ‘10000-798936838421Aja’));


10000-798936838421Aja|DOCUMENT||||10000-798936838421Aja||||||||ALT_URL ja 10000-798936838421|ja|||||2017-11-04 12:43:58-07|admin|||2017-11-04 12:45:56.652-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:56.652-07|2017-11-04 12:45:24.469-07


Then eventually, looks up the electronic_text value:

SELECT DATA_RESOURCE_ID, TEXT_DATA, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP FROM public.ELECTRONIC_TEXT WHERE ((DATA_RESOURCE_ID = ‘10000-798936838421Aja’));


10000-798936838421Aja|101キティペット-バーチャルペットゲーム|2017-11-04 12:45:56.65-07|2017-11-04 12:45:24.469-07|2017-11-04 12:45:56.65-07|2017-11-04 12:45:24.469-07

And displays on the web UI. What seems to be missing is a call to distinguish which item in product_content is to be displayed.


#9

Hi Mike, I think you are correct that the generated links do not properly take into account the locale. In ofbiz stock code only the receiving end (the java filter) recognizes the locale, while the link-generating code does not. It appears to be a major oversight in the original ofbiz code (or intentionally unimplemented). (There is probably some extra code in the Seo patches submitted to ofbiz that might include the locale, but we are reintegrating that here)


#10

Hi Mike,

Just to keep this thread up to date, please note we committed immense improvements to SEO URLs to the master branch. Basically completely re-engineered version of the old “ecomseo” code that appears almost unmaintained in ofbiz. In theory much of this thread issues are addressed, though we welcome more testing of everything. But they are not all enabled in applications/shop by default at the moment for various reasons, and the superficial demo data that gets loaded doesn’t reflect it yet.

Very basically, the new SEO mode is disabled** by default at the moment and requires setting the new filter setting “seoUrlEnabled” to “true” in Shop’s web.xml, and regenerating the SEO alternative URLs using either https://localhost:8443/catalog/control/WebSiteSeo?webSiteId=ScipioWebStore or https://localhost:8443/admin/control/runService?SERVICE_NAME=generateAllAlternativeUrls. Note if you run these with the defaults, it will essentially change all the URLs for the website or all websites, respectively.

There are numerous other settings (noted on that page) that can involve complex behavior, so we’ve primarily worked with and tested the defaults that most users will likely want. There are still some areas that need improvement such as adding ECAs (but I noticed you didn’t want these for Solr, and it’s a similar pattern of use).

So the localization for the generated URLs you noted above should be completely fixed when seoUrlEnabled is enabled.

** Note: we will likely switch seoUrlEnabled to true by default very soon possibly this week (it is largely safe as the filter can read back the old alt URLs).


#11

Thanks. I noticed that your demo site was down shortly after this message, so I was waiting until it was back [grin]. I haven’t had a chance to look at this yet, but I will shortly. A lot of the SEO related issues I had I solved by changing the seed data. I’ll check this out soon.


#12

thanks for letting us know.

Note that the seoUrlEnabled was switched to true by default in trunk since it will become standard. So git update may change look of URLs.


#13

@mz4wheeler When you do test this: also take a look at the CMS functionality and the sitemap feature. In terms of SEO, those two will help you immensely.


#14

Url must SEO friendly as we have to make sure that the major search engine like google and bing consider it search engine friendly. there should a option for alternate URL, so you can make one proper URL with SEO guidelines without the dynamic parameters.


#15

This feature has been fixed months ago and the store now accurately produces search engine friendly urls. The following link shows you an example config page for the website we use for our online demo:

https://ce.scipioerp.com/catalog/control/WebSiteSeo?webSiteId=ScipioWebStore

The same is available in your backend. You can check the results on our online store, for example:

https://ce.scipioerp.com/shop/product/demo-catalog/automotive/a40f-utility-vehicle-VH-9943
https://ce.scipioerp.com/shop/product/demo-catalog/clothing/menswear/mens-jacket-CL-5005
https://ce.scipioerp.com/shop/category/demo-catalog/clothing

Although the speaking urls are generated automatically, you can always rely on this page if you want to regenerate them. The original alt-url config, which is stored in database is also still available. Likewise, proper sitemaps are now auto-generated and can be accessed here:

https://ce.scipioerp.com/shop/sitemaps/sitemap_index.xml